4-Jan-88 09:52:44-PST,3853;000000000000 Return-Path: Received: from SCIENCE.UTAH.EDU by SCORE.STANFORD.EDU with TCP; Mon 4 Jan 88 09:49:45-PST Date: Mon 4 Jan 88 10:50:52-MST From: "Nelson H.F. Beebe" Subject: Alternatives to TOPS-20 MAKLIB? To: tops-20@SCORE.STANFORD.EDU cc: BEEBE@SCIENCE.UTAH.EDU X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 Message-ID: <12363954561.23.BEEBE@SCIENCE.UTAH.EDU> Under both TOPS-20 and Unix, linkers search load libraries only once, which makes it desirable to order the library (or at least its index) in topological order (if B calls A, then B appears before A in the library). This order is non-trivial to determine, though my LIBREF utility (available on request) will produce a control file to append .REL files into a library in topological order. It is completely out of the question to create this order by hand; the latest release of one of our commercial math libraries has over 3900 routines. It would be far easier to just do "append *.rel foo.lib", then apply a filter to foo.lib to create an index in topological order. Under Unix, the `ar' utility supports creation of libraries of any types of files, and the object file format is relatively simple. A separate utility, `ranlib', is usually applied to the library to produce an index. Part of the SUN OS 3.2 Unix man page for the linker, `ld' reads: If a named file is a library, it is searched exactly once at the point it is encountered in the argument list. Only those routines defining an unresolved external reference are loaded. If a routine from a library references another rou- tine in the same library, and the library has not been pro- cessed by ranlib, the referenced routine must appear after the referencing routine in the library. Thus the order of programs within libraries may be important. The first member of a library should be a file named `__.SYMDEF', which is understood to be a dictionary for the library as produced by ranlib; the dictionary is searched iteratively to satisfy as many references as possible. Updating a Unix library is relatively trivial: ar r foo.a *.o ranlib foo.a Under VAX VMS, library/create foo.olb library foo.olb *.obj suffice to first create, and subsequently update, an object library. Under TOPS-20, MAKLIB provides a painful alternative: MAKLIB *foo.rel=foo.rel,a.rel/{append,replace,insert:module} *foo.rel=foo.rel/index requiring before-hand knowledge of whether the module is to replace an existing one, append to the end of the library, or be inserted after an existing module. It also causes a copy of the library to be made for every `=' processed in the input stream, which means excessive CPU and disk requirements. The TOPS-20 object file format is rather complex, and the construction of an analogue to Unix `ranlib' is a non-trivial programming task. So, the query to the TOPS-20 community is ``Has anyone written the equivalent of Unix ar/ranlib or VMS LIBRARY for TOPS-20?'' While it is perhaps late in the day to ask this, now that I have `make' running on 6 different O/S's, I am using `make' for all new projects, and writing makefiles for older software collections when I go back and work on them. This past week, I recompiled over 250K lines of Fortran code after we made Fortran V10 the default system version. With only MAKLIB available, rebuilding libraries requires execution of a long command file of APPEND and MAKLIB commands, and requires that the object files be kept on-line, wasting disk space, and makes it hard to use `make' for the library update. ------- 4-Jan-88 11:59:03-PST,1360;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SCORE.STANFORD.EDU with TCP; Mon 4 Jan 88 11:58:24-PST Date: Mon 4 Jan 88 14:30:35-EST From: Rob Austein Subject: Re: Alternatives to TOPS-20 MAKLIB? To: Beebe@SCIENCE.UTAH.EDU cc: tops-20@SCORE.STANFORD.EDU In-Reply-To: <12363954561.23.BEEBE@SCIENCE.UTAH.EDU> Message-ID: <12363972713.49.SRA@XX.LCS.MIT.EDU> If anybody does do any work on a replacement for MAKLIB, please make it handle PSECTs! The rest of this message is a few suggestions for ways of using the existing MAKLIB that are less painful than what you describe. For just creating a new library from .REL files, the following kluge works, where NULL.REL is produced by feeding an END statement to the assembler of your choice: @maklib *new.lib=null.rel,*.rel/append *new.lib=new.lib/delete:null *new.lib=new.lib/index *^Z I haven't tried folding the /DELETE and /INDEX steps into one, I forget whether MAKLIB will allow that. Doesn't matter much. For the case of updating an existing library, you might want to consider writing a trivial filter that takes the output from a MAKLIB /POINTS command and, based on that and a list of files, produces a MAKLIB script that will /APPEND or /REPLACE as appropriate. None of this is pretty, but it's cheap. --Rob ------- 4-Jan-88 18:24:57-PST,828;000000000000 Return-Path: Received: from MATHOM.CISCO.COM by SCORE.STANFORD.EDU with TCP; Mon 4 Jan 88 18:24:35-PST Date: Mon 4 Jan 88 18:25:46-PST From: Greg Satz Subject: Re: Alternatives to TOPS-20 MAKLIB? To: Beebe@science.utah.edu cc: tops-20@SCORE.STANFORD.EDU In-Reply-To: <12363954561.23.BEEBE@SCIENCE.UTAH.EDU> Phone: (415) 326-1941 Message-ID: <12364048296.6.SATZ@MATHOM.CISCO.COM> A long time ago I wrote a Pascal program that would take a Fortran generated relocatable file and topologically sort the routines generating two output files, one that must be loaded and another that could be searched. This was intended to be run over the larger libraries like IMSL so that it could be loaded in a more reasonable manner. The source is free for the asking. ------- 5-Jan-88 09:27:38-PST,676;000000000000 Return-Path: Received: from SCIENCE.UTAH.EDU by SCORE.STANFORD.EDU with TCP; Tue 5 Jan 88 09:26:47-PST Date: Tue 5 Jan 88 10:27:21-MST From: "Nelson H.F. Beebe" Subject: Re: Alternatives to TOPS-20 MAKLIB? To: tops-20@SCORE.STANFORD.EDU, Beebe@SCIENCE.UTAH.EDU In-Reply-To: <12364048296.6.SATZ@MATHOM.CISCO.COM> X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 Message-ID: <12364212424.27.BEEBE@SCIENCE.UTAH.EDU> Yes, I'd like to see what you've done. I can pick it up via ANONYMOUS FTP if you tell me where to look. ------- 6-Jan-88 15:15:00-PST,1235;000000000001 Mail-From: GROSSMAN created at 6-Jan-88 15:14:56 Date: Wed 6 Jan 88 15:14:56-PST From: Stu Grossman Subject: Stanford TOPS-20 meeting To: su-tops-20@Score.Stanford.EDU Message-ID: <12364537844.23.GROSSMAN@Score.Stanford.EDU> I have scheduled a meeting to discuss the current situation of TOPS-20 at Stanford. I expect that the agenda of this meeting will go along the following lines: 1) Version 7.0 field test management 2) Domain name resolvers (ie: JEEVES vs. CHIVES) 3) Support for large host numbers in the campus network (ie: IP addresses like 36.8.5.123) 4) GALAXY support 5) Removal of PUP routing dependancies 6) Death of Sierra/location of source tree 7) Other issues... I have scheduled the meeting for: Thursday, January 14th, 1:00 to 4:00 pm in room 352 of Margaret Jacks Hall Please let me know of any other issues that you feel are important, and I will add them to the agenda. Also, the issues listed above are rather roughly prioritized, so feel free to suggest a better prioritization. Also, feel free to invite people who may not be on this list, if you think that they should be at this meeting. Stu Grossman ------- 11-Jan-88 11:58:39-PST,757;000000000000 Return-Path: Received: from R20.UTEXAS.EDU by SCORE.STANFORD.EDU with TCP; Mon 11 Jan 88 11:55:42-PST Date: Mon 11 Jan 88 13:57:40-CST From: Clifford A. Wilkes Subject: Setting back-up status To: tops-20@SCORE.STANFORD.EDU Department: Computation Center - A20/R20 staff Message-ID: <12365812653.22.CC.WILKES@R20.UTEXAS.EDU> Surely someone out there has a program to set the back-up status of files. I don't want to use REV to do entire discs! We have had to do a lot of disc restorations and each one causes DUMPER to make very(!) large incremental back ups. It's obviously an easy program to write but we have other things pending. Any help will be appreciated. <@> ------- 11-Jan-88 15:20:51-PST,6897;000000000000 Return-Path: Received: from GSB-HOW.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 11 Jan 88 15:20:02-PST Date: Mon 11 Jan 88 15:19:48-PST From: Eric M. Berg Subject: Preview of TOPS-20 version 7 (notes from Fall '87 DECUS) To: tops-20@Score.Stanford.EDU Phone-#s: 415/723-1576 (GSB-CF), 415/329-9940 (home) Message-ID: <12365849449.160.A.ERIC@GSB-HOW.Stanford.EDU> For the benefit of people who weren't at DECUS, here are some notes from the "TOPS-20 Technical Update" session given by Jim McCollum of DEC on Thursday, Dec. 10, 1987. They cover DEC's plans for TOPS-20 version 7. (These are based on the notes I took at the session. I apologize for any errors or misunderstandings; don't blame them on DEC.) GOALS for TOPS-20 version 7 =========================== --Improved maintainability, reliability, performance --Reduce unanswered SPR backlog to 0 --Improved user interface (partial filename recognition to ambiguity; cluster-wide OPR commands) --Meet customer requirements --Finish on-going 6.0/6.1 work (make cluster more usable; continue Galaxy work) --No new major functionality --Hold to original schedule. FEATURES of TOPS-20 version 7 ============================= --INFO% jsys to allow remote execution of certain system calls across cluster (e.g. SYSTAT, ^Esend) --"Dump on BUGCHK": ability to take a crash dump without crashing --Cluster-wide ENQ%/DEQ%: extends ENQ%/DEQ% across cluster; user programs will have to be re-written to take advantage of this --Separate login structure (also known as "non-PS: login"): the BS: ("boot structure") will no longer necessarily be the same as PS: (where user login directories are found); this allows several systems in a cluster to share a PS: structure. --Better handling of off-line disk structures: if a disk structure goes off-line, certain system calls (e.g. GTJFN, ACESS, OPENF) will return errors rather than causing the user's job to hang. Jobs with open files on the off-line structure will still hang. --Filename recognition to the point of ambiguity (currently implemented in the Stanford monitor): trying to do recognition where filenames with similar roots (e.g. "FILE-PART1.TXT","FILE-PART2.TXT") will result in the system typing out the unambiguous part (e.g. "FILE-PART") and then beeping, rather than doing no recognition at all. --Host-initiated LAT connections ("reverse LAT" connections, useful for spooling to LAT-connected printers) --Cluster-wide dumping (can force a crash-dump on all cluster members simultaneously) --Increased structure limits (up to 64 structures): adds more section 0/1 space --Support for CFS cluster with up to 4 CPUs --CFS transition messages: provides error messages when problems occur with a node joining a cluster --Timing-out of startup questions: system will wait one minute for an answer to startup questions ("Why reload?"), then time out and proceed with re-load if no answer is given. --PMOVE/PMOVEM instructions: will be implemented in microcode, rather than in monitor --New GETAB% functions: will return # of jobs and users on the system, also the highest & lowest job numbers in current use --DELETE subcommands: similar to the subcommands available in the DIRECTORY command ("before", "since", "larger", "smaller") --general cleanup of EXEC code --EMACS-style command editor (as implemented in Stanford EXEC) will be distributed as an unsupported product (same as PCL and MIC software) NEW GALAXY FEATURES =================== --Cluster-wide Galaxy: from a single node, give OPR commands which affect entire cluster. "SHOW CLUSTER" counterparts to OPR "SHOW" commands. --"Unprivileged OPR": allows holders of the new SEMI-OPR privilege bit to execute some subset of OPR commands. Which commands they can use are selectable during GALGEN. --Several LPTSPL changes: cluster-wide LPTSPL: print from one node to another LAT server LPTSPL: print to LAT-attached printers TTY LPTSPL: supports any TTY device as a printer DQS LPTSPL: allows files to be printed to DQS server on VMS systems --EXEC changes to support all this SCHEDULE ======== Field tests: starting January 1988 3 (or maybe 2, if things go well) field test tapes SDC submission: June 1988 Customer shipments: August 1988 DOCUMENTATION ============= DEC asked for feedback on their plans to stop producing printed TOPS-10/20 documentation. Instead, they'd like to distribute the documentation on-line in RUNOFF .MEM file format. Each site could then print and distribute the documentation as it wished. A number of users asked why DEC didn't plan to distribute the RUNOFF sources in .RNO format. Answer: the documentation is produced using a (Vax) version of RUNOFF; the sources won't compile using TOPS RUNOFF. However, users pointed out that it would be easier to convert the documentation to another format (like Scribe or LaTeX) if we had the .RNO sources. They asked DEC whether, if some site did the work of converting the documentation to Scribe/LaTeX, that site could then redistribute the (printed) documentation to other sites (which might not have Scribe/LaTeX). DEC took the issue under advisement. Since no users at the session raised any _major_ objections, my guess is that TOPS-10/20 documentation printed & distributed by DEC will soon be a thing of the past. Sites with subscriptions to the "TOPS-20 Software Notebooks" update service, take note. OTHER DISCUSSION ================ Betsy Ramsey of AMS asked whether DEC planned to make sources available to non-source licensees once TOPS-10/20 development by DEC was finished. The general tenor of the response was "we don't see any need to do that as long as we are continuing to provide software support, which will be for at least the next 5 years". DEC also mentioned that: (1) they are working on improvements to the AUTOPATCH process; (2) they are looking into the possibility of supporting older versions of the operating system for customers who want to "freeze" at earlier versions of the software. This would include telephone advisory service, "best-effort" workarounds, performance analysis, but _not_ SPR service. DECUS Large Systems SIG ======================= There was some discussion about the future of the Large Systems SIG within DECUS at the Large Systems Town Meeting. I expect there'll be some reflection of this in the Large Systems section of the next issue of the DECUS newsletters. There's also an electronic mailing-list for the Large Systems SIG steering committee: LS-SIG@R20.UTexas.EDU. ------- 11-Jan-88 19:57:34-PST,1034;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SCORE.STANFORD.EDU with TCP; Mon 11 Jan 88 19:57:08-PST Date: Mon 11 Jan 88 22:55:03-EST From: Rob Austein Subject: Re: Setting back-up status To: CC.Wilkes@R20.UTEXAS.EDU cc: tops-20@SCORE.STANFORD.EDU In-Reply-To: <12365812653.22.CC.WILKES@R20.UTEXAS.EDU> Message-ID: <12365899557.57.SRA@XX.LCS.MIT.EDU> Date: Mon 11 Jan 88 13:57:40-CST From: Clifford A. Wilkes Surely someone out there has a program to set the back-up status of files. I don't want to use REV to do entire discs! We have had to do a lot of disc restorations and each one causes DUMPER to make very(!) large incremental back ups. [XX.LCS.MIT.EDU]SRC:FIX-INCREMENTAL.MID may be what you want. We find it useful when restoring 5 and 6 pack public structures from tape. You'll also need MID:MACSYM.MID and MID:CMD.MID to assemble it. All are available via anonymous FTP. --Rob ------- 12-Jan-88 11:00:02-PST,1185;000000000000 Return-Path: Received: from A20.CC.UTEXAS.EDU by SCORE.STANFORD.EDU with TCP; Tue 12 Jan 88 10:58:01-PST Date: Tue 12 Jan 88 12:59:56-CST From: Kay Nettle Subject: TCPSPL To: tops-20@SCORE.STANFORD.EDU Message-ID: <12366064288.10.CC.NETTLE@A20.CC.UTEXAS.EDU> I can get TCPSPL and LPD to work with version 5.4 of the monitor and 4.2 of galaxy, the R20. When I try using TCPSPL under version 6.1 of the monitor and 5 of galaxy, the A20,it doesn't work. LPD will work on both systems. I have plpt3: defined on the A20 as tcp:a20-770.r20-515;timeout:60; connection:active. On the R20 it's defined as tcp:r20-77-.a20-515; timeout:60;connection:active. When I start up printer 3, this is what happens on the A20: OPR>start printer 3 OPR> 12:35:10 Printer 3 -- Startup Scheduled -- OPR> 12:35:11 Printer 3 -- TCPSPL - Not Started -- Can't find device TCP:A20-770.R20-515.0;TIMEOUT:60;CONNECTION:AC TIVE OPR> 12:35:12 Printer 3 -- TCPSPL - Stream Shutdown -- 12:35:12 Printer 3 -- Shutdown -- OPR>ex Does anyone have any advice or see anything that I'm doing wrong. -Kay- ------- 14-Jan-88 11:09:07-PST,1155;000000000000 Return-Path: Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 14 Jan 88 11:09:02-PST Return-Path: Received: from A20.CC.UTEXAS.EDU by SUMEX-AIM.Stanford.EDU with TCP; Thu, 14 Jan 88 06:27:05 PST Date: Wed 13 Jan 88 15:58:34-CST From: Kay Nettle Subject: Quasar modifications To: crispin@SUMEX-AIM.STANFORD.EDU Message-ID: <12366358950.18.CC.NETTLE@A20.CC.UTEXAS.EDU> ReSent-Date: Thu, 14 Jan 88 11:08:58 PST ReSent-From: Mark Crispin ReSent-To: SU-TOPS-20@Score.Stanford.EDU ReSent-Message-ID: <12366590220.56.CRISPIN@SUMEX-AIM.Stanford.EDU> I'm working on TCPSPL and LPD that I got from SIERRA. In LPDQSR.MAC is says that it assumes that some modifications have been made to Quasar and friends. I have tried writing the Quasar man at Columbia, but can't get a responce. I assume that ya'll are using it since it has stanford local stuff in it. Could you please tell me what modifications have to be made, or point me to someone who could tell me? Thanks. -Kay- ------- 16-Jan-88 17:38:46-PST,5784;000000000000 Return-Path: Received: from SCIENCE.UTAH.EDU by SCORE.STANFORD.EDU with TCP; Sat 16 Jan 88 17:36:47-PST Date: Sat 16 Jan 88 18:37:48-MST From: "Nelson H.F. Beebe" Subject: A new PCC-20 bug, and a fix To: tops-20@SCORE.STANFORD.EDU cc: BEEBE@SCIENCE.UTAH.EDU X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 Message-ID: <12367185293.18.BEEBE@SCIENCE.UTAH.EDU> I just nailed a bug in PCC-20 (the first found in over 2 years), and since we have compiler sources, was able to fix it. Jay Lepreau (lepreau@cs.utah.edu) originally ported PCC to TOPS-20 and distributed it to numerous TOPS-20 sites under license. He has given me permission to publish this report and the code fix. CS sold their DEC-20/60 to SCIENCE last year, so he is no longer in a position to maintain TOPS-20 software. The bug may exist in other derivatives of the original PCC; I checked cc's code generation on CS.UTAH.EDU (4.3BSD VAX Unix), but found it to be okay there. The bug is exhibited by the simple program: char item_x[ 3][ 144] = { "", "\n \\subitem ", "\n \\subsubitem "}; main() { int k; for (k = 0; k < 3; ++k) printf("item_x[%d][] = \"%s\"\n",k,&item_x[k][0]); } (a fragment from the Chen/Lamport MakeIndex program for production of document indexes for TeX, LaTeX, Scribe, troff, et al) The generated .S file has ... entry item.x item.x:: oct 0 exp 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, exp 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, exp 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, exp 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, exp 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, exp 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 oct 12 oct 40 oct 40 oct 40 oct 40 oct 134 oct 163 oct 165 oct 142 oct 151 oct 164 oct 145 oct 155 oct 40 oct 0 .... The bug is that the 5 exp lines ending in commas result in MACRO supplying an extra 0 word, with the result that the second string begins at offset 144+5 = 149, instead of 144. The fix involves rewriting zecode() in code.c; 2 years ago when I last worked on the compiler, I had already worked in that section to produce a repeat count, instead of repeated 0's, because I wanted to shorten the enormous .REL's that could be produced if n was large. The code never got installed in our production version of PCC-20 because I ran out of steam on some other modifications. I just reactivated that code section, so the .S file now has item.x:: oct 0 xlist repeat ^D143, list oct 12 oct 40 oct 40 oct 40 oct 40 oct 134 oct 163 oct 165 oct 142 oct 151 oct 164 oct 145 oct 155 oct 40 oct 0 ... which now produces correct storage assignments. If you do not want to make source patches to the compiler, you can grab PCC:C1.EXE via ANONYMOUS FTP to SCIENCE.UTAH.EDU. It has enlarged tables for big switch statements, and PCC:CPP.EXE, the preprocessor, has been extended to support long symbol names (up from 8 to 63) and allow more of them (up from 1000 to 20000). The latter change allows it to handle a full monsym.h. With Jay's permission, the complete source mods for these changes could be made available too. I also have a Unix cc-like interface which avoids the need for PCL or MIC commands to run PCC-20; ask and ye shall receive. Here is the replacement code for function zecode() in <*.CPP.DIST>code.c; the original code is preserved for reference. Install it, recompile code.c, and then do link @c1.ccl to make a new C1.EXE which can be installed in PCC:. zecode( n ){ /* n integer words of zeros */ OFFSZ temp; register i; if( n <= 0 ) return; #if 0 /* This code is WRONG-- the extra "," at the end of */ /* each line causes MACRO to supply an extra zero! */ printf( ") exp " ); for( i=1; i\n", n); printf( ")\tlist\n"); } #endif temp = n; inoff += temp*SZINT; } While you're at it, here is another fix to code.c: /* NHFB01: Surround BLT by PUSH/POP to preserve Ac1 -- code generated */ /* for functions which return a "struct" */ efcode(){ /* code for the end of a function */ if (strftn) { /* copy output (in r1) to caller, ie for fxs returning strucs (pointed to by r1). */ register struct symtab *p; register int stlab; register int count; int size; p = &stab[curftn]; deflab( retlab ); stlab = getlab(); size = tsize(DECREF(p->stype), p->dimoff, p->sizoff) / SZCHAR; count = size / NCHPERINT; /* what if not integral?? fjl */ printf( ")\thrl $1,$1\n) hrri $1,$%d\n", stlab ); /* NHFB01: Ac1 gets clobbered by BLT -- need to save and restore */ /* printf( ")\tblt $1,$%d+%d-1\n) hrrzs $1,$1\n", stlab,count); */ printf( ")\tpush\t$p,$1\n"); printf(")\tblt $1,$%d+%d-1\n",stlab,count); printf(")\tpop\t$p,$1\n"); printf(")\thrrzs\t$1,$1\n"); printf( ") reloc\n" ); printf( ")\tarray\t$%d[%d]\n) reloc\n", stlab, count ); /* turn off strftn flag, so return sequence will be generated*/ strftn = 0; } branch( retlab ); printf(") lit\n"); /* for locality, also make sure in text seg*/ #ifdef ONEPASS p2bend(); #else printf("]\n"); #endif } ------- 16-Jan-88 17:39:02-PST,644;000000000000 Return-Path: <@SUMEX-AIM.Stanford.EDU:MRC@PANDA.PANDA.COM> Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Sat 16 Jan 88 17:37:00-PST Received: from PANDA.PANDA.COM by SUMEX-AIM.Stanford.EDU with Cafard; Sat, 16 Jan 88 17:37:59 PST Date: Sat, 16 Jan 88 17:15:31 PST From: Mark Crispin Subject: GIGI (a.k.a. VK100) manual To: TOPS-20@Score.Stanford.Edu Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12367181236.7.MRC@PANDA.PANDA.COM> Hi, does anyone have a GIGI manual they don't need/want and are willing to send to me? ------- 19-Jan-88 06:55:56-PST,1516;000000000000 Return-Path: <114RONAN%VAX.LIVPOL.AC.UK@forsythe.stanford.edu> Received: from lindy.stanford.edu by SCORE.STANFORD.EDU with TCP; Tue 19 Jan 88 06:51:51-PST Received: by lindy.stanford.edu; Tue, 19 Jan 88 06:54:08 PST Received: by Forsythe.Stanford.EDU; Tue, 19 Jan 88 06:55:29 PST Received: from RL.IB by UKACRL.BITNET (Mailer X1.25) with BSMTP id 2450; Tue, 19 Jan 88 12:24:56 GMT Via: UK.AC.RL.EARN; Tue, 19 Jan 88 12:24:55 GMT Received: from RL.IB by UK.AC.RL.IB (Mailer X1.25) with BSMTP id 2447; Tue, 19 Jan 88 12:24:54 GM Via: UK.AC.LIVPOL.SPOOL; 19 JAN 88 12:24:39 GMT Date: 19-JAN-1988 12:14:25 From: 114RONAN%VAX.LIVPOL.AC.UK@forsythe.stanford.edu To: TOPS-20@score.stanford.edu Subject: Alternative archiving with request queue wanted. Having moved to TOPS-20 6.1, we are disappointed with the time taken by archive runs of DUMPER on our (very full) RP07 PS:. The computer manager here thinks that he remembers hearing about a different archiving system that used a queue of archive requests, (like the queue for retrievals), rather than having DUMPER scan the whole disk looking for marked files. This may have been a patch to some standard TOPS-20 utilities, though frankly I doubt it... Does anyone out there know anything about a system like this? Thanks for any help offered. Ronan Flood, Liverpool Polytechnic Computer Services. INTERnet: 114RONAN%VAX.LIVPOL.AC.UK@NSS.CS.UCL.AC.UK BITNET: 114RONAN%UK.AC.LIVPOL.VAX@AC.UK (I hope...) 19-Jan-88 10:44:32-PST,1014;000000000000 Return-Path: Received: from MCC.COM by SCORE.STANFORD.EDU with TCP; Tue 19 Jan 88 10:41:36-PST Date: Tue 19 Jan 88 12:44:49-CST From: Clive Dawson Subject: Re: Alternative archiving with request queue wanted. To: 114RONAN%VAX.LIVPOL.AC.UK@FORSYTHE.STANFORD.EDU cc: tops-20@SCORE.STANFORD.EDU In-Reply-To: Message from "114RONAN%VAX.LIVPOL.AC.UK@forsythe.stanford.edu" of Tue 19 Jan 88 12:14:25-CST Message-ID: <12367896542.58.AI.CLIVE@MCC.COM> Ronan- There have been several efforts over the years to speed up archiving. One of the best was done by Don Watrous at Rutgers, which makes use of a file called SYSTEM:ARCHIVE-REQUESTS.BIN. Everytime somebody makes an archive request, a bit corresponding to the directory is set in this file. This allows DUMPER to avoid scanning the whole disk. More info on this can be found in the TOPS-20 mailing list archives, or presumably from Don himself. (Try mail to WATROUS@RED.RUTGERS.EDU.) Clive ------- 19-Jan-88 11:50:06-PST,1510;000000000000 Return-Path: Received: from TOPS20.DEC.COM by SCORE.STANFORD.EDU with TCP; Tue 19 Jan 88 11:44:51-PST Date: 19 Jan 1988 1447-EST From: "Jim McCollum" To: tops-20@score.stanford.edu Reply-to: mccollum@tops20.dec.com dtn: 297-4635 Subject: TOPS-20 ARP change proposal Message-ID: <"MS11(6034)+GLXLIB6(0)" 12367907926.11.34.97083 at TOPS20.DEC.COM> A question for the ARPA community concerning TOPS-20 and the way it deals with ARP packets: I have an SPR that states that all the replies that TOPS-20 sends to ARP Request packets are sent to the ARP multicast address. It goes on to ask that we change this so that ARP replies are sent only to the requestor and not the multicast. Sure enough, this is TOPS-20's current behaviour. The RFC does not specifically state where the replies should be sent. The submitter of the SPR claims that UNIX 4.2 does not send replies to the multicast (as an example). I can't see any good reason for replying to the multicast address and am planning on changing TOPS-20 to reply only to the requestor. Does anyone have any problems with this? As an aside, it appears to me from looking at the code that when a TOPS-20 system receives a reply packet on the multicast that is not directed to itself, it pitches the packet without any update to the ARP tables. This seems like one more reason that replying to the multicast is useless. Jim -------- 21-Jan-88 21:36:31-PST,483;000000000000 Return-Path: Received: from SRI-NIC.ARPA by SCORE.STANFORD.EDU with TCP; Thu 21 Jan 88 21:33:29-PST Date: Thu, 21 Jan 88 21:37:54 PST From: Mark Lottor Subject: markup bug To: tops-20@SCORE.STANFORD.EDU Message-ID: <12368539720.22.MKL@SRI-NIC.ARPA> The routine MARKUP in IPIPIP that processes ICMP echo and echo replies doesn't get the host number correctly. It should do a LOAD T1,PISH,(PKT) instead of what's there. ------- 25-Jan-88 21:54:51-PST,1047;000000000001 Return-Path: Received: from lindy.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 25 Jan 88 21:51:06-PST Received: by lindy.stanford.edu; Mon, 25 Jan 88 21:56:19 PST Received: by Forsythe.Stanford.EDU; Mon, 25 Jan 88 21:55:03 PST Received: from ADMIN by UcEdu.UNCA.AdhocNet.CA with DECNET ; Mon, 25 Jan 88 20:24:25 MST Date: Mon 25 Jan 88 20:21:06-MST From: RMF%ADMIN%UNCAEDU.BITnet@forsythe.stanford.edu Subject: SLIP To: tops-20@score.stanford.edu Phone: (403) 240-6052 Organization: Mount Royal College; Computer Operations Postal-Address: 4825 Richard Rd. S.W.; Calgary, Alberta, T3E 6K6 Message-Id: <12369563393.8.RMF@ADMIN> I am looking for a version of SLIP for the 20. Does anyone by chance have a copy they wouldn't mind shareing? /Russ ----- Russell M Forster DECnet: RMF @ { Admin | Flux | Stasis | Ins } BITnet: RForster @ UncaEdu.BITnet ARPA: Oc.Russ @ CU20B.Columbia.Edu USEnet: uunet!calgary!vaxd!forster ------- 25-Jan-88 22:12:51-PST,1308;000000000000 Return-Path: Received: from lindy.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 25 Jan 88 22:12:33-PST Received: by lindy.stanford.edu; Mon, 25 Jan 88 22:17:42 PST Received: by Forsythe.Stanford.EDU; Mon, 25 Jan 88 22:16:24 PST Received: from ADMIN by UcEdu.UNCA.AdhocNet.CA with DECNET ; Mon, 25 Jan 88 20:29:00 MST Date: Mon 25 Jan 88 20:25:46-MST From: RMF%ADMIN%UNCAEDU.BITnet@forsythe.stanford.edu Subject: MM/Chives To: tops-20@score.stanford.edu Phone: (403) 240-6052 Organization: Mount Royal College; Computer Operations Postal-Address: 4825 Richard Rd. S.W.; Calgary, Alberta, T3E 6K6 Message-Id: <12369564244.8.RMF@ADMIN> Does the Chives system work on a *non* TCP/IP site? We are only a DECnet site with an STmail (Software Tools) BITnet gateway into the real world. Also, does anyone know of anyone that was MM or Chives on a BITnet LISTSERVer or some such? RPICICGE (CICGE.RPI.EDU) has some of the SIMTEL's archives but they don't have MM there. /Russ ----- Russell M Forster DECnet: RMF @ { Admin | Flux | Stasis | Ins } BITnet: RForster @ UncaEdu.BITnet ARPA: Oc.Russ @ CU20B.Columbia.Edu USEnet: uunet!calgary!vaxd!forster ------- 26-Jan-88 00:14:15-PST,1261;000000000000 Return-Path: <@SUMEX-AIM.Stanford.EDU:MRC@PANDA.PANDA.COM> Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 26 Jan 88 00:13:57-PST Received: from PANDA.PANDA.COM by SUMEX-AIM.Stanford.EDU with Cafard; Tue, 26 Jan 88 00:17:26 PST Date: Mon, 25 Jan 88 23:19:12 PST From: Mark Crispin Subject: Re: MM/Chives To: RMF%ADMIN%UNCAEDU.BITnet@forsythe.stanford.edu cc: tops-20@score.stanford.edu In-Reply-To: <12369564244.8.RMF@ADMIN> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12369606738.7.MRC@PANDA.PANDA.COM> Russell - PANDA runs Chives, and PANDA's non-TCP/IP and a 2020 to boot. In fact, PANDA has completely replaced its DOMAINS.TXT file with an appropriate zone file for the top-level (most of which consists of entries such as "*.ARPA IN MX 10 SUMEX-AIM.Stanford.EDU"). It's a helluva lot faster than DOMAINS.TXT (not to mention being nice to being able to reply to all hosts). The only guaranteed current MM sources are on PANDA, and so you have to get them from me. From time to time SUMEX-AIM's SS: and SIMTEL20's SRC: directories get updated from PANDA, but only infrequently. -- Mark -- ------- 26-Jan-88 10:46:49-PST,23486;000000000001 Mail-From: VAF created at 26-Jan-88 10:46:05 Date: Tue 26 Jan 88 10:46:04-PST From: Vince Fuller Subject: Re: SLIP (long reply) To: RMF%ADMIN%UNCAEDU.BITnet@Forsythe.Stanford.EDU cc: tops-20@Score.Stanford.EDU In-Reply-To: <12369563393.8.RMF@ADMIN> Office: 147 Pine Hall (under construction) Phone: 415-725-1392 Message-ID: <12369731779.44.VAF@Score.Stanford.EDU> This has been asked and answered before, so my apologies for repeating it here again... Anyway, a few years ago, I made some modifications to TOPS-20 to allow it to support IP over a serial line, using the encapsulation scheme described in the appendix of RFC891. The code worked reasonably well when I tested it but ended up not being used in production here. I have given it to other people, but haven't heard whether it's seen any extensive use (though I'd be interested to hear if you or anyone else gets it running). It should be noted that as distributed, this code assumes you have sources - it might be possible to graft it onto a binary-only system, but that would require some modifications. --Vince (what follows are a copy of my original message about the subject and the TTYSRV "module" which supports the serial line interface) ---------------------------------------- Modifications to TOPS20AN to support TCP/IP over a serial line interface. This assumes that you have a 5.3 or 5.4 TOPS20AN monitor as distributed by DEC. ---------------------------------------- Modifications to ANAUNV.MAC --------------------------- *After the line MAKNCT(\DV.NUM,\NCTNUM,^D576)> *Add: IFNDEF TTYN, ;Default to no TTY interfaces IFN TTYN,< NT.TYP==NT.SER ;Network is "serial line" network NT.DEV==NT.TTY ;Device type TTY DV.NUM==0 ;Start with number 0 MAKNCT(\DV.NUM,\NCTNUM,^D554) ;Make that type NCT >;TTY *After the line NT.NUN==:1 *add NT.SER==:2 ;Serial line protocol *After the line NT.NIN==:2 *add NT.TTY==:3 ;TTY line *After the NCT definition for the NI, add TTY NCT definition: ;Define the TTY internet interface IFE <!>,< HALT ; CONSZ Input HALT ; CONSO Input HALT ; CONO Input HALT ; CONI Input HALT ; DATAO Input HALT ; DATAI Input IFIW!TNTINI ; NTINI - Initialization instruction IFIW!TNTKIL ; NTKILL - Shutdown instruction IFIW!TIPON ; NTRSRT - Restart instruction IFIW!R ; NTISRT - Start input instruction IFIW!TIPOBG ; NTOSRT - Start output instruction IFIW!R ; NTIDUN - Input done dispatch IFIW!R ; NTODUN - Output done dispatch IFIW!R ; NTLLDR - Make header instruction IFIW!TIPOOK ; NTOTOK - Clear packet for output IFIW!R ; NTMAIN - Maintainance IFIW!R ; NTSCHK - Status check instruction BLOCK NTSVAC+17-NTIB ; Storage >;TTY Modifications to GLOBS.MAC -------------------------- *Add one line (after last DEC QEXT line): QEXT ;TTY/IP entry points Modifications to MNETDV.MAC --------------------------- *After the ADNCP routine, add: ;Prrocess SERIAL keyword ADDSER: MOVEI T1,NT.SER ;Protocol is serial line STOR T1,NTTYP,(P3) RET *In the INTNAM table, after the line KEY IPNI,NT.NIP ; KLNI Interface *add one line: KEY TTY,NT.TTY ; Serial line *In the TYPNAM table, after the line KEY PREFERRED,ADDPRF ; This is the 'preferred' address for host *add one line: KEY SERIAL,ADDSER ; Serial line protocol Modifications to PROLOG.MAC --------------------------- *After the definition of IFSM, add one line: DEFINE IPTT, ;Test for IP/TTY interface *You will need to modify your PARAMS file to define TTYN==:1* Modifications to STG.MAC ------------------------ *After the line: NDG KNIN,0 ;NUMBER OF KLNI'S *Add one line: NDG TTYN,0 ; Number of TTY lines *After the line: NDG ANX0,520 ;ADDRESS FOR FIRST AN20 *Add one line: %NETS==:ANXN+IPNIN+TTYN ;TOTAL NUMBER OF IP INTERFACES Modifications to TTYPHDV.MAC --------------------------- *At label BIGST2: add two lines: IPTT,< CALL TIPCHK ; IP link line? RETSKP> ; Yes, just take the character *At TTYDON+3 (after RET) add two lines: IPTT,< CALL TIPCHK ; IP link line? JRST TIPDON> ; Tell it *At TTDTRM+3 (after SAVET) add one line: IPTT,< CALL TIPRST> ; Reset IP link line Modifications to TTYSRV.MAC --------------------------- *After line .PTFLG==1 ;ALWAYS INCLUDE PT CODE *Add one line: IFNDEF TTYN, ; default to no IP TTY *Note: You will need to define this, probably with a one-line file compiled *with TTYSRV, as TTYN==:1 *At TYINLP-3 (after SETZM TTCQLN) add one line: IPTT,< CALL TIPINI> ; Initialize IP line *At TTCH7+9 (after MOVEI Q2,0(1)) add 3 lines: IPTT,< CALL TIPCHK ; See if IP link... JRST [ CALL TIPCH7 ; Process it there JRST TTCH7]> *At TTCH7X+2 (after CALL TTYQOC) add one line: IPTT,< CALL TIPQOC> ; Start output to IP link line *At TTYSTC, add two lines: IPTT,< CALL TIPCHK ; IP link? RET> ; Yes, never XOFF ---------------------------------------- You will also need the TTYSRV submodule TTIPDV.MAC, available via ANONYMOUS FTP from PS:TTIPDV.MAC on CMU-CS-C. This should be assembled with TTYSRV before TTPHDV.MAC. Note that as currently written, TTIPDV has the tty number of the IP link line wired in as "20". This may be set by changing the value of location TTIPLN, located in TTIPDV (this should really be set by the INTERNET.ADDRESS file, but since we don't use the tty line interface, I haven't gotten around to making the necessary changes to MNETDV.MAC). You will need to add a line to INTERNET.ADDRESS such as: TTY#0, 192 5 255 2,SERIAL,PACKET-SIZE:576,LOGICAL-HOST-MASK:0 0 0 0 where you should substitute your site's address for "192 5 255 2". Please let me know how this works and if you have any problems with it. --Vince ---------------------------------------- ;TTIPDV.MAC.1, 15-Mar-84 11:30:28, Edit by VAF ;This code implements sending and receiving of IP packets over a serial line, ;as described in the appendix of RFC891. It should only be used when no better ;interface is available... This code could stand some optimization, but since ;it needs to be done in a hurry, it will have to do. SUBTTL TTIPDV - IP front end terminal device COMMENT ~ +-----------------------------------------------------------------------+ | | | Copyright (C) 1984,1987 Vincent A. Fuller | | | | This software, in source and binary form, is distributed free of | | charge. The binary form of this software may be incorporated into | | public-domain software and the source may be used for reference | | purposes. Copies may be made of the source provided this copyright | | notice is included. Wholesale copying of the routines in this | | software or usage of this software in proprietary product without | | prior permission is prohibited. | | | +-----------------------------------------------------------------------+ ~ .CHDLE==20 ;DLE character: used to indicate control code .CHSTX==2 ;STX - start of message .CHETX==3 ;ETX - end of message MAXPKZ==<^D576*2+4> ;Max IP packet + padding + encapsulation MAXPKX==</4> ;Word count of it IPKDAT==:PKTELI-LCLPKT ;Offset in IP buffer of packet data RSI TTIPLN,<20> ;The IP link line number RSI TIPLCH,<-1> ;Last input character RSI TIPCCH,<-1> ;Current input character RS TIPIFL ;Flag if TTY initialized RS TIPIPO ;Flag if IP interface is on RS TIPMSZ ;Max output packet size of interface RS TIPNCT ;NCT address of interface RS TIPOQT ;Output line quota RS TIPOSZ ;Number of bytes remaining to output RS TIPOFL ;Flag indicating outout done acknowledged ok RS TIPOWT ;Flag indicating output pending RS TIPOAD ;Address of IP output packet RS TIPOPT ;Byte pointer into output packet RS TIPIAD ;Buffer address of input packet RS TIPIPT ;Byte pointer into input packet RS TIPISZ ;Input packet bytes left RS TIIMNY ;Number of input packets received RS TIQMNY ;Number of DTEQ's done RS TIDMNY ;Number of DTE output done interrupts RS TIOMNY ;Number of complete output packets sent RS TIEMNY ;Number of errors RS TIPINB ;Number of times no IP buffers available RS TIPOBF,MAXPKX ;Output buffer RSI TIPSPD,<> RSI TIPSPV,<,> SUBTTL TTCH7 processing for IP line RESCD ;Called from scheduler context ;Called when a character for the IP line is removed from BIGBUF. ;Accepts: ; T1/ Character ; T2/ Internal line number (must agree with TIPLIN) TIPCH7: SKIPE TIPIFL ;TTY initialized yet? SKIPN TIPIPO ;And IP interface on? RET ;Nope... Can't do input yet ANDI T1,377 ;Only 8 bits, please MOVEM T1,TIPCCH ;Save current character MOVE T2,TIPLCH ;Get last character read SKIPN TIPIAD ;Do we have a input packet yet? CALLRET TIPIST ;Maybe start input now MOVEM T1,TIPLCH ;Update last character now CALL TIPCDL ;Check for DLE RET ;Yes - handled it, so done IDPB T1,TIPIPT ;Add character to input packet SOSL TIPISZ ;Check for size overflow RET ;OK BUG.(CHK,TIPISX,TTYSRV,HARD,) CALLRET TIPIRS ;Reset input ;Checks for DLE as last character and process current character specially. ;Assumes:T1/ Current character, T2/ Previous character ;Returns +2: Normal character - process as pkt data ; +1: Special processing done. TIPCDL: CAIN T2,.CHDLE ;Was last character a DLE? IFSKP. ;Nope. Probably don't need to do anything CAIE T1,.CHDLE ;If current is DLE, then just eat it AOS (P) ;Nope. Keep the character RET ENDIF. CAIE T1,.CHDLE ;Is this a quoted DLE? IFSKP. ;Yes... SETZM TIPLCH ;Fake last character, since not really DLE RETSKP ;Treat it as a normal character ENDIF. CAIN T1,.CHDEL ;Delete? RET ;Yes. Padding - flush it CAIN T1,.CHETX ;End-of-message? JRST TIPIDN ;Yes - input done, then BUG.(CHK,TIPICX,TTYSRV,HARD,,<>) JRST TIPIRS ;Reset input ;Come here when received input, but no packet buffer allocated yet. We check ;to see if it looks like there is a packet coming in, and allocate a buffer ;if necessary. Assumes: T1/ input byte, T2/ last input byte TIPIST: CAIN T2,.CHDLE ;Was it DLE? CAIE T1,.CHSTX ;And is this start-of-message? JRST TTIPNS ;Not yet... Update last character & quit SKIPE TIPIPO ;Interface on? CALL GETBUF ;Can I get a packet buffer? CALLRET TTIPNB ;Nope. Punt incoming character MOVEM T1,TIPIAD ;Save buffer address ADDI T1,IPKDAT ;Point to data area of pkt buffer TLO T1,540000 ;Make an 8-bit global pointer to pkt buffer MOVEM T1,TIPIPT ;And save the pointer MOVE T1,TIPMSZ ;Get max packet size for interface MOVEM T1,TIPISZ ;Save as bytes left in input packet MOVE T1,TIPCCH ;Get current input character TTIPNS: MOVEM T1,TIPLCH ;Update last character seen RET ;And return ;Come here when starting input of a packet, but no IP buffers available. ;We have to drop the packet, in this case. TTIPNB: SETOM TIPLCH ;Reset to pre-initial DLE state ; JRST TIPERR ;And increment error count ;Record network errors. Increments count of them. TIPERR: AOS TIEMNY ;Bump count RET ;And done ;Check if a line is really the IP line. ;Accepts T2/ Line number ;Returns +1 if it is the IP line (TTIPLN) ;Returns +2 if it isn't, or it isn't turned on TIPCHK: SAVELN HRRZS T2 ;Make line number SKIPE TIPIPO ;Is the IP interface on? CAME T2,TTIPLN ;Is it our line number? AOS (P) ;Setup skip return... RET ;Return ;Initialize the IP receive line and associated database. Sets line type and ;turns on multinet interface. Called from main TTYSRV initialization code. TIPINI: SKIPE FEFLG ;Not in primary protocol? SKIPE TIPIFL ;Or done this already? RET ;Then just punt SAVEAC ;Multinet may need this... MOVE T2,TTIPLN ;Get line number BLCAL. TTDTEQ,<[0],[.DFTOL],[0],[.DFTOO]> ;Turn line on BLCAL. TTDTEQ,<[0],[.DFMSG],[0],[1]> ;Turn off system messages BLCAL. TTDTEQ,<[0],[.DFSPD],[6],TIPSPD> ;Set linespeed BLCAL. TTDTEQ,<[0],[.DFXEN],[0],[0]> ;Disable XON/XOFF processing LOAD T1,TSFMC,(T2) ;Get initial line allocation MOVEM T1,TIPOQT ;Remember it for output SETONE TTIGI,(T2) ;TOPS-20 should ignore input on this line SETOM TIPIFL ;Say TTY initialization done SKIPE P1,TIPNCT ;NCT setup yet? CALL TIPON ;Turn on IP interface now RET ;Come here when RSX20F reloaded. Need to reset IP line state TIPRST: EA.ENT ;Get into section 1 SETZM TIPIFL ;Say not initialized yet CALL TIPINI ;Initialize the line CALL RETOU1 ;Flush current output buffer TIPIRS: SETZ T1, ;Setup zero EXCH T1,TIPIAD ;Get input buffer & clear it CALL RETBUF ;Return it RET ;Special processing done SUBTTL Multinet interface SWAPCD ;TNTINI (NTINI) - Network Initialization ;Set up the NCT for the tty line. ;Takes P1/ pointer to NCT ;Returns +1 always ;Clobbers T1-T4 TNTINI::MOVE T1,NTPSIZ(P1) ;Get max packet size for interface CAIG T1,MAXPKZ ;Smaller than our buffer size? IFSKP. ;Nope BUG.(CHK,TIPOSX,TTYSRV,SOFT,) RET ;Punt ENDIF. MOVEM T1,TIPMSZ ;Save max packet size MOVEM P1,TIPNCT ;Save NCT address... CALL TIPINI ;Initialize line, if necessary RET ;TNTKIL (NTKILL) - Shutdown the interface ;This routine is a no-op if the interface doesn't exist, or is already off. ;Returns +1 always TNTKIL::SKIPN TIPIPO ;Is interface on? RET ;Nope - don't bother cycling network... SETOM NTSTCH(P1) ;Set cycling flag SETZM NETON(P1) ;State of network is off SETZM NTRDY(P1) ;State of interface is off SETZM NTORDY(P1) ;Output not possible SETZM TIPIPO ;Don't accept any more packets RET ;TIPON (NTRSRT) - Network restart instruction ;Set address mask and enable reception ;Takes P1/ pointer to NCT ;Returns +1 always TIPON:: SKIPE TIPIPO ;Already on? RET ;Don't cycle again SKIPE TIPIFL ;TTY line initialized yet? SKIPN TIPNCT ;And NCT setup? RET ;Nope - can't turn interface on, then SETOM NTSTCH(P1) ;Set change of state SETOM NETON(P1) ;Network is on SETOM NTORDY(P1) ;Output is on SETOM NTRDY(P1) ;Net is ready SETOM TIPIPO ;Start accepting packets CALL RETOU1 ;Get rid of stuck output buffer... AOS JB0FLG ;Tell Multinet to run RET ;TIPOOK (NTOTOK) - Net output okay ;Called T1/ (first hop) destination address ; T2/ pointing to an Internet buffer ; P1/ address of NCT ;Returns +1 no can do, T1/ ICMP error code ; +2 success, encapsulation done ;This routine is a NO-OP for now, since there's nothing to do. TIPOOK::AOS (P) ;Make a skip return RET ;That's it ;TIPOBG (NTOSRT) - Start IP output. ;Get packet from IP output queue and attempt to send it. ;Takes P1/ pointer to NCT ;Copies packet to section 0 output buffer and DTEQ's first part. ;Returns +1 always ;TIPQOC is alternate entry, called every 20ms from scheduler RESCD ;Called from interrupt level TIPQOC::SKIPE TIPOAD ;Already doing output? JRST TIPORT ;Yes - perhaps waiting to do more SAVEAC ;Preserve NCT register MOVE P1,TIPNCT ;And set it up TIPOBG::SKIPN TIPOAD ;Output already in progress? SKIPN NTIOBO(P1) ;Or nothing queued for output? RET ;Don't start anything NOSKED ;Lock out TIPQOC CALL GETOUT ;Get first output packet from output queue JRST [ OKSKED ;Nothing there, or lost timing race - punt RET] SETZM TIPOFL ;Clear output flag MOVEM T1,TIPOAD ;Setup output address OKSKED XMOVEI T2,IPKDAT(T1) ;Point at IP packet itself LOAD T4,PIPL,-LCLPKT(T1) ;Get packet length, in bytes TLO T2,540000 ;Make 8-bit global pointer to packet MOVNS T4 ;Make negative byte count HRLZS T4 ;Make AOBJN MOVE T1,[POINT 8,TIPOBF] ;Point at output buffer MOVEI T3,.CHDLE ;DLE pading IDPB T3,T1 ;Put at start MOVEI T3,.CHSTX ;Start-of-text IDPB T3,T1 ;... ADDI T4,2 ;Account for characters DO. ILDB T3,T2 ;Get char from IP buffer IDPB T3,T1 ;Append to output buffer CAIE T3,.CHDLE ;Is this a DLE? IFSKP. ;Yes - must quote it ADDI T4,1 ;Account for extra char of output IDPB T3,T1 ;And quote the DLE with another DLE ENDIF. AOBJN T4,TOP. ;Increment count, decrement IP count, loop ENDDO. MOVEI T3,.CHDLE ;Make encapsulation IDPB T3,T1 ;Append to output buffer MOVEI T3,.CHETX ;End-of-text IDPB T3,T1 ;... ADDI T4,2 ;Account for the characters HRRZM T4,TIPOSZ ;Save output byte count MOVE T1,[POINT 8,TIPOBF] ;Make output pointer MOVEM T1,TIPOPT ;Set it up ;Routine to send next part of packet. Drops in from above (for first part) and ;called during 20ms scheduler cycle from TIPQOC for successive parts. TIPOP1: MOVE T3,TIPOSZ ;Get count of bytes left to send MOVE T1,T3 ;Make a copy of the count left CAMLE T3,TIPOQT ;Less than amount of quota left? MOVE T3,TIPOQT ;Nope. Use quota count, then SUB T1,T3 ;Compute new count MOVEM T1,TIPOSZ ;And update it MOVE T4,T3 ;Copy size we are sending ADJBP T4,TIPOPT ;Compute new pointer EXCH T4,TIPOPT ;Get pointer, update new pointer MOVSI T1,TIPODN ;Output done location HRR T1,MSTRDT ;To master DTE MOVX T2,<.DFHSD,,.FEDLS> ;Sending string data, to data link HRL T3,TTIPLN ;Line number (RH has # chars already) TXO T3,DTBYTM ;Force byte mode ;(T4 already setup with byte pointer) CALL FIXARG ;Fix args NOSKD1 ;Force DTEQ to not block CALL DTEQ ;Queue up output string JRST TIPOXX ;Failed... OKSKD1 AOS TIQMNY ;Increment DTEQ output count RET ;And done for now ;Here from TIPQOC when output already in progress - maybe time to continue TIPORT: SKIPN TIPOWT ;Output waiting? RET ;Nope. Done SETZM TIPOWT ;Output no longer waiting JRST TIPOP1 ;Go send next part of packet ;Come here when output to line complete. ;Called from DTE interupt level. ;Doesn't do anything, since we wait for RSX acknowledge of output done TIPODN: AOS TIDMNY ;Increment count of DTE output dones SETOM TIPOFL ;Remember that we saw this RET ;... ;Output failed. BUGCHK & release packet TIPOXX: BUG.(CHK,TIPDTX,TTYSRV,SOFT,) OKSKD1 ;Allow scheduling... JRST TIPOAB ;Abort the packet (what else is there to do?) ;Come here on output buffer empty interrupt from RSX20F ;T2/ internal line number of tty ;Updates TIPOQT to full state and start next segment or next packet of output. TIPDON: SKIPE TIPOAD ;Output in progress? SKIPN TIPOFL ;And DTE done seen yet? RET ;No. Do nothing SETZM TIPOFL ;Clear DTE done seen SAVELN ;Save tty state LOAD T1,TSFMC,(T2) ;Get allocation MOVEM T1,TIPOQT ;Update it SKIPG TIPOSZ ;Any IP bytes left? JRST TIPODD ;Nope. All done with packet SETOM TIPOWT ;Flag waiting to do output RET ;And return - 20ms code will do output later TIPODD: AOS TIOMNY ;Increment count of sent packets TIPOAB: EA.ENT ;Enter extended section CALL RETOU1 ;Release output buffer back to internet RET ;Done SUBTTL Utilities for manipulating IP queues. ;Note: A system which has both an NFE and a TTY interface should not have these ;defined here. RESCD ;May be called from scheduler level ;Come here when finished reading input packet. Falls through to IPAPP. TIPIDN: AOS TIIMNY ;Increment count of input packets SETZ T1, ;Clear EXCH T1,TIPIAD ;Get input buffer address, clear it ; JRST IPAPP ;Fall through ;IPAPP - append an IP packet to the IP input queue ;Called in scheduler context ;Takes T1/ pointer to buffer ;Clobbers T1,T3 IPAPP: PIOFF ;Make sure PI system is off (lock out AN20) MOVE T3,INTIBI ;Get input queue tail pointer JUMPN T3,IPAPP0 ;Queue not empty, go append packet MOVEM T1,INTIBO ;Was empty. This is only item now. TRNA ;Make head and tail be same packet IPAPP0: STOR T1,NBQUE,(T3) ;Make old packet point to newest packet MOVEM T1,INTIBI ;Set new tail pointer AOS INTFLG ;Cause Internet process to notice it PION ;Turn PI system back on RET ;Return to caller ;GETBUF - claim and check a free Internet buffer ;Call at interrupt level ;Returns +1 no free buffers, Internet fork prodded ; +2 good buffer claimed, T1/ pointer to buffer ;Clobbers T1-T4 GETBUF::PIOFF ;Lock out rest of machine SOSGE INTNFI ;Any buffers? AOSA INTNFI ;No, fix count TRNA ;Yes, skip into main code JRST GETBFX ;Go poke Internet fork MOVE T1,INTFRI ;Get first buffer on queue TRNN T1,-1 ;Null queue is a bug BUG.(HLT,ENTBUF,TTYSRV,SOFT,) LOAD T2,NBQUE,(T1) ;Get pointer to next buffer SKIPE T2 ;If non-zero SETSEC T2,INTSEC ;Then make an extended address MOVEM T2,INTFRI ;Update head of free queue PION ;Let rest of machine run again SETZRO NBQUE,(T1) ;Clear pointer to next buffer CAML T1,[XWD INTSEC,INTFRE] ;Range check the pointer CAMLE T1,[XWD INTSEC,INTFRE+INTFSZ-1] ;... BUG.(HLT,ENTBF1,TTYSRV,SOFT,) RETSKP ;Good return to caller GETBFX: PION ;Turn PI system back on AOS INTFLG ;Signal work to do SETZ T1, ;Return 0 pointer AOS TIPINB ;Increment no buffer count ; BUG.(INF,TIPBFX,TTYSRV,SOFT,) ;Complain RET ;Return to caller ;RETBUF - release an Internet buffer to the Internet free pool ;Call at interrupt level ;Takes T1/ buffer pointer ;Returns +1 always ;Clobbers T1-T2 RETBF0: EA.ENT ;Get into section 1 RETBUF::MOVE T2,T1 ;Copy for indexing below PIOFF ;Maintain queue integrity (lock out AN20) EXCH T1,INTFRI ;Release to Internet STOR T1,NBQUE,(T2) ;... AOS INTNFI ;Count another free buffer PION ;Let rest of machine run RET ;Return to caller ;GETOUT - pull a packet off the Internet output queue ;Takes P1/ pointer to NCT ;Returns +1 no packets to be sent ; +2 success, T1/ address of packet to send ;Clobbers T1-T2 GETOUT: PIOFF ;Interlock with PI system SKIPN T1,NTIOBO(P1) ;Load pointer to head of Internet queue JRST GETOU1 ;Nothing to do, quit LOAD T2,NBQUE,(T1) ;Get successor packet SKIPE T2 ;Don't extend if nil SETSEC T2,INTSEC ;Make extended address MOVEM T2,NTIOBO(P1) ;Update queue header SKIPN T2 ;Now a null queue? SETZM NTIOBI(P1) ;Yes, clear tail pointer as well SETZRO NBQUE,(T1) ;Clear links in dequeued packet AOS (P) ;Prepare skip return GETOU1: PION ;Reallow PI now that queues are safe RET ;Good return to caller ;RETOUT - Release current output buffer. ;Returns +1, always, with buffer put on Internet free list RETOU0: EA.ENT ;Get into extended section, first RETOU1: SKIPN T1,TIPOAD ;Do we have an output buffer? RET ;Nope. Nothing to do, then SETZM TIPOAD ;Nuke it RETOUT: PIOFF ;Turn off interrupts through here MOVE T2,T1 ;Make a copy of it EXCH T1,INTNFB ;Put this buffer on the free list STOR T1,NBQUE,(T2) ;And link back rest of list AOS INTFLG ;Make internet process notice this PION ;Allow interrupts again RET ;And return RESCD ;Default for TTYSRV ------- 26-Jan-88 13:15:40-PST,781;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SCORE.STANFORD.EDU with TCP; Tue 26 Jan 88 13:15:16-PST Date: Tue 26 Jan 88 16:19:43-EST From: Ken Rossman Subject: TOPS FTP update needed To: TOPS-20@SCORE.STANFORD.EDU Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 Message-ID: <12369759749.23.SY.KEN@CU20B.COLUMBIA.EDU> I badly need to upgrade my hopelessly outdated TOPS-20 FTP software here on CU20B. Last I checked, there were two major versions floating around. One was from CMU, and another from Stanford. Are these still around and available for pilfering. If so, where can find them? Are there any other versions anywhere worth considering? Thanks. /Ken ------- 26-Jan-88 19:05:08-PST,636;000000000001 Mail-From: VAF created at 26-Jan-88 19:04:37 Date: Tue 26 Jan 88 19:04:37-PST From: Vince Fuller Subject: Re: TOPS FTP update needed To: sy.Ken@cu20b.columbia.edu cc: TOPS-20@Score.Stanford.EDU In-Reply-To: <12369759749.23.SY.KEN@CU20B.COLUMBIA.EDU> Office: Pine Hall 147 Phone: 415-725-1392 Message-ID: <12369822537.14.VAF@Score.Stanford.EDU> The CMU FTP is available for pilferage from PS:*.* on Internet host C.CS.CMU.EDU. It should probably be noted that I am no longer available to maintain this program on a regular basis due to a change of employment... --Vince ------- 28-Jan-88 00:30:34-PST,2082;000000000000 Return-Path: Received: from SRI-NIC.ARPA by SCORE.STANFORD.EDU with TCP; Thu 28 Jan 88 00:28:45-PST Date: Thu, 28 Jan 88 00:33:24 PST From: Mark Lottor Subject: another cause of IPFREE bugs To: tops-20@SCORE.STANFORD.EDU Message-ID: <12370144534.15.MKL@SRI-NIC.ARPA> In IPIPIP in routine RETPKT. From the comment: ;RETPKT Release packet storage. ;If a full size packet is being released and we are low on IMP input ;buffers, the packet will be used as an input buffer. Otherwise, it ;gets released to free storage. The routine first checks to see if the "FULL SIZE PACKET" bit is on, and if it is it assumes the packet is full size. Unfortunately there is a bug somewhere in the monitor that is either setting the full size bit incorrectly, or setting the packet length word incorrectly. We hit this condition today (after having the bugchk installed for many months), and the supposed full size packet was only 40 words. If this packet gets reused as an input buffer it's almost a sure IPFREE bughlt. The bugchk code follows and will save you from the bughlt. I have not found the actual bug yet. We run a version of the Stanford 6.1 monitor. ---------------------------------------------------------------------- RETPKT::JE PFSIZ,(PKT),RETPK1 ; Is it a full size packet? CAML PKT,[INTSEC,,BF1822] ; Is this an NI buffer? CAML PKT,[INTSEC,,BF1822+] ; ? SKIPA ; no JRST RETPK2 ; yes. always release. MOVE T1,INTNFI ; Yes. Get number currently around CAML T1,INTNIB ; Less than required? JRST RETPK1 ; No. ifn nicsw,< push p,t1 hlrz t1,-1(pkt) ;get buffer header word (length field) trz t1,400000 caml t1,maxwpm ;big enough? jrst retpk9 ;yes, its ok BUG.(CHK,RETSPK,IPIPIP,SOFT,,<>,< Cause: The monitor has detected an input buffer that is not of the maximum size required by this routine. >) pop p,t1 jrst retpk1 ;release bogus packet retpk9: pop p,t1 >;ifn nicsw ------- 28-Jan-88 08:59:44-PST,1082;000000000000 Return-Path: <@CUNYVM.CUNY.EDU,@WESLEYAN.BITNET:DBIGELOW@EAGLE.WESLEYAN.EDU> Received: from CUNYVM.CUNY.EDU by SCORE.STANFORD.EDU with TCP; Thu 28 Jan 88 08:53:46-PST Received: from WESLEYAN.BITNET by CUNYVM.CUNY.EDU ; Thu, 28 Jan 88 11:57:32 EST Date: 28-JAN-1988 11:31:37.08 From: Douglas Bigelow Subject: Three meg memory upgrade To: TOPS20@SCORE.STANFORD.EDU Wesleyan has two 2060s, soon to be reduced to one. However, we're trying to get another five years out of the remaining system and we're considering a mid/end life kicker. I'm trying to pick up an MCA25 cache upgrade, and I'm considering a boost from two meg of MG memory to three. The question is, how much of a performance boost will an extra megaword give us? Is it worth the estimated $15K or so it will cost me on the used market? I'd appreciate any opinions from anyone who has gone from 2M to 3M and paid any attention to the results. Second, do any of you have any memory or cache for sale? Thanks in advance, Doug 28-Jan-88 09:10:08-PST,752;000000000000 Return-Path: Received: from GSB-HOW.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 28 Jan 88 09:05:35-PST Date: Thu 28 Jan 88 09:07:57-PST From: Eric M. Berg Subject: Re: TOPS FTP update needed To: sy.Ken@cu20b.columbia.edu cc: TOPS-20@Score.Stanford.EDU In-Reply-To: <12369759749.23.SY.KEN@CU20B.COLUMBIA.EDU> Phone-#s: 415/723-1576 (GSB-CF), 415/329-9940 (home) Message-ID: <12370238206.163.A.ERIC@GSB-HOW.Stanford.EDU> One version of the Stanford sources seem to be in ps: on Score. You need to be in the appropriate user-group in order to be able to grab them; most systems staff at other sites with guest accounts on Score appear to be in that group. ------- 28-Jan-88 11:17:30-PST,1200;000000000000 Return-Path: <@SUMEX-AIM.Stanford.EDU:MRC@PANDA.PANDA.COM> Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 28 Jan 88 11:16:37-PST Received: from PANDA.PANDA.COM by SUMEX-AIM.Stanford.EDU with Cafard; Thu, 28 Jan 88 11:19:42 PST Date: Thu, 28 Jan 88 09:47:55 PST From: Mark Crispin Subject: Re: another cause of IPFREE bugs To: MKL@SRI-NIC.ARPA cc: tops-20@SCORE.STANFORD.EDU In-Reply-To: <12370144534.15.MKL@SRI-NIC.ARPA> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12370245481.7.MRC@PANDA.PANDA.COM> Good detective work, Mark! Who knows, maybe this is "the" bug... I think you may be able to use the following version of your fix, which is just a little more elegant... IFN PANDASW,< ;[2] LDB T2,[POINT 17,-1(PKT),17] ; Get length field from buffer header CAML T2,MAXWPM ; Big enough? IFSKP. BUG.(CHK,RETSPK,IPIPIP,SOFT,,<>,< Cause: The monitor has detected an input buffer that is not of the maximum size required by this routine. >) JRST RETPK1 ; Release bogus packet ENDIF. >;IFN PANDASW ------- 29-Jan-88 10:57:47-PST,1452;000000000000 Return-Path: Received: from lindy.stanford.edu by SCORE.STANFORD.EDU with TCP; Fri 29 Jan 88 10:54:57-PST Received: by lindy.stanford.edu; Fri, 29 Jan 88 11:00:23 PST Received: by Forsythe.Stanford.EDU; Fri, 29 Jan 88 10:46:16 PST Received: from ADMIN by UcEdu.UNCA.AdhocNet.CA with DECNET ; Fri, 29 Jan 88 09:51:22 MST Date: Fri 29 Jan 88 09:47:32-MST From: RMF%ADMIN%UNCAEDU.BITnet@forsythe.stanford.edu Subject: MM To: tops-20@score.stanford.edu Phone: (403) 240-6052 Organization: Mount Royal College; Computer Operations Postal-Address: 4825 Richard Rd. S.W.; Calgary, Alberta, T3E 6K6 Message-Id: <12370496631.46.RMF@ADMIN> I am running an old version of MM (v 6.1(1144) and have suddenly come across this error '?node name cache overflow'. I have been continually updating the domains.txt with BITnet nodes as I need them. What can I do to get rid of this error message? (besides of course removing nodes from my domains file). I know somebody will no doubt say 'get the latest version that uses the new domain resolver'. Don't worry, the cheque is in the mail for it. /Russ ----- Russell M Forster DECnet: RMF @ { Admin | Flux | Stasis | Ins } BITnet: RForster @ UncaEdu.BITnet ARPA: Oc.Russ @ CU20B.Columbia.Edu USEnet: uunet!calgary!vaxd!forster ------- 5-Feb-88 16:53:56-PST,462;000000000000 Return-Path: Received: from MATHOM.CISCO.COM by SCORE.STANFORD.EDU with TCP; Fri 5 Feb 88 16:52:07-PST Date: Fri 5 Feb 88 16:57:09-PST From: Len Bosack Subject: Looking for a program: PANTT To: TOPS20@SCORE.STANFORD.EDU Message-ID: <12372420771.14.BOSACK@MATHOM.CISCO.COM> PANTT is a project tracker written by Peter Hurley at DEC. Does anyone have an FTP-able copy? Thanks, Len Bosack ------- 6-Feb-88 20:39:16-PST,1800;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SCORE.STANFORD.EDU with TCP; Sat 6 Feb 88 20:36:40-PST Date: Sat, 6 Feb 1988 21:41 MST Message-ID: From: "Frank J. Wancho" To: TOPS20@SCORE.STANFORD.EDU cc: WANCHO@SIMTEL20.ARPA Subject: BSPLIT - A BBOARD file maintainer Like most sites, I use a nightly batch job containing a string of MM steps with a DELETE BEFORE -n setup to keep my BBOARD files down to "reasonable" sizes. The value for n has always been an empirical guess, usually wrong, and sometime a problem if done in one MM process instead of one for each. For those of you who keep your BBOARD files in separate subdirs and keep old messages as well, I suggest getting BBTrim from CU20B. However, for the rest of us who do not care to keep old messages, I offer BSPLIT, based on MSPLIT. BSPLIT steps down through a mail file under exclusive use, message by message, until it passes through enough messages such that the remainder of the file is less than some hardwired value, default is 100 disk pages. The file is then rewritten with that remainder, and the saved last write date/times are restored. Files already under the limit are left alone. One advantage to this program, besides being small and fast, is the guesswork for the value of n is gone. Because it retains the original last write date/times, the BBOARD program will no longer have to unnecessarily read in a file to check the messages because the MM method was the last to update that information. Source is in SRC:BSPLIT.MAC on this host, and is small enough to mail to off-net requestors. As usual, please send back any improvements for redistribution. --Frank 9-Feb-88 10:29:22-PST,4598;000000000000 Return-Path: Received: from SCIENCE.UTAH.EDU by SCORE.STANFORD.EDU with TCP; Tue 9 Feb 88 10:22:34-PST Date: Tue 9 Feb 88 11:27:44-MST From: "Nelson H.F. Beebe" Subject: Re: BSPLIT - A BBOARD file maintainer To: tops-20@SCORE.STANFORD.EDU cc: Beebe@SCIENCE.UTAH.EDU In-Reply-To: X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 Message-ID: <12373398458.14.BEEBE@SCIENCE.UTAH.EDU> I'd been wondering whether to post this, and Frank Wancho's submission indicates there may be interest in other places too. About 6 weeks ago, I wrote a PCL procedure to apply MSPLIT to our bboards (having tired of doing it by hand). We always preserve the old contents as bbdname_yymmdd.txt, where yymmdd is the stamp of the last message in the file, so a directory listing shows the files chronologically as well as alphabetically (I never liked schemes like "bbdname_1st_qtr.txt"). BBDSPLIT runs in a nightly batch job. COMMAND BBDSPLIT ( NOISE "large mail file(s)"; FILELIST (INPUT, DEFAULT_DEV "DSK", DEFAULT_NAM "*", DEFAULT_EXT "TXT") ); !----------------------------------------------------------------------- ! Purpose: ! Split mail or bulletin board files which are larger than 250 ! disk pages. The MSPLIT utility will split FOO.TXT into FOO.1, ! FOO.2, ... (each of size ~240 pages), + FOO.TXT (the remainding ! most recent messages). FOO.1 is copied to OLD:FOO_yymmdd.TXT, ! so that successive such archives will by named chronologically; ! yymmdd is the year, month, day of the first message in FOO.TXT ! (and presumably close to the last message in FOO.1). If the ! creation of the archive file is successful, then FOO.1 is ! expunged. It is expected that this command will be executed in ! a nightly batch job to ensure that bulletin board files never ! get much over 250 pages. ! ! Usage: ! BBDSPLIT filelist (default *.TXT) ! ! Remarks: ! There is no provision for handling FOO.2 et al, but if such a ! file is found to exist, the procedure will abort, and the job ! can be handled manually. ! ! Author: ! Nelson H.F. Beebe, Center for Scientific Computing, South ! Physics Building, University of Utah, Salt Lake City, UT 84112. ! ! Date: ! [15-Dec-87] ! !------------------------------------------------------------------------ BEGIN INTEGER count; INTEGER handle; INTEGER tad_value; ! internal date and time value; INTEGER year,month,month_day,week_day,hour,minute; STRING arc_file; STRING line; STRING old_file; STRING second_file; DO IF $FileInfo_I($FILEL, $FBSIZ) > (5 * 512 * 250) THEN BEGIN DISPLAY "[Splitting " + $FILES + "]"; INVOKE "BBD:MSPLIT.EXE"; TYPEIN $FILEL; old_file = $File_Dev($FILEL) + ":" + "<" + $File_Dir($FILEL) + ">" + $File_Nam($FILEL) + ".1"; second_file = $File_Dev($FILEL) + ":" + "<" + $File_Dir($FILEL) + ">" + $File_Nam($FILEL) + ".2"; ! display "%%% Debug: old_file = " + old_file; count = 0; DO !Wait for completion; PCL lacks a fork wait, sigh... BEGIN CALL $Wait(5); count = count + 1; IF count > 12 THEN ABORT "MSPLIT apparently did not create " + old_file END UNTIL $IsFile(old_file) <> 0; IF $IsFile(second_file) <> 0 THEN ABORT "MSPLIT: Cannot handle split into more than one file--found " + second_file; DOCOMMAND ORIGINAL "UNIX:HEAD -1 " + $FILEL + " >msplit.tmp"; handle = $Open("msplit.tmp",$Input); line = $Read(handle); call $Close(handle); DOCOMMAND ORIGINAL "delete msplit.tmp"; ! DISPLAY "%%% Debug: first line = " + line; call $ExpandTad($InputTad(line), year,month,month_day,week_day,hour,minute); ! DISPLAY "%%% Debug: " + ! " year: " + $String(year) + ! " month: " + $String(month) + ! " month_day: " + $String(month_day) + ! " week_day: " + $String(week_day) + ! " hour: " + $String(hour) + ! " minute: " + $String(minute); arc_file = "OLD:" + $File_Nam($FILEL) + "_" + $String(year - 1900) + $String(100 + month + 1)[2:*] + $String(100 + month_day + 1)[2:*] + ".txt"; DOCOMMAND ORIGINAL "COPY " + old_file + " " + arc_file; IF $IsFile(arc_file) <> 0 THEN DOCOMMAND ORIGINAL "DELETE " + old_file + ", EXPUNGE " ELSE ABORT "MSPLIT: could not save " + old_file + " as " + arc_file END UNTIL $NextFile = 0 END; ! BBDSPLIT ------- 9-Feb-88 10:31:27-PST,794;000000000000 Return-Path: Received: from RADC-TOPS20.ARPA by SCORE.STANFORD.EDU with TCP; Tue 9 Feb 88 10:22:43-PST Date: Tue 9 Feb 88 13:11:19-EST From: Donna Lynch Subject: Spell To: tops-20@SCORE.STANFORD.EDU cc: admin@RADC-TOPS20.ARPA Message-ID: <12373395469.5.ADMIN@RADC-TOPS20.ARPA> Is there a version of SPELL for TOPS20? Is anyone familiar with the one we are currently running? I don't know too much about it. It was here long before I was. It was apparently written by Ralph Gorin with mods by CMU. The EXE file is dated 7-Sep-79. It has curiously stopped working. I don't know if I deleted a file it might be looking for or what. It doesn't stop and show the misspelled word anymore. Any help? Thanks, Donna ------- 9-Feb-88 14:02:10-PST,1340;000000000000 Return-Path: Received: from lindy.stanford.edu by SCORE.STANFORD.EDU with TCP; Tue 9 Feb 88 13:59:53-PST Received: by lindy.stanford.edu; Tue, 9 Feb 88 14:05:55 PST Received: by Forsythe.Stanford.EDU; Tue, 9 Feb 88 14:04:24 PST Received: from ADMIN by UcEdu.UNCA.AdhocNet.CA with DECNET ; Tue, 9 Feb 88 14:54:48 MST Date: Tue 9 Feb 88 14:46:37-MST From: RMF%ADMIN%UNCAEDU.BITnet@forsythe.stanford.edu Subject: Autopatching PEP database To: tops-20@score.stanford.edu Phone: (403) 240-6052 Organization: Mount Royal College; Computer Operations Postal-Address: 4825 Richard Rd. S.W.; Calgary, Alberta, T3E 6K6 Message-Id: <12373434662.45.RMF@ADMIN> I have a problem, my PEP database is bge corrupted and lost. It seems that due to lack of foresight, I didn't manage to get one to tape. Does anyone have a PEP database to AP15 that I could get a copy of? Or, does someone know how to convence PEP that I have patches up to AP15 and continue on? If not, what was the first autopatch to patch 6.1? /Russ ----- Russell M Forster DECnet: RMF @ { Admin | Flux | Stasis | Ins } BITnet: RForster @ UncaEdu.BITnet ARPA: Oc.Russ @ CU20B.Columbia.Edu USEnet: uunet!calgary!vaxd!forster ------- 9-Feb-88 14:26:19-PST,1376;000000000001 Return-Path: Received: from lindy.stanford.edu by SCORE.STANFORD.EDU with TCP; Tue 9 Feb 88 14:24:38-PST Received: by lindy.stanford.edu; Tue, 9 Feb 88 14:30:24 PST Received: by Forsythe.Stanford.EDU; Tue, 9 Feb 88 14:19:24 PST Received: from ADMIN by UcEdu.UNCA.AdhocNet.CA with DECNET ; Tue, 9 Feb 88 15:04:26 MST Date: Tue 9 Feb 88 14:56:29-MST From: RMF%ADMIN%UNCAEDU.BITnet@forsythe.stanford.edu Subject: LAT's To: tops-20@score.stanford.edu Phone: (403) 240-6052 Organization: Mount Royal College; Computer Operations Postal-Address: 4825 Richard Rd. S.W.; Calgary, Alberta, T3E 6K6 Message-Id: <12373436459.45.RMF@ADMIN> Is there a JSYS that can be called that will return the LAT number and the Port number within that LAT. We are currently running PHOO from Columbia University (thanks Ken :-) ) and it does a terminal port to computer port trace back (translation we know what physical terminal is being used by whom). With the move to LAT's we lost that capability (or have we?) Any info would be appreciated. /Russ ----- Russell M Forster DECnet: RMF @ { Admin | Flux | Stasis | Ins } BITnet: RForster @ UncaEdu.BITnet ARPA: Oc.Russ @ CU20B.Columbia.Edu USEnet: uunet!calgary!vaxd!forster ------- 9-Feb-88 15:00:06-PST,721;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SCORE.STANFORD.EDU with TCP; Tue 9 Feb 88 14:58:21-PST Date: Tue 9 Feb 88 18:01:50-EST From: Ken Rossman Subject: Re: LAT's To: RMF%ADMIN%UNCAEDU.BITnet@FORSYTHE.STANFORD.EDU, tops-20@SCORE.STANFORD.EDU In-Reply-To: <12373436459.45.RMF@ADMIN> Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 Message-ID: <12373448354.136.SY.KEN@CU20B.COLUMBIA.EDU> I went hunting for a system call that would return the port number on a LAT box, but never did find one. Closest I came was the (unsupported) NTINF% Jsys, but that doesn't tell you port numbers on the box... /Ken ------- 10-Feb-88 11:42:07-PST,581;000000000000 Return-Path: Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 10 Feb 88 11:38:34-PST Date: Wed, 10 Feb 88 11:13:56 PST From: Mark Crispin Subject: Horoscope program To: TOPS-20@Score.Stanford.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12373669012.86.CRISPIN@SUMEX-AIM.Stanford.EDU> Does anyone have the old old library of Basic games still lying around? I'm looking for a horoscope program for a friend. ------- 10-Feb-88 17:33:20-PST,788;000000000000 Return-Path: Received: from MCC.COM by SCORE.STANFORD.EDU with TCP; Wed 10 Feb 88 17:31:41-PST Date: Wed 10 Feb 88 19:36:44-CST From: Clive Dawson Subject: TAPELOOK To: tops-20@SCORE.STANFORD.EDU Message-ID: <12373738699.36.AI.CLIVE@MCC.COM> Whenever I need to do some quick examination of magnetic tapes to check things like record lengths, etc., I generally use a utility called TAPELOOK which has been floating around various hosts for years. Now I have a need to look beyond the first record of each file, so I need to hack it a bit. Does anybody know where the source to TAPELOOK might be found, or can anybody recommend another general purpose tape utility to dump the contents of a random tape? Thanks, Clive ------- 11-Feb-88 08:32:15-PST,2844;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SCORE.STANFORD.EDU with TCP; Thu 11 Feb 88 08:30:35-PST Date: Thu 11 Feb 88 11:33:44-EST From: Ken Rossman Subject: Re: BBTRIM options To: WANCHO@SIMTEL20.ARPA, TOPS-20@SCORE.STANFORD.EDU cc: melissa@CUNIXC.COLUMBIA.EDU, sy.fdc@CU20B.COLUMBIA.EDU Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 Message-ID: <12373901993.136.SY.KEN@CU20B.COLUMBIA.EDU> Before the last -20 is shut down, I would hope *someone* there would take the time to accumulate all the local mods and neat hacks on to tape for the rest of us to continue to use. If such an archive isn't proposed to be kept at SCORE, then I would hope we get the opportunity here (along with all our other collections, except the KERMIT stuff which Frank and crew is more than welcome to keep current on his machines)... Since this topic has been touched on, I'd like to make a query to those remaining TOPS sites before our 20's are gone (in just a precious few months now). We have lots of nice things here that we've all spent lots of time developing, and which I'd sure hate to see die completely (I've spent a large part of my life developing code that is now on the verge of becoming totally useless to us here)... If I were to coordinate things here and group files together nicely into reasonably organized directory trees, would someone out there like to copy the whole mess over to their local machine(s) and be the keepers hereafter of whatever nice archives we have around here? I can stick them on tape and/or just point networked folks at the places to look on CU20B to pick things up here. Any takers? I have seem rumors of an MM implementation for Unix-like systems which Ken has mentioned on the TOPSUX list. Will it be made available to the world (unlike the SRI version)? More importantly, will there be an MMAILR/SMTJFN/MAISER to round out the package?? Even if it's only MM, I'd be interested in reverse porting it to TOPS20 to be able to handle arbitrarily large message composition and large mail files using KCC and its extended addressing option... Our C version of MM is still in alpha test here, but is looking pretty good so far. Runs fine under Unix at this point, and VMS porting will probably start within a few months, though I can make no promises about this. Under Unix, MM talks to sendmail for delivery. Under VMS, it will need another type of delivery workhorse to talk to. Perhaps a separate, generically written, mail delivery daemon system ought to be written to go along with MM, such that it could be ported, along with MM, to other OS's. But so such plans are in the works here at CU at this time. FYI, /Ken ------- 11-Feb-88 10:49:08-PST,744;000000000000 Return-Path: Received: from MACBETH.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Thu 11 Feb 88 10:49:05-PST Date: Thu 11 Feb 88 10:49:07-PST From: Rich Alderson Subject: version 7 training session To: su-tops-20@SCORE.STANFORD.EDU Message-ID: <12373926636.212.A.ALDERSON@MACBETH.STANFORD.EDU> Dave Lomatire, Jack Wong, and Ron Anderson of Digital are scheduled to come in next week (16-18 February) to install FT1. They want to have a training session on Thursday afternoon, 3:00 to 5:00, in Sweet 403 (the 4th floor conference room). Please let me know if you plan to attend so that we can be assured of handouts and such. Rich Alderson ------- 11-Feb-88 13:22:31-PST,790;000000000000 Mail-From: VAF created at 11-Feb-88 13:21:49 Date: Thu 11 Feb 88 13:21:48-PST From: Vince Fuller Subject: Re: BBTRIM options To: sy.Ken@cu20b.columbia.edu cc: WANCHO@SIMTEL20.ARPA, TOPS-20@Score.Stanford.EDU, melissa@cunixc.columbia.edu, sy.fdc@cu20b.columbia.edu In-Reply-To: <12373901993.136.SY.KEN@CU20B.COLUMBIA.EDU> Office: Pine Hall 147 Phone: 415-725-1392 Message-ID: <12373954434.31.VAF@Score.Stanford.EDU> One question - would you be interested in accumulating "nice things" developed at other sites? I, too, spend a number of years writing code which will soon be discarded (C.CS.CMU.EDU will probably be shut-off within the next year) and would be interested in contributing anything people might find useful. --Vince ------- 11-Feb-88 16:07:10-PST,786;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SCORE.STANFORD.EDU with TCP; Thu 11 Feb 88 16:06:22-PST Date: Thu 11 Feb 88 19:09:40-EST From: Ken Rossman Subject: Re: BBTRIM options To: VAF@SCORE.STANFORD.EDU, WANCHO@SIMTEL20.ARPA, TOPS-20@SCORE.STANFORD.EDU In-Reply-To: <12373954434.31.VAF@Score.Stanford.EDU> Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 Message-ID: <12373984992.148.SY.KEN@CU20B.COLUMBIA.EDU> There's certainly no point in our collecting up nice things for 20's here, since our machines are going out the door soon, but whoever might want to take over keeping archives of neat 20 things might want to coordinate collection from various sites. /Ken ------- 11-Feb-88 18:55:39-PST,475;000000000000 Mail-From: VAF created at 11-Feb-88 18:55:18 Date: Thu 11 Feb 88 18:55:18-PST From: Vince Fuller Subject: Re: BBTRIM options To: sy.Ken@cu20b.columbia.edu cc: WANCHO@SIMTEL20.ARPA, TOPS-20@Score.Stanford.EDU In-Reply-To: <12373984992.148.SY.KEN@CU20B.COLUMBIA.EDU> Office: Pine Hall 147 Phone: 415-725-1392 Message-ID: <12374015144.11.VAF@Score.Stanford.EDU> That's basically what I had in mind... Any volunteers? --Vince ------- 11-Feb-88 19:45:50-PST,1220;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SCORE.STANFORD.EDU with TCP; Thu 11 Feb 88 19:45:40-PST Date: Thu, 11 Feb 1988 20:26 MST Message-ID: From: "Frank J. Wancho" To: Ken Rossman Cc: TOPS-20@SCORE.STANFORD.EDU, VAF@SCORE.STANFORD.EDU, WANCHO@SIMTEL20.ARPA Subject: TOPS-20 Collection (The Seattle Project) In-reply-to: Msg of 11 Feb 1988 17:09-MST from Ken Rossman The unattributed extracts quoted in your message were from a message of mine. My offer to provide archive space still stands. However, I believe that, for historical reasons, SCORE has the right of first refusal. Also, last I heard, SCORE will not be going away any time soon (and neither will this host). One thing we lack here is a knowledgable volunteer with sufficient spare time to organize and maintain the collection. SCORE may be in a better position on that aspect. Did someone at Rutgers dump their structures to tape before they shut down their 20? I'd hate to see that material lost... I hope the title of this project is not too obscure... --Frank 11-Feb-88 22:11:12-PST,1685;000000000000 Return-Path: <@SUMEX-AIM.Stanford.EDU:MRC@PANDA.PANDA.COM> Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 11 Feb 88 22:10:40-PST Received: from PANDA.PANDA.COM by SUMEX-AIM.Stanford.EDU with Cafard; Thu, 11 Feb 88 22:13:48 PST Date: Thu, 11 Feb 88 21:39:28 PST From: Mark Crispin Subject: TOPS software repository To: TOPS-20@Score.Stanford.Edu Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12374045030.7.MRC@PANDA.PANDA.COM> Friends - The idea is excellent, and I volunteer to help as much as PANDA and I are able to. Unfortunately, I can't recommend PANDA as the primary repository because (1) PANDA uses RM03's, so even with a dedicated RM03 for the repository the limit would be only 30,000 pages, (2) I am going through a personal crisis (a messy divorce) which may end up with PANDA being off the air for some period of time. Score seems to be the Stanford DEC-20 that will stay around for a while, and since the TOPS-20 archive is already located there I hope we can prevail upon Score's management and systems programmer to agree to establish a repository there. You can help! Before the plug is pulled on your DEC-20, please write a tape with your site's goodies and send them to me: Mark Crispin c/o SUMEX Computer Project Medical School Office Building Room 249 Stanford, CA 94305-5477 [If you send the tape to my home I'll get a yellow slip and have to pick it up at the Post Awful...] I'll make sure the files end up at the right place, and will try to establish a library of the original tapes. ------- 12-Feb-88 07:08:54-PST,1921;000000000000 Return-Path: <@SUMEX-AIM.Stanford.EDU,@PANDA.PANDA.COM,@XERXES.STACKEN.KTH.SE:JMR%KICKI.STACKEN.KTH.SE@xerxes.stacken.kth.se> Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 12 Feb 88 07:08:25-PST Received: from PANDA.PANDA.COM by SUMEX-AIM.Stanford.EDU with Cafard; Fri, 12 Feb 88 07:09:27 PST Received: from XERXES.STACKEN.KTH.SE by PANDA.PANDA.COM with Cafard; Fri, 12 Feb 88 07:04:02 PST Received: from rtr08b.kth.se (not validated) by XERXES; Fri, 12 Feb 88 15:57:54 A Received: from KICKI.#DECnet by rtr08b.kth.se; Fri, 12 Feb 88 15:54 MET Date: 12 Feb 1988 (Friday) 1429-LOC From: JMR@kicki.stacken.kth.se Subject: PDP-6/10 software repository. To: VAF@score.stanford.edu, WANCHO@simtel20.arpa, sy.Ken@cu20b.columbia.edu, To: MRC@panda.panda.com, roll@xerxes.stacken.kth.se, jmr@nada.kth.se Cc: TOPS-20@SCORE.STANFORD.EDU We would love to volunteer as a PDP-6/10 software repository. I saw MRC was also willing to volunteer, and putting the (same) eggs into two baskets ... We (the Stacken Computer Club, the students' computer club at the Royal Institute of Technology in Stockholm, Sweden) are running a number of 10's and 20's as hobby computers, and we're collecting all sorts of useful hard- ware and software for the PDP-6/10 (TOPS-10/TOPS-20/TENEX/ITS). We're not on the ARPA Internet (yet, at least), so we would have to get the stuff on tape. Our address: Stacken Computer Club, c/o Department of Numerical Analysis and Computing Science, Royal Institute of Technology, S-100 44 Stockholm, Sweden. Yours, Jan Michael Rynning (software) Peter Lothberg (hardware) jmr@nada.kth.se roll@xerxes.stacken.kth.se +46-8-7906288 +46-8-699720 (roll@sestak.bitnet) P.S. Do you know anyone who has a PDP-6 to give away? We've got the rest of them (KA, KI, KL, and KS). We intend to run it if we get one. 16-Feb-88 10:54:03-PST,1902;000000000000 Return-Path: Received: from TOPS20.DEC.COM by SCORE.STANFORD.EDU with TCP; Tue 16 Feb 88 10:51:25-PST Date: 16 Feb 1988 1357-EST From: "Joe Dempster, DTN 336.2023, AT&T 609.273.2023" To: tops20@score.stanford.edu Subject: YIPYIP/2020 HW problems. Message-ID: <"MS11(6040)+GLXLIB6(0)" 12375238833.283.30.6223 at TOPS20.DEC.COM> YIPYIP (the DEC10 history project's 2020) is in bad shape. The system had a problem a few weeks ago which corrected itself after being powered down for the night. I should say the problem went solid last thursday, powering it down for the night probably corrected nothing. The problem: The system hangs with a the FAULT ligh on (as expected). On REBOOT the console attempts to load its BOOT routine. Nothing really happens, the only character that gets displayed on the console is a single solid block. Approximately 15 seconds later the FAULT light comes on and the system is hung. Trouble shooting to date: I have a complete set of spares (with the exception of a console board which I think is bad). I swapped all the KS modules, one at a time, and the same identical problem reappeared each time. I also swapped the 1st and last memory modules, but the problem didn't change. Conclusions: Since the system hangs before anything else can start (the light only comes on when it hangs, and never blinks) I conclude that the problem is probably with the console board. However, before I try to "fix" the console board (don't know how exactly that will happen) I thought I'd get a second opinion. There is a chance that the problem may be with the RH11's, but I haven't torn into that area yet (and hope I don't have to). I'd be appreciative of any tips or advice on working this outage. Anyone know of where a spare KS might be purchased? /joe -------- 16-Feb-88 13:19:25-PST,1499;000000000000 Return-Path: <@SUMEX-AIM.Stanford.EDU:MRC@PANDA.PANDA.COM> Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 16 Feb 88 13:17:20-PST Received: from PANDA.PANDA.COM by SUMEX-AIM.Stanford.EDU with Cafard; Tue, 16 Feb 88 13:20:15 PST Date: Tue, 16 Feb 88 12:32:04 PST From: Mark Crispin Subject: Re: YIPYIP/2020 HW problems. To: DEMPSTER@TOPS20.DEC.COM cc: TOPS-20@Score.Stanford.EDU In-Reply-To: <"MS11(6040)+GLXLIB6(0)" 12375238833.283.30.6223 at TOPS20.DEC.COM> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12375256098.7.MRC@PANDA.PANDA.COM> Joe - This may sound too obvious, but have you checked all the power supplies? The 15 second delay sounds suspiciously like a software timeout. First check the main KS10 power supply (the Mighty Mite with zillions of wires attached to it) and make sure the voltages all look reasonable. Next, check the BA11 power supply. DEC charges $800 to fix the Mighty Mite, but LH Research (the manufacturer) will charge only $400. I wouldn't advise trying to fix it yourself; it's quite hairy. You might also want to check your console terminal to make sure it's OK. I don't think it's the RH11's or the memory. You should be able to talk to the 8080 console program. It may be the console board, but that 15 second timeout suggests that it is happy and something else is sick. -- Mark -- ------- 18-Feb-88 15:38:15-PST,5351;000000000000 Return-Path: Received: from MCC.COM by SCORE.STANFORD.EDU with TCP; Thu 18 Feb 88 15:35:09-PST Date: Thu 18 Feb 88 17:25:49-CST From: Clive Dawson Subject: [Bill Barns : Re: ftp hang while trying to talk to cu20b.columbia.edu] To: tops-20@SCORE.STANFORD.EDU Message-ID: <12375812018.25.AI.CLIVE@MCC.COM> I'm forwarding this message for the benefit of those who don't see the TCP-IP traffic. It's unclear how much of this is relevant to the "current" TOPS-20 code, but at least it will become part of the TOPS-20 archives. --------------- Return-Path: Received: from SRI-NIC.ARPA by MCC.COM with TCP; Thu 18 Feb 88 17:20:12-CST Received: from OFFICE-1.ARPA by SRI-NIC.ARPA with TCP; Thu 18 Feb 88 10:57:50-PST Date: 18 Feb 88 13:50 EST From: Bill Barns Subject: Re: ftp hang while trying to talk to cu20b.columbia.edu To: Ken Rossman Cc: tcp-ip@SRI-NIC.ARPA Message-ID: In-reply-to: <12375523073.148.SY.KEN@CU20B.COLUMBIA.EDU> Readers not interested in the guts of TCP implementation might as well skip this message. I've had to muck about with Tenex TCP which is "related" to TOPS-20 TCP, and has much worse constraints with buffer space due to being part of a single section monitor. Some of what I've done to try to cope with free storage problems may be relevant to your monitor, but only you can tell for sure. I think there must be a jillion locally-hacked subflavors of this TCP code, and who knows how much resemblance remains between yours and mine. I can say that I do have a copy of "DEC's source" as of about 2.5 years ago and it seems to have the same problems which I'm about to describe, so maybe you have them too. Refer to the TCP packetizer near PKTZ10 (in source file TCPPZ or TCPTCP). The call on TCPIPK will nonskip-return if you are indeed out of space. Code in a literal tries to queue you to retry but as I understand the code, there's a problem. Your TCB is not queued anywhere at this instant, but TSFP or TSEP is very probably on (else why are you here?) So ENCPKT and/or DLAYPZ will effectively no-op and you're out of the packetizer without being queued anywhere. Any future Force or Encourage will meet the same fate because of those same bits. You're trapped in the Twilight Zone. Cure: SETZRO ,(TCB) as the first thing in the literal that calls ENCPKT after TCPIPK failure. If this scenario happened, it would be likely to yield the symptoms described by David Herron; but so might other things. I made several changes to TCPPRC routine, a little too long to list here. Basically they are: not to run a free-storage scavenge more than once a second, so as not to hog the CPU; and don't run TVTOPR on any pass that did a scavenge, in hopes of making fewer and bigger Telnet packets. It's better to avoid running out of space in the first place, even if that takes something drastic. With an 1822 interface it's absolutely crucial not to let the input interrupt level run out of buffers, so as to avoid RFNM-related deadlocks. Solution: Never give Internet the "last" input buffer. Put it back on the input buffer list after processing the 1822 leader. I suspect this isn't your problem though, since your addresses are class B/C, thus probably not 1822. It would help to have some idea of what most of your space is being used for when you run out. Absent specific data, I'd suspect huge retransmit queues caused by big windows and slow gateways between you and the FTPers. You can brute-force cope with this somewhat either by clamping received windows, or by finagling the packetizer to refuse to packetize for any connection that has more than n packets on the RX queue, or where the first packet on the RX queue has actually been retransmitted (a quick test for congestion). This will slow things down, but that's what you need to do when you're short of space. You can condition this code on INTFSP being less than some threshold and shove it into the PKTZ10 area too. If you have a lot of TVT (Telnet) tinygram traffic, you might want to add code in this same area to ask TCPIPK for only the size of buffer you need, rather than a max size buffer, when space is below the threshold. Also in the OPSCAN routine (TTTVDV or TTANDV source file?) around OPSCA1+10 or so, just after the JUMPE T3,OPSCA7 you might add JN TSEP,(TCB),OPSCA7 which will prevent this routine from undoing any delay previously imposed by some other routine. Further down in this same routine you should also have a change published by Westfield and Crispin about 2-3 years ago which includes a test on whether the RX queue is empty. This change is mainly performance-oriented but will save free storage too in some situations. These cover the highlights of things I've done that seem relevant. You can talk bits with me further if you're interested, of course. I wanted to post this much in case it stirs up any comments from TOPS-20 hackers out there. Maybe someone out there has already done these changes in a form that will slide directly into CU20B monitor. -b ------- 22-Feb-88 21:59:17-PST,886;000000000000 Return-Path: Received: from MATHOM.CISCO.COM by SCORE.STANFORD.EDU with TCP; Mon 22 Feb 88 21:58:12-PST Date: Mon 22 Feb 88 22:02:43-PST From: Len Bosack Subject: REL Block 1070 (Long Symbol Request) To: Tops20@SCORE.STANFORD.EDU Message-ID: <12376932846.7.BOSACK@MATHOM.CISCO.COM> Does anyone have an easy (well..) way to get MACRO/FAIL/MIDAS to generate block type 1070? What I have in mind is something like: .LSDEF VERYLONGSYMBOLNAME,expr-that-MACRO-can-collapse and .LSEXT symbol-to-be-defined,VERYLONGSYMBOLNAMESTILLNOLOWERCASE In the first case VERYLONGSYMBOLNAME would be defined by LINK, able to be referenced by the second case. .LSEXT would define a short symbol to be the value of the long symbol. These would make the job of porting C programs written for UN*X much, much easier. Len ------- 24-Feb-88 11:16:29-PST,660;000000000000 Return-Path: Received: from R20.UTEXAS.EDU by SCORE.STANFORD.EDU with TCP; Wed 24 Feb 88 11:14:10-PST Date: Wed 24 Feb 88 13:17:57-CST From: CC.KASSEBAUM@R20.UTEXAS.EDU Subject: Bug in IPHOST ethernet status To: tops-20@SCORE.STANFORD.EDU Message-ID: <12377339759.9.CC.KASSEBAUM@R20.UTEXAS.EDU> The ethernet status command of IPHOST has been working on out V5.4 monitor until I installed 6.1 AP16 version of TCP/IP. Now it behaves the same as ov v6.1 machine. You get three lines of channel info then ?JSYS error at user PC 6125. Does anybody have a patch for IPHOST ot tcp/ip to fix this. Dak ------- 29-Feb-88 16:50:47-PST,1015;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SCORE.STANFORD.EDU with TCP; Mon 29 Feb 88 16:47:00-PST Date: Mon 29 Feb 88 19:00:01-EST From: Ken Rossman Subject: IP bugs & fixes To: TOPS-20@SCORE.STANFORD.EDU Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 Message-ID: <12378701827.138.SY.KEN@CU20B.COLUMBIA.EDU> Many thanks to all who helped get me on the right track towards fixing up the CU20B monitor's IP code (in particular, thanks go to Clive Dawson and Frank Wancho). We're running the new patches now, and things "feel" a lot better so far, though I haven't done any sort of testing to see how much better things are now. If some of you who (semi-)regularly FTP things from CU20B could maybe drop me a note and let me know if things are going better with FTP connections, I'd really appreciate it. Particularly those of you who grab Kermit updates now and then. Thanks again, /Ken ------- 2-Mar-88 00:36:13-PST,903;000000000000 Return-Path: Received: from GSB-HOW.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 2 Mar 88 00:33:33-PST Date: Wed 2 Mar 88 00:38:08-PST From: Eric M. Berg Subject: Job Vacancy: System Programmer at Stanford GSB To: tops-20@Score.Stanford.EDU Phone-#s: 415/723-1576 (GSB-CF), 415/329-9940 (home) Message-ID: <12379058292.174.A.ERIC@GSB-HOW.Stanford.EDU> The Stanford Graduate School of Business is seeking a system programmer with experience in EITHER the VAX/VMS, OR the TOP-20, Unix, and TCP/IP computing environments. Full details are in the file PS:Job-Description-Sysprog.TXT which is available from host GSB-How.Stanford.EDU by Anonymous FTP. Specific questions may be directed to the undersigned. Eric M. Berg Stanford GSB Computer Facility A.ERIC@GSB-How.Stanford.EDU ------- 2-Mar-88 13:06:27-PST,2713;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SCORE.STANFORD.EDU with TCP; Wed 2 Mar 88 13:05:42-PST Date: Wed, 2 Mar 1988 14:10 MST Message-ID: From: "Frank J. Wancho" To: TOPS20@SCORE.STANFORD.EDU cc: WANCHO@SIMTEL20.ARPA Subject: More on TCP performance Around mid December, I started noticing TCBs in NOT.NOT states accumulating in the system, all indicating "partial pkt received" status, and all from incoming FTP connections. After some arbitrary time, the load shot up into the 40's and the system no longer responded and had to be rebooted. Because we have a high volume of FTP connections, this sequence repeated about every three days or so. I tracked down that it was NETSRV causing the load to increase. I recompiled NETSRV, commenting out the section which put the program in Queue 0. We no longer have problems with wild load factors. If enough of those NOT.NOTs accumulated, the system now gets a chance to eventually garbage collect and the NOT.NOTs vanish. That was OK for a while. But, I was receiving complaints from TAC users of long response times when the load was low (less than .5) and few, if any, users on the system. At those times, there were several of those NOT.NOTs hanging around, not yet enough for garbage collection to kick in. So, I trudged through the code and found the flag word which causes the garbage collection to occur: INTSVR. When I set it to -1, the NOT.NOTs vanished, and from personal observation through a TAC connection, the response time immediately improved every time this was done. So far, there have been no side effects noticed. In fact, until we had one of those rare clock error stops Monday evening, we had been up for 26 days straight! There are several open questions concerning these NOT.NOTs: 1. Is there a pattern? Well, yes, after a fashion - almost all of them are from Class B hosts connected through Fuzzball gateways, most of which are on NSFNET. This may be purely coincidental. Apparently the Fuzzballs are severely congested. 2. If the TCBs are already in a NOT.NOT state, why should it matter if there is a "partial packet received" and just flush it? 3. Why is it that even a small (~5) handful of these NOT.NOTs (as opposed to the same or higher number of active connections) seem to so severely impact network response time (20 to 40 second or more for a character echo)? I don't have the answers. Only a handful of hosts probably even see enough FTP connections to provoke this condition. If you have some thoughts or answers, I'd like to hear from you. --Frank 4-Mar-88 14:10:54-PST,2074;000000000000 Return-Path: Received: from SEED.AMS.COM by SCORE.STANFORD.EDU with TCP; Fri 4 Mar 88 14:09:04-PST Return-Path: <@KL.SRI.COM:info-vax-request@kl.sri.com> Received: from KL.SRI.COM by SEED.AMS.COM with TCP; Thu 3 Mar 88 04:40:11-EST Received: from ucbvax.Berkeley.EDU by KL.SRI.COM with TCP; Sat 27 Feb 88 05:11:16-PST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA20846; Sat, 27 Feb 88 04:59:03 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-vax@kl.sri.com (info-vax@kl.sri.com) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 Feb 88 00:49:12 GMT From: uplherc!sp7040!obie!wsccs!val@gr.utah.edu (Val Kartchner) Subject: VT Trek from DEC system 20 Message-Id: <184@wsccs.UUCP> Sender: info-vax-request@kl.sri.com To: info-vax@kl.sri.com ReSent-Date: Fri 4 Mar 88 17:14:17-EST ReSent-From: Betsy Ramsey ReSent-To: TOPS-20@SCORE.STANFORD.EDU ReSent-Message-ID: <12379731155.38.EWR@SEED.AMS.COM> I have seen a very good real time Star Trek games called VTTREK for DEC system 20's. The person who brought it here had the source, but no longer has it. It was written in FORTRAN and some DEC 20 assembly. I'd like to get the complete source to it, and/or any descendants from it. It shows the view from the bridge with a 3-D perspective control panel. I was very impressed. I'd also be interested in source for other Star Trek and other games, expecially real-time and multi-user games. We already have the Conquest (Star Trek like game), but if you have a more recent version, or a version written in C (or FORTRAN), I'd welcome it. Thanks in advance, -=:[ VAL ]:=- -- --- /\ ------------ Val Kartchner {UT@WSC} ---- #include ----- /\/\ . /\ | "Those who don't understand VMS are condemmed to reinvent / \/ \/\/ \ | Unix; those who understand VMS and Unix use VMS." ==/ U i n T e c h \====!ihnp4!utah-cs!utah-gr!uplherc!sp7040!obie!wsccs!val==== 6-Mar-88 11:35:02-PST,700;000000000000 Return-Path: Received: from MCC.COM by SCORE.STANFORD.EDU with TCP; Sun 6 Mar 88 11:31:58-PST Date: Sun 6 Mar 88 13:36:40-CST From: Clive Dawson Subject: AN20/ECU patch To: tops20@SCORE.STANFORD.EDU Message-ID: <12380226750.27.AI.CLIVE@MCC.COM> For several years we've been been running a small program at boot time which serves to establish proper handshaking between our AN20 and the ECU which connects us to the Internet PSN. Without it, the IMP READY signal never comes up because the ECU is waiting for HOST READY and vice versa. Does anybody have the equivalent functionality in the form of a monitor patch? Thanks, Clive ------- 10-Mar-88 17:39:38-PST,1081;000000000000 Return-Path: Received: from msr.epm.ornl.gov (ORNL-MSR.ARPA.#Internet) by SCORE.STANFORD.EDU with TCP; Thu 10 Mar 88 17:38:33-PST Received: by msr.epm.ornl.gov (5.51/4.9) id AA21627; Thu, 10 Mar 88 20:43:13 EST Date: Thu, 10 Mar 88 20:43:13 EST From: jzj@msr.EPM.ORNL.GOV (Jeff Jones) Message-Id: <8803110143.AA21627@msr.epm.ornl.gov> To: Tops-20@Score.Stanford.Edu Subject: WANTED - Callable fork code Folks, I am need of some FORTRAN callable assembly routines which work like the PCL commands: INVOKE, TYPEIN, CLEARTYPEOUT, KILLPROGRAM, and GETTYPEOUT. For people who don't know, these commands permit a PCL procedure to start a program in a lower fork and feed commands to it and retrieve output from it in a somewhat controlled fashion. I do have the PCL source for the 5.1 EXEC but I do not care to get into BLISS source unless I have to. If someone can point me toward some code, I would be most appreciative. Thanks in advance, Jeff Jones Martin Marietta Energy Systems, Inc. Oak Ridge, Tn (615)576-2335 11-Mar-88 13:34:55-PST,1041;000000000000 Return-Path: Received: from SCIENCE.UTAH.EDU by SCORE.STANFORD.EDU with TCP; Fri 11 Mar 88 13:34:04-PST Date: Fri 11 Mar 88 14:35:18-MST From: "Nelson H.F. Beebe" Subject: Re: WANTED - Callable fork code To: jzj@MSR.EPM.ORNL.GOV, Tops-20@SCORE.STANFORD.EDU cc: Beebe@SCIENCE.UTAH.EDU In-Reply-To: <8803110143.AA21627@msr.epm.ornl.gov> X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 Message-ID: <12381559066.21.BEEBE@SCIENCE.UTAH.EDU> Re: Fortran-callable fork package: Pick up DOC:FRKPAK.INFO from SCIENCE.UTAH.EDU via ANONYMOUS FTP and browse through it with Emacs INFO mode (do C-X I then G(dsk:frkpak)); if you like it, I'll make the sources available. You might want to look at DOC:FILEIO.INFO as well. I also have a complete JSYS interface with complete MONSYM symbols for Fortran programs, so you can conveniently do systems programming in Fortran if you need to. ------- 11-Mar-88 18:13:01-PST,1032;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SCORE.STANFORD.EDU with TCP; Fri 11 Mar 88 18:11:05-PST Date: Fri, 11 Mar 1988 19:14 MST Message-ID: From: "Frank J. Wancho" To: jzj@MSR.EPM.ORNL.GOV Cc: "Nelson H.F. Beebe" , Tops-20@SCORE.STANFORD.EDU, WANCHO@SIMTEL20.ARPA Subject: WANTED - Callable fork code In-reply-to: Msg of 11 Mar 1988 14:35-MST from Nelson H.F. Beebe Also available via ANONYMOUS FTP from SIMTEL20.ARPA in SRC:FORMAC.* are the sources and documentation for Sandia's FORTRAN/MACRO library, written by Norm Samuelson in the FORTRAN V7 days. Some routines may not apply or are no longer necessary, especially the extended addressing hack. Also, the interface to the EXEC is better done by modifying the EXEC so that it can read its command line args, a trivial, but useful feature to add if you have sources. --Frank 14-Mar-88 05:05:41-PST,2219;000000000000 Return-Path: Received: from DREA-XX.ARPA by SCORE.STANFORD.EDU with TCP; Mon 14 Mar 88 05:04:16-PST Date: Sat, 12 Mar 88 08:33:54 AST From: Peter J Gergely Subject: WANTED - Callable fork code To: jzj@msr.epm.ornl.gov cc: tops-20@score.stanford.edu Postal-address: 9 Grove St., P.O. Box 1012, Dartmouth, NS B2Y 3Z7, Canada Phone-Number: (902) 426-3100 x 215 [8:30am to 4:15pm Atlantic time] Message-ID: <12381722651.13.GERGELY@DREA-XX.ARPA> Also availble we have, the following files here at DREA-XX.ARPA. PS:DECLIB.HLP PS:DECLIB.REL PS:DECLIB.DOC The only request is that I have, is that mail be sent to GERGELY@DREA-XX.ARPA, with your name and mailing address (EMAIL and SNAIL) saying that you picked up the library. DECLIB.DOC is the formal documentation that may be requested in printed form, by sending the appropriate request to: CHIEF, Defence Research Establishment Atlantic P.O. Box 1012, Dartmouth, NS Canada B2Y 3Z7 Enclosed below is the .HLP available for DECLIB. The documentation was originally sent out to a few people on TOPS-20 many years ago. The HELP date should probably read 1985. Have fun. - Peter -- Peter J. Gergely (DREA, P.O. Box 1012, Dartmouth, NS B2Y 3Z7 Canada) ARPANET: gergely@DREA-XX.ARPA (preferred) or Peter@DREA-GRIFFIN.ARPA DIALNET: Peter@DIAL|DREA-Griffin CSNET: gergely%cs.dal.cdn@ubc.csnet UUCP: gergely@dalcs.UUCP ------------------------------------------------------------------------------- PROGRAM: DECLIB HELP DATE: July, 1982 AUTHOR/LOCAL CONTACT: Peter J. Gergely PURPOSE: Originally written by C. Mihoff to provide the capability of performing general magnetic tape operations from FORTRAN (the original DECLIB). The library was extensively modified to include many more powerful FORTRAN-callable MACRO routines such as general information functions, subprograms manipulation, binary typeout, and many others. ADDITONAL REQUIREMENTS: FURTHER DOCUMENTATION MAY BE FOUND AT: DOC:DECLIB.DOC ------- 14-Mar-88 10:12:18-PST,1077;000000000000 Return-Path: Received: from lindy.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 14 Mar 88 10:11:38-PST Received: by lindy.stanford.edu; Mon, 14 Mar 88 06:35:33 PST Received: by Forsythe.Stanford.EDU; Mon, 14 Mar 88 10:15:42 PST Received: from bmc1.uu.se by max.uu.se; Mon, 14 Mar 88 19:13 MET Received: from TCP-DAEMON by bmc1.UU.SE; Mon, 14 Mar 88 19:13 MET Date: Mon 14 Mar 88 19:11:57 From: Bj|rn Victor Subject: Messy ARP table To: TOPS-20@score.stanford.edu Cc: Victor@aida.uu.se Message-Id: <880314191157.14.VICTOR@AIDA> Could somebody out there help me and find the patch for messy ARP tables (duplicates all over, table overflows)? I know I've seen it passing by during the last year or three, but now I seem to have lost it. (A DDT patch would be best, but a source patch will certainly do...) Yours, --Bjorn Victor victor@AIDA.UU.SE Dept. of Computer Systems or Uppsala University, SWEDEN victor%AIDA.UU.SE@uunet.UU.NET ------- 30-Mar-88 09:00:40-PST,1041;000000000000 Return-Path: <@SUMEX-AIM.Stanford.EDU:MRC@PANDA.PANDA.COM> Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 30 Mar 88 08:58:44-PST Received: from PANDA.PANDA.COM by SUMEX-AIM.Stanford.EDU with Cafard; Wed, 30 Mar 88 09:03:04 PST Date: Wed, 30 Mar 88 07:51:40 PST From: Mark Crispin Subject: PANDA record uptime To: KS-owners@PANDA.PANDA.COM, TOPS-20@Score.Stanford.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12386477245.7.MRC@PANDA.PANDA.COM> PANDA died after a 2045 hour run due to a software bug. I was hacking; specifically, I had called ULKINI (unlocking EDDT from physical memory) from MDDT to see how many memory pages I'd get back. I saw no indication from INFO MON or SYSDPY that it made any difference, so I went back to MDDT and was rewarded with a SKDPF1 bughlt. Since EDDT wasn't in memory, there was no hope of reviving the system. I wonder what the current TOPS-20 record uptime is? ------- 4-Apr-88 17:46:10-PDT,1516;000000000000 Return-Path: <@SUMEX-AIM.Stanford.EDU:MRC@PANDA.PANDA.COM> Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 4 Apr 88 17:43:28-PDT Received: from PANDA.PANDA.COM by SUMEX-AIM.Stanford.EDU with Cafard; Mon, 4 Apr 88 17:48:37 PDT Date: Mon, 4 Apr 88 17:14:46 PDT From: Mark Crispin Subject: value of a DEC-20? To: TOPS-20@Score.Stanford.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12387879552.7.MRC@PANDA.PANDA.COM> Is there any place or organization that puts values on antique computers? I am in the midst of an extremely nasty divorce. Part of this consists of my estranged wife claiming that my 2020 system is worth "between $10K-$20K". This is patently bullshit (I think a more realistic value is $2K) but just try to convince the courts of that. They just see a lot of iron and think it must be worth a lot of money. So, I need to get some sort of valuation placed on it from an authority the courts will accept. With the used market as volatile as it is (I've seen $295 to $995 for RM03's), a turkey can really screw things up but good. I don't think *any* dealer would buy a 2020 at any price, but $500 seems to be what people have been paying for them these days. The thing that hurts the most is that the system isn't really legally mine; title was never transferred to me. I won't even talk about the alimony. -- Mark -- ------- 4-Apr-88 17:57:03-PDT,979;000000000000 Return-Path: Received: from buita.BU.EDU by SCORE.STANFORD.EDU with TCP; Mon 4 Apr 88 17:56:49-PDT Received: from bu-it.bu.edu by buita.BU.EDU (4.0/4.7) id AA08450; Sat, 5 Mar 88 19:56:55 EST Received: from bu-cs.bu.edu by bu-it.bu.edu (3.2/4.7) id AA01555; Mon, 4 Apr 88 21:00:16 EDT Return-Path: Received: by bu-cs.bu.edu (5.31/4.7) id AA19719; Mon, 4 Apr 88 19:58:18 EST Date: Mon, 4 Apr 88 19:58:18 EST From: bzs%bu-cs.bu.edu@buita.BU.EDU (Barry Shein) Message-Id: <8804050058.AA19719@bu-cs.bu.edu> To: MRC@PANDA.PANDA.COM Cc: TOPS-20@Score.Stanford.EDU In-Reply-To: Mark Crispin's message of Mon, 4 Apr 88 17:14:46 PDT <12387879552.7.MRC@PANDA.PANDA.COM> Subject: value of a DEC-20? Why don't you just ask DEC's Traditional Products Group (TPL) what they would give you or valuate it at if they were interested. Seems like that would be authoritative enough. -Barry Shein, Boston University 4-Apr-88 19:01:00-PDT,1041;000000000000 Mail-From: GROSSMAN created at 4-Apr-88 19:00:17 Date: Mon 4 Apr 88 19:00:16-PDT From: Stu Grossman Subject: Re: value of a DEC-20? To: bzs%bu-cs.bu.edu@BUITA.BU.EDU cc: TOPS-20@Score.Stanford.EDU In-Reply-To: <8804050058.AA19719@bu-cs.bu.edu> Message-ID: <12387898758.10.GROSSMAN@Score.Stanford.EDU> I think that since Mark takes such good care of his 2020, that the total system must be worth in the neighborhood of 250,000 -> 300,000 dollars. Actually, the system is really worth what you can earn with it. If it is no longer available, then it's value would be equal to the value of whatever could equivalently replace it. I would think that a Sun 3/280 Server with a couple of Fuji Eagles and a tape drive might be a rough equivalent. That's worth about $90,000. Of course, you have some printers and modems on the system, so that would push the price up to somewhere in the neighborhood of $100,000. See, you really have a pretty decent system after all!!! Stu ------- 4-Apr-88 20:27:14-PDT,742;000000000000 Return-Path: Received: from ardvax.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 4 Apr 88 20:26:34-PDT Received: by ardvax.stanford.edu; Mon, 4 Apr 88 19:34:10 PST Date: Mon, 4 Apr 1988 20:34:01 PDT From: Bill Yeager To: grossman@score.stanford.edu Cc: tops-20@score.stanford.edu Subject: dec2020 Stu, pure nonsense! Mark's system is worth exactly what he can sell it for on the open market. Just like my 68VW squareback. I could replace it with an 88 GTI 16V that is worth about $16,500 bucks, but certainly cannot sell if for more than $1K. 2020's are neat to have around just like my ol' reliable VW. But, gee, have you driven one of those GTI's? Bill 4-Apr-88 21:33:55-PDT,1019;000000000000 Return-Path: Received: from buita.BU.EDU by SCORE.STANFORD.EDU with TCP; Mon 4 Apr 88 21:33:20-PDT Received: from bu-it.bu.edu by buita.BU.EDU (4.0/4.7) id AA20082; Tue, 5 Apr 88 00:37:12 EDT Received: from bu-cs.bu.edu by bu-it.bu.edu (3.2/4.7) id AA11088; Tue, 5 Apr 88 00:37:09 EDT Return-Path: Received: by bu-cs.bu.edu (5.31/4.7) id AA01497; Mon, 4 Apr 88 23:35:20 EST Date: Mon, 4 Apr 88 23:35:20 EST From: bzs%bu-cs.bu.edu@buita.BU.EDU (Barry Shein) Message-Id: <8804050435.AA01497@bu-cs.bu.edu> To: yeager@ardvax.stanford.edu Cc: grossman@score.stanford.edu, tops-20@score.stanford.edu In-Reply-To: Bill Yeager's message of Mon, 4 Apr 1988 20:34:01 PDT <8804050331.AA27105@bu-cs.bu.edu> Subject: dec2020 Actually, I'll relate a comment from an unnamed observer here, not my particular opinion: "get the quote from the lawyer then deliver the 2020 and strike half the claimed value off the rest of the settlement, then buy another" 4-Apr-88 23:28:34-PDT,645;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SCORE.STANFORD.EDU with TCP; Mon 4 Apr 88 23:28:15-PDT Date: Tue 5 Apr 88 02:33:05-EST From: Ken Rossman Subject: Re: dec2020 To: yeager@ARDVAX.STANFORD.EDU, grossman@SCORE.STANFORD.EDU cc: tops-20@SCORE.STANFORD.EDU Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 Message-ID: <12387959345.148.SY.KEN@CU20B.COLUMBIA.EDU> 2020's are neat to have around just like my ol' reliable VW. But, gee, have you driven one of those GTI's? And remember: "It's not a *computer*, it's a *DEC*" ------- 5-Apr-88 06:37:08-PDT,2086;000000000000 Return-Path: Received: from lindy.stanford.edu by SCORE.STANFORD.EDU with TCP; Tue 5 Apr 88 06:36:36-PDT Received: by lindy.stanford.edu; Tue, 5 Apr 88 06:41:37 PDT Received: by Forsythe.Stanford.EDU; Tue, 5 Apr 88 06:39:52 PDT Received: by INDYCMS (Mailer X1.23b) id 6906; Tue, 05 Apr 88 08:28:40 EST Date: Tue, 5 Apr 1988 08:10 EST From: Mark H. Wood Subject: Re: value of a DEC-20? To: I would say that a good model for the situation described might be the one followed when valuing wrecked automobiles for the purpose of recovering one's loss in a multi-car accident. (It doesn't sound right yet, but read on.) Get several estimates from used-computer dealers that you trust, asking for the price THEY would get for SELLING a comparable system. Establish a range of reasonable values and throw out the turkeys. (Your lawyer can tell you how to weight your range for the best combination of fairness and tactical advantage....) Another place to try might be the Computer Museum in Boston. A third source of valuation, though it will probably carry less weight, could be people you know who purchase computers for their businesses' use. What would several of your business acquaintances pay for your system, if they needed it, and would they be willing to offer an expert opinion? But one should not have to go through all this. Is there any way you can *prove* that the 2020 is owned by someone else? Your posession of the machine should NOT be significant if someone else can prove ownership. (I am rather ignorant here: do minicomputers have certificates of title, like automobiles? If not, you may have to bring in a representative of the owner as witness to your non-ownership, or at least present an affidavit executed by the owner. Just for luck, also be prepared to explain your posession of somebody else's computer.) Please check with your lawyer before pursuing any of these avenues. 5-Apr-88 08:42:31-PDT,1454;000000000000 Return-Path: Received: from sally.utexas.edu by SCORE.STANFORD.EDU with TCP; Tue 5 Apr 88 08:42:03-PDT Posted-Date: Tue, 5 Apr 88 10:34:31 cdt Received: by sally.utexas.edu (5.54/5.51) id AA18373; Tue, 5 Apr 88 10:47:12 CDT Date: Tue, 5 Apr 88 10:34:31 cdt From: ctp@red.cs.utexas.edu (Clyde T. Poole) Message-Id: <8804051534.AA08028@red> Received: by red (13.1/4.22) id AA08028; Tue, 5 Apr 88 10:34:31 cdt To: tops-20@score.stanford.edu Subject: Death of another DECSYSTEM-20 I just posted the following notice here at the University of Texas at Austin. The actual disposition of the hardware is still unknown. ----- At a meeting of the Steering Committee for the Research DECSYSTEM-20 on Thursday, March 31, 1988, it was decided to shut down the R20 permanently as of August 31, 1988. All users of the R20 should begin to make alternate arrangements for file storage and electronic mail as soon as possible. Faculty, staff and students of the Department of Computer Sciences can contact Karen Schaffer (karen@ratliff.cs.utexas.edu) about alternate arrangements. ----- Clyde T. Poole -- Technical Coordinator, Facilities and Equipment Univ. of Texas at Austin ARPA/CSnet: ctp@cs.utexas.edu Dept. of Computer Sciences UUCP: {uunet,harvard,ihnp4}!ut-sally!ctp Taylor Hall 2.124 BITNET: ctp@UTADNX SPAN: UTADNX::CTP Austin, TX 78712-1188 VOICE: (512) 471-9551 7-Apr-88 06:51:52-PDT,1847;000000000000 Return-Path: <@MITVMA.MIT.EDU,@WESLEYAN.BITNET:DBIGELOW@EAGLE.WESLEYAN.EDU> Received: from MITVMA.MIT.EDU by SCORE.STANFORD.EDU with TCP; Thu 7 Apr 88 06:47:34-PDT Received: from WESLEYAN.BITNET by MITVMA.MIT.EDU ; Thu, 07 Apr 88 09:50:12 EDT Date: 7-APR-1988 09:11:44.28 From: Douglas Bigelow Subject: KNISCE bugchecks with cisco AGS gateway To: Tops-20@Score.Stanford.Edu Got an interesting problem here... Wesleyan has just joined NSFnet via the new JVNCnet New England loop, which is a ring of universities joined by cisco AGS routers and 56KB lines. Our AGS has an Ethernet interface for our local network, a 56KB serial link to Yale, and another 56KB link to Brown. The gateways are still having the routing configurations tuned, but they'll be in full operation within a week. Now, starting two days ago, both of our 2060s started issuing KNISCE bugchecks about once a minute. They were roughly synchronized on both systems. We tried halting and reloading the NIs, disconnecting the tranceivers, etc. Finally, we started unplugging other network hosts that we were suspicious of. Lo and behold, it turns out that the 20s quiet right down when the cisco AGS is disconnected, and start re-issuing KNISCEs when it's reconnected. We're running version 150 of the NI microcode (from KNILDR), and haven't changed any software or hardware on our 20s in two years. The cisco box had been on our network for a week before any problem started occurring. It seems to have popped up about the time that the AGS was switched from RIP routing to IGRP, but that may be pure coincidence. Anyone have any ideas? Need any more information? Any ideas welcome. Please reply directly to me so I can see the responses most quickly. Thanks -- Doug 7-Apr-88 08:58:40-PDT,1307;000000000000 Return-Path: Received: from lindy.stanford.edu by SCORE.STANFORD.EDU with TCP; Thu 7 Apr 88 08:57:39-PDT Received: by lindy.stanford.edu; Thu, 7 Apr 88 09:02:30 PDT Received: by Forsythe.Stanford.EDU; Thu, 7 Apr 88 09:01:14 PDT X-Delivery-Notice: SMTP MAIL FROM does not correspond to sender. Received: from locke.hs.washington.edu (SYSTEM@UWALOCKE) by UWAVM.ACS.WASHINGTON.EDU (Mailer X1.25) with BSMTP id 0378; Thu, 07 Apr 88 09:01:11 PDT Date: Thu, 7 Apr 88 09:01 PDT From: BRUCE EDWARDS Subject: 2020 console line speed change To: tops-20@score.stanford.edu X-Vms-To: IN%"tops-20@Score.Stanford.EDU" I have a trivial question for those in the know. Does anyone know what the switch settings are to change the speed to 1200 baud for both the CTY and the KLINIK line on the KS10 console board (M8616). We have finally hooked up a 1200 baud DECWRITER and would like to take advantage of it. Thanks in advance. Bruce Edwards John Locke Computer Center University of Washington SB-50 Seattle, WA 98195 Bitnet - BRUCE@UWALOCKE Internet - BRUCE@LOCKE.HS.WASHINGTON.EDU (not sure how well this addr will work( 7-Apr-88 10:14:45-PDT,1092;000000000000 Return-Path: Received: from lindy.stanford.edu by SCORE.STANFORD.EDU with TCP; Thu 7 Apr 88 10:13:54-PDT Received: by lindy.stanford.edu; Thu, 7 Apr 88 10:18:40 PDT Received: by Forsythe.Stanford.EDU; Thu, 7 Apr 88 10:15:30 PDT Date: Thu, 7 Apr 88 10:11 PDT From: (BRUCE EDWARDS) Subject: 2020 console Line speed change To: Tops-20@score.stanford.edu X-Original-To: edu%"Tops-20@Score.Stanford.edu", BRUCE I have a trivial question for those in the know. Does anyone know what the switch settings are to change the speed to 1200 baud for both the CTY and the KLINIK line on the KS10 console board (M8616). We have finally hooked up a 1200 baud DECWRITER and would like to take advantage of it. Thanks in advance. Bruce Edwards John Locke Computer Center University of Washington SB-50 Seattle, WA 98195 Bitnet - BRUCE@UWALOCKE Internet - BRUCE@LOCKE.HS.WASHINGTON.EDU (not sure how well this addr will work) 7-Apr-88 14:26:47-PDT,3582;000000000000 Return-Path: Received: from decwrl.dec.com by SCORE.STANFORD.EDU with TCP; Thu 7 Apr 88 14:25:21-PDT Received: by decwrl.dec.com (5.54.4/4.7.34) id AA10889; Thu, 7 Apr 88 14:30:30 PDT Date: Thu, 7 Apr 88 14:30:30 PDT Message-Id: <8804072130.AA10889@decwrl.dec.com> From: ridder%warlok.DEC@decwrl.dec.com To: KS-Owners@panda.pands.com, TOPS-20@score.stanford.edu, BRUCE%UWALOCKE.BITNET@forsythe.stanford.edu Subject: Re: 2020 console Line speed change ======== Date: 7 Apr 1988 1529-MDT From: Hans To: "(BRUCE EDWARDS) 7-Apr-88 1011 PDT" <"BRUCE%UWALOCKE.BITNET@forsythe.stanford.edu"@DECWRL> cc: "TOPS-20@Score.Stanford.EDU"@DECWRL, "KS-Owners@Panda.Pands.COM"@DECWRL Subject: Re: 2020 console Line speed change Message-ID: <"MS11(6040)+GLXLIB6(0)" 12388635963.74.143.120097 at WARLOK> References: Message from "(BRUCE EDWARDS) 7-Apr-88 1011 PDT" <"BRUCE%UWALOCKE.BITNET@forsythe.stanford.edu"@DECWRL> of 7-Apr-88 1332-MDT 2020 console boards come in two types, rev D and rev E, and they look totally different from each other. These days you will find mostly rev E boards, but occasionally you'll find an old one. The rev E board has a switch pack at the top and bottom edge of the board (holding it like it would be in the backplane.) The rev D board has the two switch packs right next to each other in the center of the board. Console terminal (REV E) ! E10 ! E173 ! ! 3 ! 4 ! 5 ! 6 ! 2 ! 3 ! 110 ! Off ! Off ! Off ! Off ! Off ! Off ! 150 ! On ! Off ! Off ! Off ! Off ! On ! 300 ! Off ! On ! Off ! Off ! Off ! On ! 600 ! Off ! Off ! Off ! On ! Off ! On ! 1200 ! Off ! Off ! On ! Off ! Off ! On ! 1800 ! On ! Off ! On ! Off ! Off ! On ! 2400 ! On ! On ! Off ! Off ! Off ! On ! 4800 ! Off ! On ! On ! Off ! Off ! On ! 9600 ! On ! On ! On ! Off ! Off ! On ! KLINIK terminal (REV E) ! E10 ! E173 ! ! 1 ! 2 ! 7 ! 8 ! 4 ! 7 ! 110 ! Off ! Off ! Off ! Off ! Off ! Off ! 150 ! On ! Off ! Off ! Off ! Off ! On ! 300 ! Off ! On ! Off ! Off ! Off ! On ! 600 ! Off ! Off ! Off ! On ! Off ! On ! 1200 ! Off ! Off ! On ! Off ! Off ! On ! 1800 ! On ! Off ! On ! Off ! Off ! On ! 2400 ! On ! On ! Off ! Off ! Off ! On ! 4800 ! Off ! On ! On ! Off ! Off ! On ! 9600 ! On ! On ! On ! Off ! Off ! On ! Console terminal (REV D) ! E508 ! ! 1 ! 2 ! 3 ! 4 ! 5 ! 6 ! 110 ! Off ! Off ! Off ! Off ! Off ! Off ! 300 ! Off ! Off ! On ! Off ! On ! Off ! 600 ! On ! Off ! Off ! Off ! On ! Off ! 1200 ! Off ! On ! Off ! Off ! On ! Off ! 1800 ! Off ! On ! Off ! On ! On ! Off ! 2400 ! Off ! Off ! On ! On ! On ! Off ! 4800 ! Off ! On ! On ! Off ! On ! Off ! 9600 ! Off ! On ! On ! On ! On ! Off ! KLINIK terminal (REV D) ! E509 ! ! 1 ! 2 ! 3 ! 4 ! 5 ! 6 ! 110 ! Off ! Off ! Off ! Off ! Off ! Off ! 300 ! Off ! Off ! On ! Off ! On ! Off ! 600 ! On ! Off ! Off ! Off ! On ! Off ! 1200 ! Off ! On ! Off ! Off ! On ! Off ! 1800 ! Off ! On ! Off ! On ! On ! Off ! 2400 ! Off ! Off ! On ! On ! On ! Off ! 4800 ! Off ! On ! On ! Off ! On ! Off ! 9600 ! Off ! On ! On ! On ! On ! Off ! -------- 7-Apr-88 17:13:43-PDT,741;000000000000 Return-Path: Received: from MCC.COM by SCORE.STANFORD.EDU with TCP; Thu 7 Apr 88 17:13:25-PDT Date: Thu 7 Apr 88 19:18:17-CDT From: Clive Dawson Subject: Re: KNISCE bugchecks with cisco AGS gateway To: DBIGELOW%EAGLE.WESLEYAN.EDU%WESLEYAN.BITNET@MITVMA.MIT.EDU cc: tops20@SCORE.STANFORD.EDU In-Reply-To: Message from "Douglas Bigelow " of Thu 7 Apr 88 09:11:44-CDT Message-ID: <12388666623.31.AI.CLIVE@MCC.COM> Did you say you are running NI Microcode version 150?! We've been running version 171 for about a year now. I would certainly suggest updating KNILDR as the first step toward solving this problem. Clive ------- 28-Apr-88 11:10:04-PDT,2747;000000000000 Return-Path: <114RONAN%SPOOL.LIVERPOOL-POLY.AC.UK@forsythe.stanford.edu> Received: from lindy.stanford.edu by SCORE.STANFORD.EDU with TCP; Thu 28 Apr 88 11:05:37-PDT Received: by lindy.stanford.edu; Thu, 28 Apr 88 10:17:56 PDT Received: by Forsythe.Stanford.EDU; Thu, 28 Apr 88 10:15:10 PDT Received: from RL.IB by UKACRL.BITNET (Mailer X1.25) with BSMTP id 5716; Thu, 28 Apr 88 18:01:08 BST Via: UK.AC.RL.EARN; Thu, 28 Apr 88 18:01:07 BST Received: from RL.IB by UK.AC.RL.IB (Mailer X1.25) with BSMTP id 5714; Thu, 28 Apr 88 18:01:07 BS Via: UK.AC.LIVPOL.SPOOL; 28 APR 88 18:01:04 BST Date: 28-APR-1988 17:58:38 From: 114RONAN%SPOOL.LIVERPOOL-POLY.AC.UK@forsythe.stanford.edu To: TOPS-20@score.stanford.edu Subject: DUMPER archival nasty - have YOU been bitten? Here's a problem that MAY be affecting you, but you haven't noticed. Doing archiving with DUMPER 6(532) under TOPS-20 6.1(7030), we find that sometimes files appear to have been archived, but in fact have NOT been. I.e. when we come to retrieve the files from the archive tape they are supposedly saved on, they're not there. At least one other site in the U.K. has reported and SPR'd this problem. The scenario I have seen myself is as follows:- doing the first archival run onto a 1600 bpi tape in a TU77 drive. The tape had been used before, so we answer no to "Is this a new tape?". DUMPER then searches the tape for the end of the last saveset, and proceeds to "save" the files that are marked for archiving. The tape moves as you would expect, and DUMPER lists the files as it "saves" them, but when you rewind the tape and print a listing of it, you find that no files have actually been saved, and EOT is still where it was when you started. In this particular example, the only saveset on the tape when we started was continued from a previous archival tape, and the only file in the saveset was also continued from the previous tape. This may or may not be relevant, but I tried several times to archive files to this particular tape, and had no luck. I eventually used SAVE rather than ARCHIVE to save one file after the first (only) saveset, and subsequent archives seemed to work OK, (except that the saveset names were not "ARCHIVE blah blah" as you would expect, but blank). I don't know if this is the only time when this happens, but we are now VERY wary of doing any archivals until we get a solution to this problem... It might prove an interesting, (or terrifying), exercise to check your archived files and see if they appear on the archive tapes they're supposed to :-( Ronan Flood, (114RONAN@SPOOL.LIVPOL.AC.UK) Liverpool Polytechnic Computer Services. 28-Apr-88 22:20:13-PDT,783;000000000000 Return-Path: Received: from lindy.stanford.edu by SCORE.STANFORD.EDU with TCP; Thu 28 Apr 88 22:15:06-PDT Received: by lindy.stanford.edu; Thu, 28 Apr 88 22:20:53 PDT Received: by Forsythe.Stanford.EDU; Thu, 28 Apr 88 22:18:14 PDT Received: by INDYCMS (Mailer X1.23b) id 3501; Thu, 28 Apr 88 17:01:56 EST Date: Thu, 28 Apr 1988 17:00 EST From: Mark H. Wood Subject: Re: DUMPER archival nasty - have YOU been bitten? To: Since the tape moves "normally", I suspect a positioning problem. Did you space the tape past the LEOT and look for the saveset? The archival logic may be mispositioning after searching for LEOT. Good luck! 2-May-88 22:54:47-PDT,916;000000000000 Return-Path: Received: from GSB-HOW.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 2 May 88 22:54:46-PDT Date: Mon 2 May 88 22:59:20-PDT From: Eric M. Berg Subject: Master TTYINI file now lives on Score To: su-tops-20@Score.Stanford.EDU, nethax@Jessica.Stanford.EDU Phone-#s: 415/723-1576 (GSB-CF), 415/329-9940 (home) Message-ID: <12395282310.162.A.ERIC@GSB-HOW.Stanford.EDU> With the demise of the Sierra DECsystem-20, the master copy of the file TTYINI.NET-BASE now lives in the FINGER: directory on Score. (This is the file which is used to general terminal type and location information for TOPS-20 and Unix hosts on campus.) I expect that Stu Grossman will make some announcement regarding access to the FINGER: directory on Score for people who need to update the file but do not currently have access. Stay tuned... ------- 5-May-88 17:59:01-PDT,837;000000000000 Return-Path: Received: from GSB-HOW.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 5 May 88 17:55:58-PDT Date: Thu 5 May 88 18:00:24-PDT From: Eric M. Berg Subject: LCG Clearance Sale To: tops-20@Score.Stanford.EDU Phone-#s: 415/723-1576 (GSB-CF), 415/329-9940 (home) Message-ID: <12396014324.169.A.ERIC@GSB-HOW.Stanford.EDU> DEC just sent around a letter announcing an "LCG Inventory Reduction Offer" (can you say "going out of business sale"?), with sale prices on MG memory, MCA-25 cache/pager upgrades, CI-20 and NIA-20 port adapters, and even whole KL-10 systems. If you're interested, call LCG Marketing at 617/467-4291 or 467-5404. (Presumably there are two phone lines to handle the tremendous amount of business they expect to do. :-} ) ------- 9-May-88 19:10:40-PDT,2376;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SCORE.STANFORD.EDU with TCP; Mon 9 May 88 19:06:59-PDT Date: Mon, 9 May 1988 19:35 MDT Message-ID: From: "Frank J. Wancho" To: TOPS-20@SCORE.STANFORD.EDU cc: WANCHO@SIMTEL20.ARPA Subject: Verify any drives lately? One of our secondary drives, PD1:, developed a hard error Saturday and the drive was reformatted and verified by the CE. Then I CREATEd and VERIFY'd the drive with CHECKD, but not without a couple of time-consuming problems. The CHECKD used came with 6.1 and is 6.1(88). The first problem we had last November when I did the same thing with CHECKD on our RP06 boot drive, which caused much wasted time bringing up the new drives under 6.1. We found that with 6.1 and the 442 microcode which comes with version 15.50 of RSX20F, we could no longer ENABLE WRITE-VERIFICATION FILE without causing the system to continuously reboot due to an ILUUO. The workaround is to have the DEC CE reformat and verify, and not ENABLE WRITE... with CHECKD. We rediscovered that problem this weekend. This problem did not occur with 5.4 and RSX20F version 15.15... We also discovered that CHECKD will fail at 1,,READ2+5 with a JSYS error: illegal operation with DSKOP. After the third time we tried this, we accidentally discovered the workaround was to repeatedly CONTINUE CHECKD until it considered the error as a hard error and finished. (This was near the end of the disk.) It was also rather peculiar that all the errors it found were all preceded by a series of JSYS error: messages eventually followed by a message from CHECKD that the soft error was corrected by the ECC mechanism, but considered bad (because I had ENABLEd SOFT-ERROR-MARKING). Finally, when CHECKD fails, it leaves the structure in limbo - you can't DISMOUNT it with either EXEC or OPR commands. It turned out to require a combination of SET.. UNAVAILABLE/AVAILABLE OPR commands. (The exact sequence that finally worked can be made available if anyone is interested - I need to check the console log.) Now, the question for today: has anyone experienced the same or similar problems and has the fix(es) been published. If it is known to be fixed in AP#17, I'd like to know so I can go unpack it. --Frank 16-May-88 01:47:33-PDT,2055;000000000000 Return-Path: Received: from GSB-HOW.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 16 May 88 01:47:32-PDT Date: Mon 16 May 88 01:46:17-PDT From: Jim Lewinson Subject: LPTSPL Crashes on CANCEL; Excessive CPU consumption To: SU-Tops-20@Score.Stanford.EDU Message-ID: <12398720576.140.A.JIML@GSB-HOW.Stanford.EDU> Problem #1: The TCP version of LPTSPL crashes when a job in progress is canceled. Diagnosis: It turns out that the Galaxy IPCF Interupt code makes an assuption about the format of the Stack Frame when it mucks with it in order to make the currently executing routine return right away. As a result, it returns to a random memory location. Solution: Add a location, TCPCNT, that NETSOU can use to store the bytes remaining to be sent, and make the code at NETSOU use that space, instead of allocating a word from the stack and screwing up GLXLIB's Interrupt routines. The corrected code is on [GSB-HOW] SP:<6.1.GALAXY.STANFORD>LPTSPL, and will propagate to LOTS as soon as I find the sources there again. Problem #2: There is code in LPTSPL which starts up a subfork and tries to READ characters from the JFN that LPTSPL is sending on. I think this is intended to handle printers that send ^Q's back which are getting past the Ethertip and were piling up in the tip and trashing the connection. However, this code doesn't seem to work. The BIN% works when executed in the parent fork, but it simply returns without an error code in the subfork. Needless to say, it loops back right away to read another "character", and so consumes large amounts of CPU time. "Solution" When it actually manages to read a "character", I made it go to sleep for a few seconds. It still consumes a little CPU time, but it is bearable. Does anyone understand what is going on here? I get impression that the child isn't allowed to touch a TCP: JFN opened by a parent, but I can't even figure out what the error is. Jim ------- 16-May-88 12:10:10-PDT,1471;000000000000 Return-Path: Received: from MCC.COM by SCORE.STANFORD.EDU with TCP; Mon 16 May 88 12:01:30-PDT Date: Mon 16 May 88 13:56:56-CDT From: Clive Dawson Subject: SMTP connections refused To: tops20@score.stanford.edu Message-ID: <12398831740.32.AI.CLIVE@MCC.COM> Several months ago there was some discussion about hung SMTP connections which prevented new SMTP connections from getting established. Bill Westfield published a patch to TCPTCP and IPIPIP which addressed this problem, but our 20 is still experiencing it even though we have this patch installed. I modified SMTJFN to print a message on the CTY every time it fails to open a listening SMTP connection. These failures happen much more often than I realized -- about once every 10 minutes on the average. The problem is that most remote mailers which get a connection refused will not try again for many minutes, even though an immediate retry would almost always succeed. This results in a delay of up to 30 minutes for a small but significant number of messages which would normally be delivered in seconds. The CTY messages also show that the error being returned from the OPENF is "Retransmission timeout". I don't understand what this means in the context of a listening connection. I'm going to start digging into this further, but thought I'd find out if anybody else has found a way to deal with this. Thanks, Clive ------- 18-May-88 15:43:12-PDT,2635;000000000000 Return-Path: Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 18 May 88 14:22:38-PDT Date: Wed, 18 May 88 14:06:45 PDT From: Mark Crispin Subject: MMailr bugfix To: TOPS-20@Score.Stanford.Edu Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12399379660.43.CRISPIN@SUMEX-AIM.Stanford.EDU> Thanks to Clive Dawson, the long-standing (6+ years!) and wierd bug which caused message notifications or dequeuing after "0 days" has finally been identified and stomped on. The problem was a string buffer overflowing into the notification control cell. This happened if the From: address was very long (more than 120 characters). The fix follows: REDIT 1(103) COMPARE by user CRISPIN, 18-May-88 14:01:23 File 1: SS:MMAILR.MAC.521 File 2: SS:MMAILR.MAC.522 ***** CHANGE #1; PAGE 1, LINE 9; PAGE 1, LINE 9 ;Version components MMLWHO==0 ;Who last edited MMAILR (0=developers) MMLVER==6 ;MMAILR's release version (matches monitor's) MMLMIN==1 ;MMAILR's minor version MMLEDT==^D521 ;MMAILR's edit version  --------------------------------- ;Version components MMLWHO==0 ;Who last edited MMAILR (0=developers) MMLVER==6 ;MMAILR's release version (matches monitor's) MMLMIN==1 ;MMAILR's minor version MMLEDT==^D522 ;MMAILR's edit version  ***** CHANGE #2; PAGE 7, LINE 90; PAGE 7, LINE 90 GTDLEN==.GTDML+10 GTDBLK: BLOCK GTDLEN+1 ;GTDOM% argument block RLYBFL==5*HSTBFL RLYBUF: BLOCK RLYBFL ;MX relays buffer USRNUM: BLOCK 1 FRMMSG: BLOCK 30  --------------------------------- GTDLEN==.GTDML+10 GTDBLK: BLOCK GTDLEN+1 ;GTDOM% argument block RLYBFL==5*HSTBFL RLYBUF: BLOCK RLYBFL ;MX relays buffer USRNUM: BLOCK 1  ***** CHANGE #3; PAGE 7, LINE 114; PAGE 7, LINE 113 PTHLST: BLOCK 40 ;List of host relays that are in the path STRBSZ==1000 ;Length of string buffers STRBUF: BLOCK STRBSZ ;String buffer, used globally STRBF1: BLOCK STRBSZ ;Alternative string buffer, used locally STRBF2: BLOCK STRBSZ ;Another alternate buffer used locally MEMEND==.-1 ;End of memory initialized at startup  --------------------------------- PTHLST: BLOCK 40 ;List of host relays that are in the path STRBSZ==1000 ;Length of string buffers STRBUF: BLOCK STRBSZ ;String buffer, used globally STRBF1: BLOCK STRBSZ ;Alternative string buffer, used locally STRBF2: BLOCK STRBSZ ;Another alternate buffer used locally FRMMSG=STRBF2+ MEMEND==.-1 ;End of memory initialized at startup  ------- 26-May-88 23:21:24-PDT,1256;000000000000 Return-Path: Received: from GSB-WHY.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 26 May 88 23:18:42-PDT Date: Thu 26 May 88 23:18:39-PDT From: Eric M. Berg Subject: DECUS Large Systems SIG going out of business... To: tops-20@Score.Stanford.EDU Reply-To: A.ERIC@GSB-HOW.STANFORD.EDU Phone-#s: 415/723-1576 (GSB), 415/329-9940 (home) Message-ID: <12401577283.11.A.ERIC@GSB-WHY.Stanford.EDU> Excerpted from a recent posting to the INFO-VAX mailing list... --------------- Date: 23 May 88 17:02:30 GMT From: pop!ctp@sally.utexas.edu (Clyde T. Poole) Subject: DECUS Questions Answered (last modified 23-May-1988) To: info-vax@kl.sri.com [....] 4) What is a SIG and a SIC? SIGs are Special Interest Groups. There are many SIGs in DECUS. [....] SICs are Special Interest Committees. These are really either new SIGs in the making or old SIGs going out of business. They provide the same kinds of services that SIGs provide but are short of volunteer leadership. Currently there is only one SIC, Large Systems, which is an old SIG going out of business because of the lack of a constituency. [....] ------- 27-May-88 07:07:49-PDT,2732;000000000000 Return-Path: Received: from sally.utexas.edu by SCORE.STANFORD.EDU with TCP; Fri 27 May 88 07:07:16-PDT Posted-Date: Fri, 27 May 88 08:52:51 cdt Received: by sally.utexas.edu (5.54/5.51) id AA18623; Fri, 27 May 88 09:07:32 CDT Date: Fri, 27 May 88 08:52:51 cdt From: ctp@red.cs.utexas.edu (Clyde T. Poole) Message-Id: <8805271352.AA28118@red> Received: by red (13.1/4.22) id AA28118; Fri, 27 May 88 08:52:51 cdt To: A.ERIC@gsb-how.stanford.edu Cc: tops-20@score.stanford.edu In-Reply-To: Eric M. Berg's message of Thu 26 May 88 23:18:39-PDT <12401577283.11.A.ERIC@GSB-WHY.Stanford.EDU> Subject: Re: DECUS Large Systems SIG going out of business... Woops! I should have posted something to the tops-20 list as soon as I returned from Spring DECUS. Because of a lack of volunteer leadership, the continued decline in session attendance and confusion over which SIG is responsible for what kind of sessions, the SIG Council declared the Large Systems SIG to be a SIC (Special Interest Committee) as of the end of Spring DECUS. This is not NECESSARILY the death knell for the Large Systems SIG. It simply means that an impartial third party from another SIG will be appointed by the SIG Council to help the SIC meet its obligations. If the SIC is unable to field a full complement of volunteer leadership within one year, it is possible that the SIC will then be dissolved. It is also possible that it will be reorganized with a new name and purpose (having nothing to do with our favorite 36 bit computers). I am sorry this is happening, but we all had to assume that it would come to this sooner or latter. I will continue at my position with the SIC Steering Committee (Communications Committee Voting Representative) as long as I can, but because of changes in the installed base of computers here at the UT Computer Sciences Dept., it will be VERY difficult for me to justify attending DECUS Symposia and administrative meetings. (When you don't have any Digital computers, your boss thinks it is strange that you want to spend University time and money on DECUS meetings.) Questions should probably be referred to Berkley Shands (SIC Chairman) at: BITNET: berkley@wunet ----- Clyde T. Poole - Technical Coordinator, Facilities and Equipment (in real life) DECUS U. S. Chapter, VAX and LS SIG, Newsletter Editor (in my spare time) Univ. of Texas at Austin ARPA/CSnet/NSFnet: ctp@cs.utexas.edu Dept. of Computer Sciences UUCP: {uunet,harvard,ihnp4}!ut-sally!ctp Taylor Hall 2.124 BITNET: ctp@UTADNX SPAN: UTADNX::CTP Austin, TX 78712-1188 VOICE: (512) 471-9551 "Life is a bitch ... and then you die" 2-Jun-88 14:02:32-PDT,690;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SCORE.STANFORD.EDU with TCP; Thu 2 Jun 88 13:53:10-PDT Date: Thu 2 Jun 88 16:55:47-EDT From: Rob Austein Subject: End of the Yellow Brick Road To: TOPS-20@SCORE.STANFORD.EDU Message-ID: <12403309823.55.SRA@XX.LCS.MIT.EDU> OZ.AI.MIT.EDU is being shut down, tomorow. This has been in the works for so long that the phrase "when OZ goes away" has become a local joke, but it's finally happening. The final precipitating factor was a head crash on the system sources pack. OZ is survived (for the moment) by 3 Twenex and 4 ITS machines. And yes, Toto.AI.MIT.EDU too. --Rob ------- 5-Jun-88 13:04:03-PDT,1785;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SCORE.STANFORD.EDU with TCP; Sun 5 Jun 88 13:01:07-PDT Date: Sun, 5 Jun 1988 14:01 MDT Message-ID: From: "Frank J. Wancho" To: TOPS-20@SCORE.STANFORD.EDU cc: WANCHO@SIMTEL20.ARPA Subject: You've been buffaloed! Possibly *the* most interesting and subtle piece of news presented by DEC at the Spring DECUS is the fact that out of the some 1,200 -10 and -20 installations in existence five years ago, DEC had expected a great migration would result in around 300 installations left to be supported at this time. The news is that far more of us have held on than expected - we are still over 900 installations strong!! In other words, less than a fourth chickened out instead of the three-forths DEC expected. The Great Migration Project was a bust! Now, it seems to me that with over 900 sites still alive and kicking, we would have more than enough interest in keeping a very active user group supported, regardless of the direction DEC is taking. Although we are greatly outnumbered by the mini sites, 900 is a very large and substantial number in the mainframe world user group. Five years ago, for whatever reasons may have been valid at the time, the large VAX sites were lumped into the LCG SIG, and I believe the result dilluted our base and interest rather than strengthened it. Now, that the LCG SIG is being disbanded, we have the opportunity to reorganize into our own again, just the -10 and -20 sites. I believe we can ignore the doomsayers who insist on pointing to those sites which are planning to abandon their machines and press on. We still have the numbers! What do you say? --Frank 5-Jun-88 14:50:43-PDT,1477;000000000000 Return-Path: Received: from vx2.GBA.NYU.EDU by SCORE.STANFORD.EDU with TCP; Sun 5 Jun 88 14:50:20-PDT Received: by vx2.GBA.NYU.EDU (5.51/) id AA29383; Sun, 5 Jun 88 17:49:29 EDT Return-Path: Received: by vx2.GBA.NYU.EDU (5.51/) id AA29341; Sun, 5 Jun 88 17:47:04 EDT Date: Sun, 5 Jun 1988 17:47:02 EDT Sender: Ittai Hershman From: Ittai Hershman To: "Frank J. Wancho" Office-Phone: 212-285-6080 Subject: Re: You've been buffaloed! In-Reply-To: Your message of Sun, 5 Jun 1988 14:01 MDT Message-Id: Resent-To: tops-20@score.stanford.edu Resent-Date: Sun, 5 Jun 1988 17:49:26 EDT Resent-From: Ittai Hershman Message-Id: Frank, I think this is a case of wishful thinking. The migration may be taking longer than DEC expected, but it is definitely happening. New York, for example, had one of the highest concentrations of DEC-20s. Many have disappeared; most of the remaining ones will be gone by the end of the year. The joke may be on DEC, however, because many of the academic sites that have migrated (we're 7/8ths done) to 8700s are displeased with them and beginning to look at Sun-4/280s. It's really a shame that Systems Concepts couldn't get their act together. The PDP-10 is DEAD, DEAD, DEAD. Sigh!!! -Ittai 5-Jun-88 16:44:41-PDT,2313;000000000000 Return-Path: Received: from MATHOM.CISCO.COM by SCORE.STANFORD.EDU with TCP; Sun 5 Jun 88 16:44:24-PDT Date: Sun 5 Jun 88 16:44:19-PDT From: Len Bosack Subject: Re: You've been buffaloed! To: WANCHO@SIMTEL20.ARPA cc: Tops-20@SCORE.STANFORD.EDU Message-ID: <12404126937.8.BOSACK@MATHOM.CISCO.COM> The current state of the 10s and 20s is exactly and only the confluence of Digital's actions and the fact the we -- the customers -- have collectively spent several billion dollars on this enterprise. As we imagine ourselves reasonable people, we desire to get a passing return on our investments. I expect we will have our 20s here for another 3-5 years and would acquire more should this prove the best overall solution. Almost all of the capital spending goes for UN*X boxes, however. Two thoughts come with the above: Perhaps there is a need to be filled by a strong 10/20 user group. Such a group would help Digital to fulfill its support commitment with a bit less guesswork than now obtains. When last I spoke with the Digital management, they wanted to give effective support and were willing to spend a significant amount of money to do so. Their problem was "What is to be done?". There was no consensus as to what was useful and what was not. While Digital wants to offer effective end-of-life support, there may yet be a modest market for a "Service Life Extension Program". Such a thing is clearly beyond their stated support program. It also presents a risk no reasonable independent corporation would undertake. It may be that we customers would find it desirable to undertake some of this project collectively. If there were to be a fair consensus on what was needed, there are legal vehicles to accomplish the end. An Example: While various power supply project have already been done, another sort of project is possible. Modern technology makes it possible to provide 4MW of fast main memory entirely within the processor backplane. The power savings are comparable to replacing the supplies. The machine would also run 1.5x to 2x faster (wild guess). A strong, focused user organization could help guide both Digital and any collective action in the customers' interest. Len Bosack ------- 6-Jun-88 07:07:50-PDT,1555;000000000000 Return-Path: Received: from sally.utexas.edu by SCORE.STANFORD.EDU with TCP; Mon 6 Jun 88 07:06:00-PDT Posted-Date: Mon, 6 Jun 88 08:55:49 cdt Received: by sally.utexas.edu (5.54/1.11) id AA21031; Mon, 6 Jun 88 09:06:19 CDT Date: Mon, 6 Jun 88 08:55:49 cdt From: ctp@red.cs.utexas.edu (Clyde T. Poole) Message-Id: <8806061355.AA07404@red> Received: by red (13.1/4.22) id AA07404; Mon, 6 Jun 88 08:55:49 cdt To: TOPS-20@score.stanford.edu In-Reply-To: "Frank J. Wancho"'s message of Sun, 5 Jun 1988 14:01 MDT Subject: Re: You've been buffaloed! Let me try again... The Large Systems SIG is NOT dead, it is just ill. If enough TOPS-10 and TOPS-20 people attended DECUS Symposia AND enough of these people were willing to take over the leadership AND these new leaders could produce enough volunteers to PRESENT and CHAIR sessions, the Large Systems SIC could be brought back to health. If this doesn't happen by the next Symposium, THEN the SIG will probably die. Another possibility is something along the line that Bozack (did I spell it correctly?) suggested. Maybe a seperate orginazation that meets occasionally for short periods of time (less expensive than DECUS) and invites the appropriate management from DEC to meet with them. Unfortunately The University of Texas at Austin is one of the 900 sites that is alive and kicking but about to die. Both the -20's here will be turned off on August 31, 1988. So passes a great machine... ctp 6-Jun-88 07:14:59-PDT,749;000000000000 Return-Path: Received: from bu-it.BU.EDU by SCORE.STANFORD.EDU with TCP; Mon 6 Jun 88 07:14:01-PDT Received: from BU-CS.BU.EDU by bu-it.BU.EDU (5.58/4.7) id AA24398; Mon, 6 Jun 88 10:12:52 EDT Return-Path: Received: by bu-cs.bu.edu (5.31/4.7) id AA17760; Mon, 6 Jun 88 10:15:42 EDT Date: Mon, 6 Jun 88 10:15:42 EDT From: bzs%bu-cs.bu.edu@bu-it.BU.EDU (Barry Shein) Message-Id: <8806061415.AA17760@bu-cs.bu.edu> To: ctp@red.cs.utexas.edu Cc: TOPS-20@score.stanford.edu In-Reply-To: Clyde T. Poole's message of Mon, 6 Jun 88 08:55:49 cdt <8806061355.AA07404@red> Subject: You've been buffaloed! Maybe the independent consortium could be called the "Ajar Software Foundation". 6-Jun-88 07:21:19-PDT,1237;000000000000 Return-Path: Received: from TOPS20.DEC.COM by SCORE.STANFORD.EDU with TCP; Mon 6 Jun 88 07:20:23-PDT Date: 6 Jun 1988 1018-EDT From: "Reed B. Powell" To: tops-20@score.stanford.edu High-Performance-Systems-Marketing: LCG-DEC10-20 Location: "297-4261 MRO2-2/2C (Pole 11B)" REPLY: "GIDNEY:: or HPSVAX::" Subject: "you've been buffaloed" Message-ID: <"MS11(6040)+GLXLIB6(0)" 12404286077.222.64.5861 at TOPS20.DEC.COM> Two points of clarification (from the source of those numbers, by the way!): You are using numbers that represent the numbers of machines, not sites! The number of sites peaked at ~830-840, and is now down to around ~600. This includes >~100 2020 sites outside of the USA. Our (digital's) expectation 5 years ago was that 3/4 of the user base would be on their way, or finished, moving to VAXes, not that the LCG systems would be all gone by now. That in fact is how things stand at this time: most of the 10/20 sites are in the process of moving. I'm sorry if the numbers and graphs I did for Connie Davis at DECUS were a bit confusing, and did not clearly state Digital's perception of events, but ... -reed powell -------- 6-Jun-88 11:47:46-PDT,2651;000000000000 Return-Path: Received: from ardvax.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 6 Jun 88 11:47:21-PDT Received: from KSL-1186-4.Stanford.EDU by ardvax.stanford.edu with TCP; Mon, 6 Jun 88 11:47:22 PDT Date: Mon, 6 Jun 88 11:41:52 PDT From: Mark Crispin Subject: 10/20 interest group To: TOPS-20@score.stanford.edu Message-Id: <611594864.A0169.KSL-1186-4.Crispin@SUMEX-AIM.Stanford.EDU> This is in response to Clyde Poole's message about DECUS. I created this distribution list 9 years ago. I am a systems programmer at a site that has a 2065 and a 2020, and from time to time I update bits on these machines. The 2065's plug will be pulled anywhere from 1-3 years from now. The 2020 will probably stay around forever. I've provided software support for two 2065 systems, one of which has *no* plug-pulling plans and the other of which has had the date repeatedly pushed back "one more year". To top it all off, I personally own two 2020 systems, one of which is operational and is known to the net as PANDA.PANDA.COM. Obviously, I care a helluva lot about 20's. The problem with DECUS is that for the most part recent DECUS symposia have been a collossal waste of time and money. The VAX sessions are completely uninteresting to me, and the 10/20 sessions have fallen into one of these categories: . bitching and moaning about how rotten DEC has treated us or at Systems Concepts for not panning out as the White Knight. (not too many of these recently) . glassy-eyed DECies talking about how wonderful the next version of the operating system is going to be, as if nothing is going on, and dead silence if you ask about languages or layered products. . re-hashing stuff that many of us already know about, e.g. tools, domains, etc. . commiserating our shared fate, typically with generous amounts of alcohol. This may be fine and good, but it's damn difficult to economically justify the (ever-soaring!!) expense of going to a DECUS symposium. It now costs more to go to DECUS for one day than it did to go for the entire week a couple of years ago. I think a separate meeting from the mass symposia would be a good idea. I reject the notion of it being separate from DECUS -- we **ARE** DEC users, so why the push to kick us out of DECUS (and DECUS support!). Therefore, I suggest reviving the old 10/20 symposia. Maybe it only needs to be a day or two, and it would be much smaller scale than the VAX-zoo symposia. Maybe, it'd even be worthwhile to go to. 6-Jun-88 13:08:04-PDT,4017;000000000000 Return-Path: Received: from sally.utexas.edu by SCORE.STANFORD.EDU with TCP; Mon 6 Jun 88 13:05:51-PDT Posted-Date: Mon, 6 Jun 88 15:02:31 cdt Received: by sally.utexas.edu (5.54/1.12) id AA28752; Mon, 6 Jun 88 15:06:02 CDT X-Notice: Mail into the domain CS.UTEXAS.EDU should be routed through the relay host CS.UTEXAS.EDU. SMTP connections to our other hosts will be discontinued approximately 1-Aug-88. Date: Mon, 6 Jun 88 15:02:31 cdt From: ctp@red.cs.utexas.edu (Clyde T. Poole) Message-Id: <8806062002.AA08096@red> Received: by red (13.1/4.22) id AA08096; Mon, 6 Jun 88 15:02:31 cdt To: Crispin@sumex-aim.stanford.edu Cc: TOPS-20@score.stanford.edu In-Reply-To: Mark Crispin's message of Mon, 6 Jun 88 11:41:52 PDT <611594864.A0169.KSL-1186-4.Crispin@SUMEX-AIM.Stanford.EDU> Subject: Re: 10/20 interest group Ah... someone took the bait... Posted-Date: Mon, 6 Jun 88 11:41:52 PDT Date: Mon, 6 Jun 88 11:41:52 PDT From: Mark Crispin [lots of stuff deleted] Obviously, I care a helluva lot about 20's. Caring about -20's and caring about DECUS are two VERY different things. No one gets anything from DECUS if no one puts anything in. The problem with DECUS is that for the most part recent DECUS symposia have been a collossal waste of time and money. The VAX sessions are completely uninteresting to me, and the 10/20 sessions have fallen into one of these categories: . bitching and moaning about how rotten DEC has treated us or at Systems Concepts for not panning out as the White Knight. (not too many of these recently) . glassy-eyed DECies talking about how wonderful the next version of the operating system is going to be, as if nothing is going on, and dead silence if you ask about languages or layered products. . re-hashing stuff that many of us already know about, e.g. tools, domains, etc. . commiserating our shared fate, typically with generous amounts of alcohol. Interesting that you should say all of the above. I agree with it pretty much. The question is how did this come about? Its really VERY simple. The Large Systems SIG has had VERY LITTLE support from its constituancy. When was the last time you presented a session at a DECUS Symposium Mark? The sessions you have seen at DECUS are what the Steering Committee was able to produce WITHOUT anyone returning a Call For Participation. This may be fine and good, but it's damn difficult to economically justify the (ever-soaring!!) expense of going to a DECUS symposium. It now costs more to go to DECUS for one day than it did to go for the entire week a couple of years ago. Absolutely correct. For a couple of years the Steering Committee has tried to keep all the DEC-10 -20 sessions on 3 consecutive days, so that you didn't have to pay for the entire 5 day symposium if you didn't want to. I think a separate meeting from the mass symposia would be a good idea. I reject the notion of it being separate from DECUS -- we **ARE** DEC users, so why the push to kick us out of DECUS (and DECUS support!). Therefore, I suggest reviving the old 10/20 symposia. Maybe it only needs to be a day or two, and it would be much smaller scale than the VAX-zoo symposia. Maybe, it'd even be worthwhile to go to. If there were volunteers to GIVE and CHAIR sessions and to man the Steering Committee, there would be no problem with continuing the SIG. It isn't even necessary to have a seperate symposia. Simply scheduling for one or two days at the regular meetings would work just fine. We need to focus on the REAL problem here, that is the lack of interest in PARTICIPATING in the DECUS leadership or in preparing and giving interesting and useful sessions at symposia. Without volunteers that can and will commit time and effort, all the complaining in the world will not help. ctp 6-Jun-88 13:47:14-PDT,2094;000000000000 Return-Path: <@SUMEX-AIM.Stanford.EDU:Crispin@SUMEX-AIM.Stanford.EDU> Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 6 Jun 88 13:47:00-PDT Received: from KSL-1186-4.STANFORD.EDU by SUMEX-AIM.Stanford.EDU with TCP; Mon, 6 Jun 88 13:44:52 PDT Date: Mon, 6 Jun 88 13:39:24 PDT From: Mark Crispin Subject: Re: 10/20 interest group To: ctp@red.cs.utexas.edu cc: TOPS-20@score.stanford.edu Message-ID: <611601916.A0076.KSL-1186-4.Crispin@SUMEX-AIM.Stanford.EDU> In-Reply-To: <8806062002.AA08096@red> Clyde - You have missed the point completely. The current DECUS VAX-zoo is too expensive to go to even for one day (especially for one day). I lay a lot of blame for it squarely on DECUS management's shoulder. The DECUS symposia have become high-overhead with a great deal of extraneous frills; what's more, DECUS symposia pricing in recent years has been established to discourage anything less than full-week memberships. Don't deny it, the DECUS staff has admitted as much! No matter how interesting any 10/20 session may be at the VAX-zoo, I cannot justify going to such an expensive symposium in terms of time or money. I can not/will not spend a week at a symposia for which there is only a day's worth of sessions which are interesting (I could care less about the migration-to-VMS sessions). I can not/will not spend several hundred dollars for a single day meeting, particularly if it's unlikely I'll hear anything I don't already know. The VAX-zoo is probably perfect as it is for the VAX users, who have an action-packed week full of fun and thrills. It is utterly unsuited for us, in any form. Until/unless we have a meeting which is exclusively 10/20 oriented and is priced towards what we will get out of it, "include me out." I won't go, much less consider presenting any sessions. Is DECUS willing to offer 10/20 sites 1-day attendance at the VAX-zoo for the 10/20 sessions for $100? I doubt it. So don't even mention the idea. -- Mark -- 20-Jun-88 06:01:45-PDT,568;000000000000 Return-Path: Received: from MATH.AMS.COM by SCORE.STANFORD.EDU with TCP; Mon 20 Jun 88 05:54:27-PDT Date: Mon 20 Jun 88 08:44:39-EDT From: Betsy Ramsey Subject: IPABFL Bugchks To: TOPS-20@SCORE.STANFORD.EDU cc: EWR@VAX01.AMS.COM Message-ID: <12407939007.54.EWR@MATH.AMS.COM> I'm running a V6.1 AP15 AN monitor, and I'm getting IPABFL bugchks about once every ten days. We're having to reboot to clear this. Anyone else have this problem or know of a fix for it? I'm not a source site. Thanks. ------- 23-Jun-88 14:32:32-PDT,847;000000000000 Return-Path: Received: from research.att.com by SCORE.STANFORD.EDU with TCP; Thu 23 Jun 88 14:21:24-PDT From: postmaster@research.att.com Date: Thu, 23 Jun 88 17:20:05 EST >From: FS$JSUPPLEE@VAXC.STEVENS-TECH.EDU (Jim Supplee, Physics Dept.) To: tms%whuts@att.arpa Subject: Is this working? X-VMS-To: TOMS Message-Id: <8852317206.20200973.FS$JSUPPLEE> Tom, Hello, Hello. After many attempts, I finally found an address for you that does not give any immediate error messages; maybe we're connected?? If you do really get this, please let me know-- either by electronic reply or (if that fails) call 420-5705 or 653-8286. Hope you're having a good summer. I'll be working at Drew beginning July 25. Jim ------------ 27-Jun-88 16:32:03-PDT,428;000000000000 Return-Path: Received: from SRI-NIC.ARPA by SCORE.STANFORD.EDU with TCP; Mon 27 Jun 88 16:28:05-PDT Date: Mon, 27 Jun 88 16:25:12 PDT From: Susan Kahn Subject: Version numbers on UNIX To: tops20@SCORE.STANFORD.EDU cc: skahn@SRI-NIC.ARPA Message-ID: <12409890624.17.SKAHN@SRI-NIC.ARPA> Does anyone know of an implementation of file version numbers on UNIX? Susan ------- 10-Jul-88 20:21:39-PDT,3202;000000000000 Return-Path: Received: from uunet.UU.NET by SCORE.STANFORD.EDU with TCP; Sun 10 Jul 88 20:19:52-PDT Received: from munnari.UUCP by uunet.UU.NET (5.59/1.14) with UUCP id AA28541; Sun, 10 Jul 88 23:19:28 EDT Message-Id: <8807110319.AA28541@uunet.UU.NET> Received: from kokab.cc.deakin.oz (via mulga) by munnari.oz with SunIII (5.5) id AA13813; Mon, 11 Jul 88 13:00:35 EST (from ccw@kokab.cc.deakin.oz for uunet!tops20@score.stanford.edu) Date: Mon, 11 Jul 88 09:02:34 EST From: munnari!kokab.cc.deakin.oz.au!ccw@uunet.UU.NET (Craig Warren) Received: by kokab.cc.deakin.oz (4.0) id AA05610; Mon, 11 Jul 88 09:02:34 EST X-Mailer: Mail User's Shell (6.3 6/25/88) To: tops20@score.stanford.edu Subject: Problems with DBMS And Cobol-13 I have just upgraded to Tops20 6.1 (At last!), and have installed Cobol-V13 and DBMS 6.1. Unfortunately something is wrong. I have rebuilt the Cobol runtime system to include support for DBMS, but I am having trouble with loading routines that include DBMS verbs: 12:55:58 MONTR $@Load/NOSY PRBSOC,PRDPRM,PPRMVL,PZNMPD,PWKDAY,A:A/LIB,Z:Z/LIB,NAME,%"VERSION:0(3744)" 12:56:20 USER MACRO: NAME 12:56:21 USER LINK: Loading 12:56:28 USER ?LNKUGS 4 undefined global symbols 12:56:28 USER CLOSED 405666 12:56:28 USER FIND5 405257 12:56:28 USER GETS 405354 12:56:28 USER JBTRAN 405566 12:56:28 MONTR $ .... Here are some size details: 13:01:15 MONTR @Vdirectory Subsys:Cobol,Subsys:Coblib,Subsys:Cobots-v13,Subsys:dbms 13:01:16 MONTR 13:01:16 MONTR PS: 13:01:16 MONTR COBOL.EXE.2;P777752 203 103936(36) 9-Jul-88 17:35:37 OPERATOR 13:01:16 MONTR .HLP.1;P777752 2 4802(7) 30-Jun-83 04:51:48 NIXON 13:01:16 MONTR COBLIB.REL.5;P777752 127 64626(36) 10-Jul-88 11:32:52 OPERATOR 13:01:17 MONTR COBOTS-V13.EXE.2;P777752 85 43520(36) 9-Jul-88 17:00:28 OPERATOR 13:01:17 MONTR DBMS.REL.3;P777752 69 35328(36) 9-Jul-88 17:00:00 OPERATOR 13:01:17 MONTR 13:01:17 MONTR Total of 486 pages in 5 files 13:01:17 MONTR $@Get Subsys:Link 13:01:17 MONTR 13:01:17 MONTR $@Information Version 13:01:17 MONTR Snark - "The Last DECsystem-20", TOPS-20 Monitor 6.1(7030) 13:01:17 MONTR TOPS-20 Command processor 6.1(273) 13:01:17 MONTR Program is LINK, version is 6(2364) 13:01:17 MONTR PDVs: Program name LINK, version 6(2364) 13:01:17 MONTR $@Get Subsys:Cobol 13:01:18 MONTR 13:01:18 MONTR $@Information Version 13:01:18 MONTR Snark - "The Last DECsystem-20", TOPS-20 Monitor 6.1(7030) 13:01:18 MONTR TOPS-20 Command processor 6.1(273) 13:01:18 MONTR Program is COBOL, version is 13(1515) 13:01:18 MONTR $ 13:01:19 MONTR Killed by OPERATOR, TTY 173 13:01:19 MONTR Killed Job 11, User OPERATOR, Account , TTY 203, 13:01:19 MONTR at 10-Jul-88 13:01:19, Used 0:00:02 in 0:00:05 I have read fairly carefully the installation instructions in both Installing Cobol and Installing DBMS, and I expect that I have done something wrong in one of these steps. Can anyone provide any insight? Craig Warren ARPA: ccw%charlie.oz.au@uunet.uu.net UUCP: ...!uunet!munnari!charlie.oz!ccw 13-Jul-88 10:00:02-PDT,658;000000000000 Return-Path: Received: from SRI-NIC.ARPA by SCORE.STANFORD.EDU with TCP; Wed 13 Jul 88 09:56:53-PDT Mail-From: SKAHN created at 27-Jun-88 16:25:12 Date: Mon, 27 Jun 88 16:25:12 PDT From: Susan Kahn Subject: Version numbers on UNIX To: tops20@SCORE.STANFORD.EDU cc: skahn@SRI-NIC.ARPA Message-ID: <12409890624.17.SKAHN@SRI-NIC.ARPA> ReSent-Date: Wed, 13 Jul 88 09:43:52 PDT ReSent-From: Susan Kahn ReSent-To: tops20@score.stanford.edu ReSent-Message-ID: <12414011869.29.SKAHN@SRI-NIC.ARPA> Does anyone know of an implementation of file version numbers on UNIX? Susan ------- 13-Jul-88 15:18:13-PDT,1962;000000000000 Return-Path: Received: from unix.SRI.COM by SCORE.STANFORD.EDU with TCP; Wed 13 Jul 88 15:17:05-PDT Received: by unix.SRI.COM (5.31/5.14) id AA11040; Wed, 13 Jul 88 15:17:18 PDT Received: by orc.olivetti.com (3.2/SMI-3.2) id AA06455; Wed, 13 Jul 88 15:11:50 PDT Date: Wed, 13 Jul 88 15:11:50 PDT From: roode@orc.olivetti.com (David Roode) Message-Id: <8807132211.AA06455@orc.olivetti.com> To: tops-20@score.stanford.edu Subject: DECsystem30 A story in today's San Jose Mercury says that DEC is preparing to launch an entire range of machines based on the MIPS processor design. I have heard quietly that a new "MicroVax" is about to be released, and that it may well be a multiprocessor design. Given their current product positioning, I was having a hard time seeing how they could introduce something interesting without it competing with their existing VAX business. It seems rather soon for an additional MicroVax product such as this one is supposed to be--significantly more processor power and better price/performance than the MicroVAX 3000 series, not just a new package like the most recent Sun announcement. If DEC were to introduce a non-VAX processor system, it would avoid all of these pitfalls. It would also open up many cans of worms, and would be very interesting to watch. Supposedly DEC is feeling increased competition from non-VAX processors. In some senses, what they would like to do is to sell VAX to those who will pay for it, yet have something else to sell to the customers who are awake. Recall that they dropped the PDP-10/DEC-20 line ostensibly because it was uneconomical for them to support two different architectures. If DEC makes VMS run on the new processor series, and creates source level compatibility for compilers, they could have multiple architectures. Then though, they would start to impact their lucratively priced sales of VAX processors. 14-Jul-88 10:59:12-PDT,3001;000000000000 Return-Path: Received: from bu-it.BU.EDU by SCORE.STANFORD.EDU with TCP; Thu 14 Jul 88 10:53:36-PDT Received: from BU-CS.BU.EDU by bu-it.BU.EDU (5.58/4.7) id AA20378; Wed, 13 Jul 88 22:53:44 EDT Return-Path: Received: by bu-cs.bu.edu (5.31/4.7) id AA17591; Wed, 13 Jul 88 22:57:02 EDT Date: Wed, 13 Jul 88 22:57:02 EDT From: bzs%bu-cs.bu.edu@bu-it.BU.EDU (Barry Shein) Message-Id: <8807140257.AA17591@bu-cs.bu.edu> To: roode@orc.olivetti.com Cc: tops-20@score.stanford.edu In-Reply-To: David Roode's message of Wed, 13 Jul 88 15:11:50 PDT <8807132211.AA06455@orc.olivetti.com> Subject: DECsystem30 Interesting, I recently heard just this as a rumor, guess it was true. I've heard rumors of some attempts (internally) to make VMS portable but I've never given them much credence (I believe fully that someone had the job to evaluate how hard that would be to do, but I doubt strongly that the conclusion was affirmative, I think it's architected for the Vax in many ways, nothing is impossible, but I'd be shocked.) Pieces could start to show up (like the VMS Fortran compiler), but that's neither here nor there. So that leaves one with the conclusion that this new MIPS chip based processor runs only Unix (Ultrix? MIPSix [they have a Unix themselves that's supposed to be very good]? AIX? [OSF]) That makes some sense. The current major MIPS VAR is Silicon Graphics (other than MIPS which doesn't make workstations with graphics/bitmap heads.) They (SGIC) tend to market high end graphics workstations tho they'll be announcing something soon in a lower price range, could be pretty head-on (or, put another way, I wonder what Silicon Graphics' future is, particularly in terms of obtaining MIPS chips.) I thought about the possibility of a dual architecture model with a MIPS chip and a uVax chip, able to run Unix and VMS, but it really doesn't make any sense (I only mention it to see if someone else can come up with a reasoning for that, just a speculation.) One major problem would be that you'd probably need 1GB of disk to get everything on, and administration would be a nightmare (not to mention communications between the two systems), yet somehow it seems worth pondering for a moment. I do think the old comment is coming true about the Vax, they couldn't make it fast and they couldn't make it cheap (not to completely malign a company with $10B in sales...) An interesting data point is that the last I checked the R3000 (current MIPS chip) ran the Dhrystone benchmark (non-floating pt, non-IO) a little faster than the IBM3090 (well, the 3090 we have here, I think there's a little faster 3090 out now, still in the same ballpark.) I think FP is around 3.5MFlops (nothing to be ashamed of, but not a super-computer), not sure what it would rate on I/O, but an *expensive* one is only around $50K. This is from memory. Interesting. -Barry Shein, Boston University 15-Jul-88 05:57:42-PDT,1080;000000000000 Return-Path: Received: from lindy.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 15 Jul 88 05:57:10-PDT Received: by lindy.Stanford.EDU (4.0/4.7); Fri, 15 Jul 88 05:57:37 PDT Received: by Forsythe.Stanford.EDU; Fri, 15 Jul 88 05:59:25 PDT Received: by INDYCMS (Mailer X1.25) id 7649; Fri, 15 Jul 88 07:51:21 EST Date: Fri, 15 Jul 1988 07:40 EST From: Mark H. Wood Subject: Re: DECsystem30 To: I'd read about the MIPS deal in the trade papers, and I wonder if the MIPS chips aren't destined to hide inside some kind of dedicated X-window client system; that is, a very-high-performance terminal that speaks DECwindows but provides no local processing to the user. I really don't see DEC introducing another architecture at this time, *especially* one that would run Un*x before they could have VMS ready! I don't think we'll see the MIPS chips in an independent, general-purpose computer from DEC, for some time to come. 15-Jul-88 06:34:51-PDT,2144;000000000000 Return-Path: Received: from bu-it.BU.EDU by SCORE.STANFORD.EDU with TCP; Fri 15 Jul 88 06:34:36-PDT Received: from BU-CS.BU.EDU by bu-it.BU.EDU (5.58/4.7) id AA05371; Fri, 15 Jul 88 09:24:26 EDT Return-Path: Received: by bu-cs.bu.edu (5.31/4.7) id AA07581; Fri, 15 Jul 88 09:27:47 EDT Date: Fri, 15 Jul 88 09:27:47 EDT From: bzs%bu-cs.bu.edu@bu-it.BU.EDU (Barry Shein) Message-Id: <8807151327.AA07581@bu-cs.bu.edu> To: IMHW400%INDYCMS.BITNET@Forsythe.Stanford.EDU Cc: TOPS-20@SCORE.STANFORD.EDU In-Reply-To: Mark H. Wood's message of Fri, 15 Jul 1988 07:40 EST <8807151301.AA06596@bu-cs.bu.edu> Subject: DECsystem30 >I'd read about the MIPS deal in the trade papers, and I wonder if the MIPS >chips aren't destined to hide inside some kind of dedicated X-window client >system; that is, a very-high-performance terminal that speaks DECwindows >but provides no local processing to the user. I really don't see DEC >introducing another architecture at this time, *especially* one that would >run Un*x before they could have VMS ready! I don't think we'll see the MIPS >chips in an independent, general-purpose computer from DEC, for some time >to come. I wouldn't discount anything (neither does DEC, heh heh, joke), but putting a ~12MIPs or more general purpose CPU in just to run X-windows would seem like a strange approach to me, why not just add a good graphics co-processor? They exist. DEC released the GPX with Unix before VMS, it has happened, particularly in the workstation arena (wasn't the "calypso", a four CPU vax, recently released Unix-first? Not sure, it may have been simultaneous tho the people I've heard of being approached before official announcement were only talking about Unix.) It's quite possible that Unix is just that much stronger in areas like CAD/CAM that it's justified to emphasize it over VMS within such product lines, even in DEC's mind. I don't think anyone has accused VMS of being a particularly attractive graphics *workstation* environment, unless you happen to already be committed to it. -Barry Shein 15-Jul-88 06:51:01-PDT,1623;000000000000 Return-Path: Received: from vx2.GBA.NYU.EDU by SCORE.STANFORD.EDU with TCP; Fri 15 Jul 88 06:50:48-PDT Received: by vx2.GBA.NYU.EDU (5.51/) id AA08711; Fri, 15 Jul 88 09:49:08 EDT Date: Fri, 15 Jul 1988 9:49:06 EDT Sender: Ittai Hershman From: Ittai Hershman To: Mark H.Wood Cc: Office-Phone: 212-285-6080 Subject: Re: DECsystem30 In-Reply-To: Your message of Fri, 15 Jul 1988 07:40 EST Message-Id: I'd read about the MIPS deal in the trade papers, and I wonder if the MIPS chips aren't destined to hide inside some kind of dedicated X-window client system; that is, a very-high-performance terminal that speaks DECwindows but provides no local processing to the user. I find that hard to swallow. After all a 68020 could easily handle that, and no one would blink an eyelash if Digital bought into that technology. It would also be *much* cheaper. Actually, I think that Digital is making a serious mistake. They have spent the last 5 years putting all their eggs in one basket for strategic marketing reasons (the ubiquitous "Digital has it now" coupled with the single architecture concept). Its bad enough for them to have to admit that we were all correct when we told them that the VAX is not going to be able to sustain them, but to go out and buy someone elses technology -- that's really makes them look bad. Personally, I'd rather buy into the SUN-4... -Ittai 16-Jul-88 08:18:43-PDT,549;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SCORE.STANFORD.EDU with TCP; Sat 16 Jul 88 08:15:26-PDT Date: Sat, 16 Jul 1988 09:15 MDT Message-ID: From: "Frank J. Wancho" To: TOPS-20@SCORE.STANFORD.EDU cc: WANCHO@SIMTEL20.ARPA Subject: PING for TOPS-20? Does anyone have a working TOPS20 version of the Unix "ping" program? Unfortunately, the statistics gathering programs which use the hooks in the BBN TCP monitors won't help here. --Frank 18-Jul-88 17:51:36-PDT,1414;000000000000 Return-Path: Received: from uunet.UU.NET ([192.12.141.129].#Internet) by SCORE.STANFORD.EDU with TCP; Mon 18 Jul 88 16:42:13-PDT Received: from munnari.UUCP by uunet.UU.NET (5.59/1.14) with UUCP id AA14185; Mon, 18 Jul 88 19:41:19 EDT Message-Id: <8807182341.AA14185@uunet.UU.NET> Received: from kokab.cc.deakin.oz (via mulga) by munnari.oz with SunIII (5.5) id AA05523; Tue, 19 Jul 88 08:59:00 EST (from ccw@kokab.cc.deakin.oz for uunet!TOPS20@score.stanford.edu) Date: Tue, 19 Jul 88 08:44:23 EST From: munnari!kokab.cc.deakin.oz.au!ccw@uunet.UU.NET (Craig Warren) Received: by kokab.cc.deakin.oz (4.0) id AA05468; Tue, 19 Jul 88 08:44:23 EST X-Mailer: Mail User's Shell (6.3 6/25/88) To: TOPS20@score.stanford.edu Subject: 6.1 Upgrade problems Problem: Many TTYSTP BUGINF's Occasional TTYBBO BUGCHK's Big Buffer Overflow's Many Front-End crashes Somtimes proceeded by DTESUI BUGINF's often just get 11-HALT B03 Scenario: Just upgraded to 6.1 + RSX-20F VB15-21 Suspects: We do block data input from a number of our terminals, which seems to cause the Front-End a great amount of difficulty. Solution: ? - Anyone seen a similar problem? Craig Warren ARPA: ccw%charlie.oz.au@uunet.uu.net UUCP: ...!uunet!munnari!charlie.oz!ccw 20-Jul-88 16:26:10-PDT,876;000000000000 Return-Path: Received: from dorsai.ics.hawaii.edu by SCORE.STANFORD.EDU with TCP; Wed 20 Jul 88 16:24:30-PDT Received: from uhccux.uhcc.hawaii.edu by dorsai.ics.hawaii.edu with SMTP id 4201; Wed, 20 Jul 88 13:25:56 HST Date: Wed, 20 Jul 88 10:16:00 HST From: Jeffrey Blomberg To: tops-20@SCORE.STANFORD.EDU Subject: Telnet Message-Id: Aloha! We are running telnet 6.1(935) and occasionally encounter IPIBLP bugchks when a user runs telnet to login to our Ultrix system. I was wondering if anyone else has encountered these bugchks? Is there a newer (should I venture to say 'better') version of telnet floating around. -Jeff ps: We have already rebuilt the monitor to increase the buffer size. Also, we are communicating over an NI. 20-Jul-88 17:40:55-PDT,1330;000000000000 Return-Path: <@SUMEX-AIM.Stanford.EDU:Crispin@SUMEX-AIM.Stanford.EDU> Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 20 Jul 88 17:40:31-PDT Received: from KSL-1186-4.STANFORD.EDU by SUMEX-AIM.Stanford.EDU with TCP; Wed, 20 Jul 88 17:36:22 PDT Date: Wed, 20 Jul 88 17:34:17 PDT From: Mark Crispin Subject: re: Telnet To: Jeffrey Blomberg cc: TOPS-20@Score.Stanford.EDU Message-ID: <615417608.A2688.KSL-1186-4.Crispin@SUMEX-AIM.Stanford.EDU> Jeff - Your message's headers had linefeeds instead of CR/LF's in it. Perhaps there is a bug in the mail program you are using on uhccux.uhcc.hawaii.edu; you may want to check up on that. My current version of TELNET (I wrote it) is 6.1(959). However, none of the changes between 935 and 959 would correct your problem, and anyway, the problem is a monitor not a Telnet problem. I suggest that you try to increase the value of NNIPIB (in STG.MAC, this is the number of buffers to keep around) from ^D40 to some higher value, rebuild your monitor, and see if that doesn't make the problem go away. You may also want to put on a network line monitor to see if you aren't getting something like a broadcast storm or other strange behavior. -- Mark -- 20-Jul-88 18:48:19-PDT,1752;000000000000 Return-Path: Received: from lindy.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 20 Jul 88 18:47:59-PDT Received: by lindy.Stanford.EDU (4.0/4.7); Wed, 20 Jul 88 18:48:36 PDT Received: by Forsythe.Stanford.EDU; Wed, 20 Jul 88 18:50:25 PDT Date: Wed, 20 Jul 88 18:50:25 PDT From: To: tops-20@score.stanford.edu Subject: Re: 6.1 Upgrade problems Received: from Stasis.MRC.AdhocNet.CA by UcEdu.UNCA.AdhocNet.CA with DECNET ; Wed, 20 Jul 88 08:59:47 MDT Date: Wed, 20 Jul 88 08:58:15 MDT From: rmf%Ins.MRC.AdhocNet.CA%Stasis.MRC.AdhocNet.CA@UNCAEDU. BITnet (Russ Forster) Message-Id: <880720085820.02m@Ins.MRC.AdhocNet.CA> Subject: Re: 6.1 Upgrade problems In-Reply-To: Your message <8807182341.AA14185@uunet.UU.NET> dated 19-Jul-1988 To: tops-20@score.stanford.edu > Problem: Many TTYSTP BUGINF's > Occasional TTYBBO BUGCHK's > Big Buffer Overflow's > Many Front-End crashes > Somtimes proceeded by DTESUI BUGINF's > often just get 11-HALT > B03 > Scenario: Just upgraded to 6.1 + RSX-20F VB15-21 The released version of RS-20F for 6.1 is 15-50. Maybe you should start there. /Russ ----- Russell M. Forster Mount Royal College DECnet: RMF @ { Flux | Stasis | Ins } Computer Operations BITnet: RForster @ UncaEdu.BITnet 4825 Richard Rd. S.W. USEnet: uunet!calgary!vaxa!forster Calgary, Alberta Phone: (403) 240-6052 T3E 6K6 22-Jul-88 19:59:24-PDT,1020;000000000000 Return-Path: Received: from lindy.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 22 Jul 88 19:58:40-PDT Received: by lindy.Stanford.EDU (4.0/4.7); Fri, 22 Jul 88 19:59:03 PDT Received: by Forsythe.Stanford.EDU; Fri, 22 Jul 88 20:00:40 PDT Received: from kth.se by KTH-BITNET-GATEWAY ; 23 Jul 88 02:52:35 GMT Received: from kicki.stacken.kth.se by kth.se (5.57+IDA+KTH/3.0) id AA27051; Sat, 23 Jul 88 04:52:26 +0200 Date: Sat, 23 Jul 88 04:54:56 +0200 From: ROLL%SESTAK.BITNET@Forsythe.Stanford.EDU (Peter Lothberg) To: tops-20@score.stanford.edu Subject: Ethernet interface for KL10 Message-Id: In these days when everyone gets rid of their KL processors, we are out trying to find a Ethernet interface. A NIA-20 or a MEIS or anything else that might work. Anyone out there that knews one that is just colecting dust or so? Peter Lothberg, Stacken Computer Club, roll@stacken.kth.se, roll@sestak.bitnet 24-Jul-88 01:39:56-PDT,1323;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SCORE.STANFORD.EDU with TCP; Sun 24 Jul 88 01:38:26-PDT Date: Sun, 24 Jul 1988 02:38 MDT Message-ID: From: "Frank J. Wancho" To: TOPS-20@SCORE.STANFORD.EDU cc: WANCHO@SIMTEL20.ARPA Subject: Wanted: Excess DECSYSTEM-20 equipment This is a repeat request. If any other goverment agency is about to excess their DECSYSTEM-20, particularly if it is a Model 2065, please contact me via netmail or at AV 258-6258 (505-678-6258) between 10am and 5pm MST. We are also interested in certain other equipment such as RP07-AA disk drives to support our every growing "public domain" collections, and any of the following: RP07-C Dual Access Kits - we can use four now, more later as we add drives. CI20-AA - we can use two to interconnect the second machine whenever it appears. SC-0008 - Star coupler to go with the CI20-AA. NIA20 - Ethernet Interface - grandious plans for an alternate path... DELNI - just one for now. A LAT box - maybe... We are also willing to consider indefinite loans of any of the above equipment. Any of the equipment must be DEC deinstalled so that it can qualify for continuing DEC maintenance once installed here. --Frank 26-Jul-88 23:45:48-PDT,1367;000000000000 Return-Path: Received: from MACBETH.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Tue 26 Jul 88 23:45:46-PDT Date: Sun 24 Jul 88 13:05:16-PDT From: Sean L. Welsh Subject: Othello Retired from Service To: System@MACBETH.STANFORD.EDU Message-ID: <12416932117.15.W.WELSH@MACBETH.STANFORD.EDU> ReSent-Date: Tue 26 Jul 88 23:43:39-PDT ReSent-From: Eric M. Berg ReSent-To: su-tops-20@SCORE.STANFORD.EDU ReSent-Message-ID: <12417572618.15.E.EMB@MACBETH.STANFORD.EDU> Due to an air-conditioning malfunction in the AIR computer room, Othello is down. AIR Facilities and Operations had planned to announce Othello's imminent retirement this week; we are instead taking the opportunity of this unplanned outage to remove Othello from service permanently. We will re-assign the network address "Othello" to Macbeth presently, in order that mail addressed to Othello will be delivered; however, we would like to advise you at this time to inform your correspondents to use one of the other AIR TOPS-20 addresses for mail. The Othello address will be retired eventually as well; AIR will endeavor to make this change with as little impact as practicable. Sean L. Welsh, Director Facilities and Operations Academic Information Resources ------- 7-Aug-88 11:59:56-PDT,1810;000000000000 Return-Path: Received: from VAX02.AMS.COM by SCORE.STANFORD.EDU with TCP; Sun 7 Aug 88 11:57:47-PDT Return-Path: <@SEED.AMS.COM,@MATH.AMS.COM:RELAY-INFO-VAX@CRVAX.SRI.COM> Received: from SEED.AMS.COM by VAX01.AMS.COM via SMTP with TCP; Sat, 6 Aug 88 01:50:10-EDT Received: from MATH.AMS.COM by SEED.AMS.COM with TCP; Sat 6 Aug 88 01:49:10-EDT Received: from CRVAX.SRI.COM by MATH.AMS.COM with TCP; Sat 6 Aug 88 01:49:11-EDT Received: From KL.SRI.COM by CRVAX.SRI.COM with TCP; Thu, 4 AUG 88 22:49:20 PDT Received: from ucbvax.berkeley.edu by KL.sri.com with TCP; Thu, 4 Aug 88 05:38:30 PDT Received: by ucbvax.berkeley.edu (5.59/1.28) id AA13467; Wed, 3 Aug 88 21:09:16 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-vax@kl.sri.com (info-vax@kl.sri.com) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 3 Aug 88 09:54:56 GMT From: clyde!watmath!julian!uwovax!brent@bellcore.com Subject: WHY ARE (were) THERE 36 BITS? Message-Id: <524@uwovax.uwo.ca> Sender: info-vax-request@kl.sri.com To: info-vax@kl.sri.com ReSent-date: Sun 7 Aug 88 14:58:07-EDT ReSent-from: Betsy Ramsey ReSent-to: TOPS-20@SCORE.STANFORD.EDU Some time ago there was a video called "Why are there 36 bits?" (or someting like that) shown at DECUS. I never saw it - too many other things going on I guess. Anyone remember it? Anyway, we are planning a "wake" for our KL which will me retired at the end of the month. Seems like a suitable presentation for such a solemn occasion. Assuming it exists, could I get a copy? And soon! Please reply to me with any hints you may have. If you would like to see it too, I'll post again about where I find it (if I do). Thanks. Brent. ------- 7-Aug-88 12:09:52-PDT,845;000000000000 Return-Path: Received: from bu-it.BU.EDU by SCORE.STANFORD.EDU with TCP; Sun 7 Aug 88 12:09:19-PDT Received: from BUITA.BU.EDU by bu-it.BU.EDU (5.58/4.7) id AA23880; Sun, 7 Aug 88 15:10:31 EDT Return-Path: Received: by buita (5.58/4.7) id AA10641; Sun, 7 Aug 88 15:10:34 EDT Date: Sun, 7 Aug 88 15:10:34 EDT From: budd@bu-it.BU.EDU Message-Id: <8808071910.AA10641@buita> To: com@bu-it.bu.edu, info-vax@kl.sri.com, tops-20@score.stanford.edu Subject: Re: WHY ARE (were) THERE 36 BITS? I was once asked a similar question when I was at a party of VMS types and it came out that I worked for LCG. Someone asked "what do you use the extra 4 bits for?". Before I could compose a better answer some semi-enlightened soul shouted "no-ops!!" I guess you had to be there. -Phil 8-Aug-88 09:08:51-PDT,1386;000000000001 Return-Path: Received: from VAX02.AMS.COM ([130.44.1.5].#Internet) by SCORE.STANFORD.EDU with TCP; Mon 8 Aug 88 09:06:07-PDT Date: Mon 8 Aug 88 12:05:29-EDT From: Reed Powell Subject: Re: 36-bit Tape Sender: EWR@VAX02.AMS.COM To: INFO-VAX@KL.SRI.COM, TOPS-20@SCORE.STANFORD.EDU Cc: Powell%HPSVAX.DEC@DECWRL.DEC.COM Reply-To: Powell%HPSVAX.DEC@DECWRL.DEC.COM Message-ID: <587059529.0.EWR@VAX02.AMS.COM> Mail-System-Version: From: HPSVAX::POWELL "Reed B Powell HPS Mktg" Date: 8-AUG-1988 08:57 Subj: RE: WHY ARE (were) THERE 36 BITS? Assuming this makes it through the gateways (and anyone sees this)... The video in question was run at the 25th Anniversary of 36 bits in DECUS celebration. The video itself is an internal DEC video, and was presented after receiving special dispensations, etc., from the Powers That Be (now the Powers That Been). I doubt if I can get the OK to send out random copies. The direct answer to your question is "so we could store 2 addresses in one word for handling linked lists in LISP, and 18-bits was enough to hold the highest possible address anyone would ever conceivably want to address." Remember that a lot of the motivation for the architecture was from LISP needs. -reed ------- 10-Aug-88 15:12:09-PDT,475;000000000000 Return-Path: Received: from SPAR-20.SPAR.SLB.COM by SCORE.STANFORD.EDU with TCP; Wed 10 Aug 88 15:10:24-PDT Date: Wed 10 Aug 88 15:14:00-PDT From: Doug Faunt Subject: MF20 power supply To: tops-20@SCORE.STANFORD.EDU Message-ID: <12421412000.22.FAUNT@SPAR-20.SPAR.SLB.COM> I have a broken one (as well as two running and a spare), and am wondering i anyone knows where I can get this one repaired. ------- 10-Aug-88 18:32:17-PDT,896;000000000000 Return-Path: Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 10 Aug 88 18:31:46-PDT Date: Wed, 10 Aug 88 18:28:40 PDT From: Mark Crispin Subject: KL10 request To: TOPS-20@Score.Stanford.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12421447436.52.CRISPIN@SUMEX-AIM.Stanford.EDU> A couple of hackers out in New Jersey have done some preliminary design work in the area of KL service life extension. One product they are thinking of is a 4MW memory board which will set inside the CPU cabinet. They are looking to acquire a KL10 for their hardware hacking efforts, since obviously you can't do this on a production machine. Does anybody have a KL they are willing to part with for this noble effort? -- Mark -- ------- 15-Aug-88 17:53:19-PDT,1264;000000000000 Return-Path: Received: from uunet.UU.NET by SCORE.STANFORD.EDU with TCP; Mon 15 Aug 88 17:47:15-PDT Received: from munnari.UUCP by uunet.UU.NET (5.59/1.14) with UUCP id AA21699; Mon, 15 Aug 88 20:46:55 EDT Message-Id: <8808160046.AA21699@uunet.UU.NET> Received: from kokab.cc.deakin.oz (via mulga) by munnari.oz with SunIII (5.5) id AA20774; Tue, 16 Aug 88 10:30:42 EST (from ccw@kokab.cc.deakin.oz for uunet!TOPS20@score.stanford.edu) Date: Tue, 16 Aug 88 10:25:58 EST From: munnari!kokab.cc.deakin.oz.au!ccw@uunet.UU.NET (Craig Warren) Received: by kokab.cc.deakin.oz (4.0) id AA06900; Tue, 16 Aug 88 10:25:58 EST X-Mailer: Mail User's Shell (6.3 6/25/88) To: TOPS20@score.stanford.edu Subject: Problem with Isam after upgrading to 6.1 I have a problem with Isam after upgrading to 6.1. Programs that access 2 Isam files eventually die with a ?PA1050: Illegal instruction 6,,0 at user 0 after running sometimes for several minutes. The programs dont necessarily have both Isam files open at the same time. If I change the programs to use only a single Isam file, they run correctly. What monitor resource does Isam require? Craig Warren ccw%charlie.oz.au@uunet.uu.net 22-Aug-88 15:42:54-PDT,2798;000000000000 Return-Path: Received: from columbia.edu by SCORE.STANFORD.EDU with TCP; Mon 22 Aug 88 15:39:27-PDT Received: from cunixc.cc.columbia.edu by columbia.edu (5.54/1.14) id AA13274; Mon, 22 Aug 88 15:59:03 EDT Received: by cunixc.cc.columbia.edu (5.54/5.10) id AA16346; Mon, 22 Aug 88 15:58:25 EDT Date: Mon, 22 Aug 1988 15:58:18 EDT From: Melissa To: tops20@score.stanford.edu Cc: bug-mm@cunixc.cc.columbia.edu Subject: Columbia-MM for Unix Message-Id: In September, if things go as planned, the Columbia Computer Center is getting rid of CU20B, our last DEC20. We're mostly moving to UNIX systems. I suspect there are a lot of sites like us out there, and I thought I should mention some good news for those moving to UNIX. Most of you have probably heard about CCMD, the COMND jsys package written in C. The first major program written using CCMD is MM, which is right now in Beta testing. We had hoped to be out of Beta testing by the end of the summer, but it looks like we won't make it. However, anyone who would like MM now is welcome to it. (See copyright notice below.) Whether you want MM now, or want it after Beta testing, send some mail to bug-mm@cunixc.cc.columbia.edu and we'll send you more info and put you on the announcement mailing list. If you grab a copy for testing, please register with us, so you'll get bug reports and patches. Columbia-MM is available via anonymous ftp from cunixc.cc.columbia.edu (128.59.40.130 since August 15). You'll have to cd to the mm subdirectory, from which you can get mm-intro.txt, which will explain the other files available. Versions of MM are being run on Ultrix, BSD 4.2/4.3, SunOS 3.2, SunOS 4.0, Pyramid, DYNIX 2.0 (Sequent Balance 21000), and Celerity systems. The HP-UX and System V ports are currently in progress. (At Columbia we only test MM under Ultrix 2.0 and SunOS 4.0, and rely on our beta testers for the other ports.) Hope this warms your little TOPS20 hearts :-)... --Melissa MM is: Copyright (c) 1986, 1987, 1988, The Trustees of Columbia University in the City of New York. Chris Maio, Computer Research Facilities, Computer Science Department, Fuat C. Baran, Howard Kaye, Melissa Metz, Academic Systems Group, Center for Computing Activities. Permission is granted to any individual or institution to use, copy, or redistribute this software so long as it is not sold for profit, provided that this notice and the original copyright notices are retained. Columbia University makes no representations about the suitability of this software for any purpose. It is provided "as is" without express or implied warranty. 22-Aug-88 16:08:50-PDT,947;000000000000 Return-Path: Received: from uunet.UU.NET by SCORE.STANFORD.EDU with TCP; Mon 22 Aug 88 16:07:56-PDT Received: from munnari.UUCP by uunet.UU.NET (5.59/1.14) with UUCP id AA09250; Mon, 22 Aug 88 04:41:52 EDT Message-Id: <8808220841.AA09250@uunet.UU.NET> Received: from kokab.cc.deakin.oz (via mulga) by munnari.oz with SunIII (5.5) id AA28464; Mon, 22 Aug 88 17:34:31 EST (from ccw@kokab.cc.deakin.oz for uunet!TOPS20@score.stanford.edu) Received: by kokab.cc.deakin.oz (4.0) id AA06886; Mon, 22 Aug 88 15:42:37 EST To: Tops20 People Subject: Ethernet/Tcp utilities Date: Mon, 22 Aug 88 15:40:35 +1000 From: Craig Warren Having just attached our 20 to our backbone Ethernet, we are now in the market for utilities. I currently have Telnet, FTP and NFS. What other utilities can people offer? 26-Aug-88 01:42:37-PDT,566;000000000000 Return-Path: Received: from STL-HOST1.ARPA by SCORE.STANFORD.EDU with TCP; Fri 26 Aug 88 01:40:49-PDT Date: Fri, 26 Aug 88 03:39:47 CDT From: Frank J. Wancho Subject: ACTGEN in reverse? To: TOPS-20@SCORE.STANFORD.EDU Message-ID: <12425458081.17.WANCHO@STL-HOST1.ARPA> I seem to recall seeing a description of a program designed to create an ACCOUNTS.CMD file from SYSTEM:ACCOUNTS-TABLE.BIN, probably on a recent DECUS tape. Does anyone have a copy of it online and available via FTP? --Frank ------- 2-Sep-88 05:59:23-PDT,1403;000000000000 Return-Path: Received: from MCC.COM by SCORE.STANFORD.EDU with TCP; Fri 2 Sep 88 05:56:48-PDT Date: Fri 2 Sep 88 07:56:02-CDT From: Clive Dawson Subject: Monitor Symbol Table Problems To: tops20@score.stanford.edu Message-ID: <12427339736.31.AI.CLIVE@MCC.COM> A recent monitor I built (5.4) insists on trashing at least one entry in its symbol table after it is booted. I discovered this when SYSDPY started producing very strange output, since the symbol involved was NUFKS (number of forks allowed per job). Other than this, the system behaves normally. A spot-check of various other symbols showed they were ok. Has anybody seen anything like this before? Thanks, Clive ------------------------------------ [PHOTO: Recording initiated Thu 18-Aug-88 11:11PM] Link from AI.CLIVE, TTY 71 Tops-20 Command processor 5.1(121700) 2$;System has just been booted... 2$sy Thu 18-Aug-88 23:11:23 Up 0:05:11 1+9 Jobs Load av 1.49 0.84 0.37 No operator in attendance Job Line Program User Foreign host 6* 71 Systat Ai.Clive 1 106 Sysjb1 Operator 2 105 Ptycon Operator 3 110 Dsv Operato^C 2$get system:monitr 2$st 140 DDT nufks=30 ^C 2$^C 2$mddt MDDT nufks=777777,,777777 ^C 2$pop [PHOTO: Recording terminated Thu 18-Aug-88 11:12PM] ------- 6-Sep-88 07:20:09-PDT,3432;000000000000 Return-Path: Received: from VAX02.AMS.COM ([130.44.1.5].#Internet) by SCORE.STANFORD.EDU with TCP; Tue 6 Sep 88 07:13:26-PDT Return-Path: <@SEED.AMS.COM,@GIZMO.SRI.COM:RELAY-INFO-VAX@CRVAX.SRI.COM> Received: from SEED.AMS.COM by VAX01.AMS.COM via SMTP with TCP; Sat, 3 Sep 88 09:56:29-EDT Received: from GIZMO.SRI.COM by SEED.AMS.COM with TCP; Sat 3 Sep 88 09:56:02-EDT Received: From KL.SRI.COM by CRVAX.SRI.COM with TCP; Sat, 3 SEP 88 06:10:08 PDT Received: from ucbvax.Berkeley.EDU by KL.SRI.COM with TCP; Sat, 3 Sep 88 05:51:23 PDT Received: by ucbvax.Berkeley.EDU (5.59/1.31) id AA04074; Sat, 3 Sep 88 04:01:52 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-vax@kl.sri.com (info-vax@kl.sri.com) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 2 Sep 88 12:05:57 GMT From: att!chinet!mcdchg!clyde!watmath!julian!uwovax!brent@ucbvax.Berkeley.EDU Subject: DECsystem-10 Wake - A Summary Message-Id: <648@uwovax.uwo.ca> Sender: info-vax-request@kl.sri.com To: info-vax@kl.sri.com ReSent-date: Tue 6 Sep 88 10:12:28-EDT ReSent-from: Betsy Ramsey ReSent-to: TOPS20@SCORE.STANFORD.EDU DECsystem-10 Wake - A Summary ============================= In memory of our life and strife with 36 bits, our site held a wake/celebration on August 31. Invitations were sent far and wide, although no one came from further than Toronto (200 km). Local staff managed to locate various memorabelia for the event, including an RP02 disk, paper tape, DECtapes, and PDP-10 manuals in various flavours. One attendee provided a real DECsystem-10 name bar from the top of a 1090. Black armbands were worn and a registry was available to be signed. Wake cake and coffee was served. To help with atmosphere, recorded music was provided: "Requiem in d-moll, KV 626" by Wolfgang Amadeus Mozart followed by "Symphonie 2 'Resurrection'" by Gustav Mahler Those who wished had their picture taken with the processor coffin, on which the 1964-1985 "Nobody did it Better" poster was prominently displayed. The sailboat poster "Chart your course with Digital's Large Systems" was prominently posted (upright to begin, upside-down later). Perhaps 50 people attended. A suitable tribute to a very fine system. b. "Dies irae, Dies illa Solvet DEC-10 in favilla Teste Bobby cum Monilla." "Quantus VAXen est futurus, Quando DCL est venturus, Cuncta stricte discussurus!" PS: Throughout our "migration, we used a logo which may be "borrowed", consisting of a clock (circle), 10 o'clock marked as "10", and 12 o'clock marked as "VAX". (Reverse block letters below the hands indicate that this is a d i g i t a l clock.) The hands of the clock face indicate the time is "10 to VAX". I'll mail a master of the logo to any interested parties if you drop me a line indicting your snail-mail address. (Coming from Canada with a pseudo strike may take a while, however.) BTW, the time at our site is now "10 past VAX - do you know where your files are?" -- Brent Sterner Technical Support Manager, Academic Systems Network Telephone (519)661-2151 x6036 Last Gasp Computing & Communications Services, Natural Sciences Building The University of Western Ontario, London, Ontario, Canada N6A 5B7 ------- 7-Sep-88 15:42:48-PDT,1943;000000000000 Return-Path: Received: from SIMTEL20.ARMY.MIL by SCORE.STANFORD.EDU with TCP; Wed 7 Sep 88 15:38:11-PDT Date: Wed, 7 Sep 1988 16:37 MDT Message-ID: From: "Frank J. Wancho" To: TOPS-20@SCORE.STANFORD.EDU cc: WANCHO@SIMTEL20.ARMY.MIL Subject: NOT.NOT fix! Back around the middle of December, we were getting plagued with stuck NOT.NOT connections with "partial packet received" conditions, and NETSRV causing the load to go through the roof. The quick fix was to remove NETSRV from putting itself in Queue 0 so that garbage collection could run and flush those stuck NOT.NOTs. Unfortunately, garbage collections didn't occur often enough. So, I fished through the code and found that by setting INTSVR to some non-zero value via MDDT, I could release those NOT.NOTs. Doing that once or twice a day seemed to keep the lines open. (I also noticed that when I did this while coming in through a TAC, the response noticably improved.) Now, what's strange is that all these NOT.NOTs were residual FTPSRT jobs. Last week, I started playing with FTPSRT, ignoring the caveat that you can't use the BIGBUF option with DEC monitors, only BBN versions. Nothing changed - you still can't use the BIGBUF option. However, I decided to recompile and relink a new version of FTPSRT (which I hadn't done since well before we moved to 6.1), and put up that version. Stranger things have happened in the life of this machine, and I've waited almost a week to make sure before sending this message, but we've had not one stuck NOT.NOT since putting up that recompiled and relinked FTPSRT! Bottom line: if you haven't rebuilt your network utilities, such as FTPSRT/FTPSER, FTP, WHOIS, FINGER, SMTJFN, NETSRV, MMAILR, etc., since moving to 6.1, do so. You can't loose, and may even gain, as I just did. --Frank 8-Sep-88 19:53:54-PDT,2478;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SCORE.STANFORD.EDU with TCP; Thu 8 Sep 88 19:50:58-PDT Date: Thu 8 Sep 88 22:51:39-EDT From: Rob Austein Subject: [Pandora B. Berman: The end of the world as we used to know it] To: TOPS-20@SCORE.STANFORD.EDU Message-ID: <12429064720.14.SRA@XX.LCS.MIT.EDU> Date: Thu, 8 Sep 88 21:39:25 EDT From: "Pandora B. Berman" Subject: The end of the world as we used to know it "The time has come," said LCS, "MX at last must go. Its day has gone. We need that space Most urgently." And so Before we crate it, let us give A final cheerio. Once there was a KL-10 called MIT-MC which belonged to the Macsyma Consortium. It provided Macsyma, the symbolic algebra system, to researchers all over the world, and mail gatewaying and mailing list support to a large fraction of the Arpanet. Things continued in this fashion from 1975 to 1983. When the Macsyma Consortium dissolved in 1983, MC turned to providing cycles for MIT's Laboratory for Computer Science, and continued supporting much of the Arpanet's mail service. But the machine itself was growing old and cranky. In 1986, the mail services were moved to a smaller, more maintainable machine (a KS-10), and the name "MC" was moved with them. But the KL-10 continued to run under the new name "MX". Now the end has come. MX was down cold for several months, and has only been revived recently to copy some old 7-track tapes. LCS can't keep MX any longer -- it needs the space for other purposes. So the KL is being sent to the Home for Aged But Beloved PDP-10s; a crack team of hardware hackers will arrive next week to dismantle it and take it back with them to Sweden. In celebration of this momentous event, we are holding a small farewell gathering: Friday, 16 September 1988 16:00 NE43-8th floor playroom (545 Technology Square, Cambridge, MA) Reservations are strenuously requested (though not strictly necessary) -- we need a head count so we can figure out how many trays of institutional brownies to order. Send yours to: CENT@AI.AI.MIT.EDU Offers of refreshement are also very welcome -- do you think we have any budget for this kind of thing? Send all such offers also to CENT as above. ------- 9-Sep-88 07:56:34-PDT,630;000000000000 Return-Path: Received: from TOPS20.DEC.COM by SCORE.STANFORD.EDU with TCP; Fri 9 Sep 88 07:52:16-PDT Date: 9 Sep 1988 1052-EDT From: BRAITHWAITE@TOPS20.DEC.COM To: tops20@score.stanford.edu Subject: Anybody know of a working copy of BSYS on TOPS-20? Message-ID: <"MS11(6041)+GLXLIB6(0)" 12429195874.83.428.56920 at TOPS20.DEC.COM> I got a request from a customer want to read very o-o-o-l-d tapes that were backed up on a TENEX system using BSYS (something pre-DUMPER). I would appreciate a pointer to a working copy or to documentation on the tape format. thanks dave -------- 12-Sep-88 17:30:24-PDT,1080;000000000000 Return-Path: <@SUMEX-AIM.Stanford.EDU:MRC@PANDA.PANDA.COM> Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 12 Sep 88 17:12:28-PDT Received: from PANDA.PANDA.COM by SUMEX-AIM.Stanford.EDU with Cafard; Mon, 12 Sep 88 12:12:44 PDT Date: Mon, 12 Sep 88 11:31:16 PDT From: Mark Crispin Subject: SPR 20-21691 in the 1 July Software Dispatch To: TOPS-20@Score.Stanford.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12430022204.7.MRC@PANDA.PANDA.COM> I am very suspicious of this patch. The whole point of the code as written with the XOR's is to update SPTH with the new status of FILWB+THAWB+OFNDUD+OFN2XB. After the ANDX, T2 acquires those four bits which are different between T2 and SPTH. The XORM updates SPTH with the new state. With the IORM, SPTH ends up with those bits set if they were set either in T2 or SPTH. This code is also in 5.1 and its function looks very straightforward there. Anyone else have any insights about this? ------- 12-Sep-88 17:32:57-PDT,654;000000000000 Return-Path: <@SUMEX-AIM.Stanford.EDU:MRC@PANDA.PANDA.COM> Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 12 Sep 88 17:13:03-PDT Received: from PANDA.PANDA.COM by SUMEX-AIM.Stanford.EDU with Cafard; Mon, 12 Sep 88 13:27:36 PDT Date: Mon, 12 Sep 88 12:17:49 PDT From: Mark Crispin Subject: SPR 20-21881 To: TOPS-20@Score.Stanford.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12430030678.7.MRC@PANDA.PANDA.COM> I think there should be a NOINT in the patch for 20-21881 in the success case, to balance the OKINT in ULKOFN. ------- 13-Sep-88 11:38:24-PDT,2547;000000000000 Return-Path: Received: from TOPS20.DEC.COM by SCORE.STANFORD.EDU with TCP; Tue 13 Sep 88 11:36:01-PDT Date: 13 Sep 1988 1435-EDT From: "David Lomartire" To: MRC%PANDA.PANDA.COM@SUMEX-AIM.STANFORD.EDU, TOPS-20@Score.Stanford.EDU DTN: 297-5508 Mailstop: MRO1-2/L14 Pole: MRO1-2/KL21 Subject: Re: SPR 20-21691 in the 1 July Software Dispatch Message-ID: <"MS11(6041)+GLXLIB6(0)" 12430285148.81.209.65477 at TOPS20.DEC.COM> References: Message from Mark Crispin of 12-Sep-88 2041-EDT In-reply-to: <12430022204.7.MRC@PANDA.PANDA.COM> The intent of the code in this area is to insure that, upon the first real open of an unrestricted file, the access bits in SPTH are accurate based on the new opening. Further, this code is called upon the opening of a long file and it will insure that the page-table-zero (PT0) access will match the page-table-table (PTT) access. When this code is executed, it is insured that FILUB is set and that FILWB and THAWB are not. This is because the OFN represents an unrestricted file and so only FILUB should be present. OFN2XB may be present in the flags of the OFN and OFNDUD should not (although, I have just discovered a case in which OFNDUD is incorrectly set; more on this later) since the file was open for read. So, only OFN2XB should be set when this code is entered. The code will take the access bits from the real open and set them in SPTH. An IORM is used so that OFN2XB is not inadvertanly cleared. The XORM will clear OFN2XB if it happens to be set and this caused OFJFBD BUGHLTs. None of the other bits (FILWB, THAWB, OFNDUD) should be in SPTH before the IORM is done since the file was an unrestricted one. However, the IORM will insure that they appear in SPTH if they appear as part of the "real" opening. But, there is a bug which I happened to find while looking this over. It is possible to have OFNDUD set in SPTH when entering CHKLAC. Thus, it will remain set in SPTH even if the real opener is not OF%DUD. The solution is to clear OFNDUD in RELOF6 after an OFN is released and only unrestricted openers remain. Note that, if a file is opened with OF%RD+OF%RDU+OF%DUD, OFNDUD will not be set. So, it is correct to clear OFNDUD in RELOF6. Hopefully, this clears up any confusion. David Lomartire LSBU Software Engineering TOPS-20 Group -------- 14-Sep-88 16:32:26-PDT,2892;000000000000 Return-Path: Received: from sierra.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Wed 14 Sep 88 16:30:52-PDT Received: from columbia.edu by sierra.STANFORD.EDU (3.2/4.7); Wed, 14 Sep 88 16:29:05 PDT Received: from cunixc.cc.columbia.edu by columbia.edu (5.54/1.14) id AA18183; Wed, 14 Sep 88 19:30:31 EDT Received: by cunixc.cc.columbia.edu (5.54/5.10) id AA00792; Wed, 14 Sep 88 19:26:44 EDT Date: Wed, 14 Sep 1988 19:26:43 EDT From: Melissa Metz To: tops-20%score@sierra.stanford.edu Subject: Manuals Message-Id: Our last DEC20 is going away this month, and I have a whole pile of manuals. Some are even still in their original shrink-wrap! Some of them are pretty old, but I thought that in case ANYONE might want them I might as well offer. Of course, I'm not charging for them, though I might have to ask for shipping if I send out a lot and someone notices... See the list below. --Melissa -------------------------------------- RSX-11: Manager's Implementation Guide TOPS-10/TOPS-20 or DECSYSTEM-10/DECSYSTEM-20: User Environment Test Package Procedures/Reference Manual #2 RSX-20F System Reference Manual #2 Batch Reference Manual #3 Hardware Reference Manual -- Volume I: Central Processor #7 SAIL manuals #2 DDT Reference Card KL System Reference Card USAGE File Specification Syserr Manual OPR Commands Reference Card SPEAR Reference Card DECSYSTEM-10: Algol Programmer's Reference Manual System Reference Card TOPS-20 or DECSYSTEM-20: Error Detection, Recovery and Reporting Reference Manual COBOL Utilities Manual COBOL Programmer's Reference Manual Getting Started with Runoff Text Formatting Program DBMS-20 User's Guide TOPS-20AN User's Guide #6 MACRO Assembler Reference Manual #3 Link Reference Manual #2 Operator's Guide #3 Operator's Command Language Reference Manual User Utilities Guide DECnet-20 Programmer's Guide and Operations Manual IBM Emulation/Termination #3 Monitor Calls Reference Manual -- Version 4 Monitor Calls User's Guide -- Version 4 (?) Monitor Calls User's Guide -- Version 6 (?) Fortran Reference Manual User's Guide -- Version 1 Batch Operator's Guide Sort User's Guide Getting Started with Batch (TOPS-20) Introduction to DECSYSTEM-20 Assembly Language Programming, by Ralph Gorin Monitor Internals Course Guide Guide to Measuring Uptime System Manager's Guide KL Model B Installation Guide Update Notice (9/85) for User Utilities Guide #2 Monitor Calls Quick Reference Guide (6.1) Commands Reference Manual (Exec v.4) #2 DDT Reference Card Commands Reference Card Monitor Calls Reference Manual (v.3A) DDT Manual PDP11: Introduction to DECnet Macro-11 Language Reference Manual 14-Sep-88 18:28:40-PDT,1157;000000000000 Return-Path: Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 14 Sep 88 18:27:19-PDT Date: Wed, 14 Sep 88 18:23:16 PDT From: Mark Crispin Subject: 2020 and TU78 To: TOPS-20@Score.Stanford.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12430621495.14.CRISPIN@SUMEX-AIM.Stanford.EDU> Hi - The question came up here (SUMEX) about whether or not a 2020 could drive a TU78. As I understand it, you couldn't put an RP07 on a 2020 because the RP07 was too fast for the RH11. However, I never heard any definite word about the TU78. Even though the TU78 transport itself is capable of fast transfers (faster than the RP07, isn't it?) the question is can the RH11 talk to a TM78. Of course, I know that 2020's can talk to TU77/TM03's. If it is merely a small matter of programming (e.g. building a monitor with PHYM78) this may keep electrons flowing to a 2020 system here as the machine to read our large library of Tenex/TOPS-20 archive tapes. -- Mark -- ------- 15-Sep-88 14:04:21-PDT,2396;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SCORE.STANFORD.EDU with TCP; Thu 15 Sep 88 14:02:37-PDT Date: Thu, 15 Sep 1988 16:58 EDT Message-ID: Sender: SRA@XX.LCS.MIT.EDU From: Rob Austein To: TOPS-20@SCORE.STANFORD.EDU cc: Info-CHIVES@XX.LCS.MIT.EDU Subject: Chives version 1.0 now available Reply-To: Bug-CHIVES@LCS.MIT.EDU After most of a year of beta-testing and further development, version 1.0 of the Chives system is now available. Chives is an implementation of the Domain Name System protcols for TOPS-20 (and other systems), and supports/is supported by the MM/MMAILR mail system distributed by Mark Crispin. Small bugfixes and improvements are generally merged into the existing sources without a lot of fanfare, so the current sources should be viewed as a snapshot rather than as something carved in stone. The reason we are doing a full-blown release at this point is that as of a few weeks ago: (1) All of the known outstanding bugs had been fixed, (2) A lot of low-level code had changed since the last update to the distribution sources, and (3) The general design of RESOLV and GTDOM% had been proven to be stable and reliable over a period of an entire year's use on XX and a few other machines. Some highlights of the new release: - A memory manager to eliminate the fragmentation problems that Chives used to suffer from. - A garbage collector to reclaim space occupied by RRs with expired TTLs. - More/better telemetry, lots of little bugfixes. - Support for negative caching. - Better support for multi-homed hosts. - Convergence of the version of KCC used to compile Chives with the version of KCC maintained by SRI. - Support for TOPS-20 7.0. I believe that DEC intends to distribute the necessary monitor hooks to support GTDOM% on an upcoming autopatch tape, contact BUG-CHIVES@LCS.MIT.EDU if you care about this. There are undoubtably other fixes/improvements that I've forgotten about, it's been a long time since the last source distribution. Chives is available via ANONYMOUS FTP from XX.LCS.MIT.EDU. You want the directory XX: and the directory tree XX:. Please send queries, bug reports, et cetera, to BUG-CHIVES@LCS.MIT.EDU rather than to me directly. --Rob 15-Sep-88 14:59:04-PDT,1940;000000000000 Return-Path: <@SUMEX-AIM.Stanford.EDU:MRC@PANDA.PANDA.COM> Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 15 Sep 88 14:57:56-PDT Received: from PANDA.PANDA.COM by SUMEX-AIM.Stanford.EDU with Cafard; Thu, 15 Sep 88 14:53:04 PDT Date: Thu, 15 Sep 88 11:32:34 PDT From: Mark Crispin Subject: XJRST for 2020's To: TOPS-20@Score.Stanford.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12430808872.7.MRC@PANDA.PANDA.COM> Some user-mode software is starting to appear which uses the XJRST instruction. In particular, user-mode versions of monitor code (e.g. GTDOM%) which lives in the skyseg (section 6) is likely to use the XNENT/XRENT etc. macros which will generate an XJRST to fly from section 1 to section 6 if you use a 6.x or 7.0 PROLOG. Rather than fight, I elected to switch. Implementing XJRST in the KS10 microcode adds one microinstruction. If you have ucode sources for your KS (you lucky devil), you can add XJRST to as follows: ;COMPARISON OF MRC:SIMPLE.MIC.2 AND MRC:SIMPLE.MIC.3 ;OPTIONS ARE /3 **** FILE MRC:SIMPLE.MIC.2, 38-31 (30268) 1535: UUO ;(15) **** FILE MRC:SIMPLE.MIC.3, 38-31 (30268) 1535: VMA_[AR], START READ, ;(15) XJRST J/XJRST *************** **** FILE MRC:SIMPLE.MIC.2, 41-11 (31862) **** FILE MRC:SIMPLE.MIC.3, 41-11 (31894) XJRST: MEM READ, [PC]_MEM, ;PUT DATA IN PC HOLD LEFT, ;IGNORE SECTION NUMBER J/PIEXIT ;JOIN XJRSTF CASE *************** I added the XJRST routine just in front of the XJRSTF routine. To remind you what XJRST FOO is, it's like JRST @FOO except that the former case merely sets the PC to the contents of FOO while the latter case sets the PC to the results of an effective address calculation done on the contents of FOO (hence indexing and indirection are possible). ------- 15-Sep-88 20:50:33-PDT,750;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SCORE.STANFORD.EDU with TCP; Thu 15 Sep 88 20:49:10-PDT Date: Thu, 15 Sep 1988 21:29 EDT Message-ID: From: JTW@XX.LCS.MIT.EDU To: tops-20@SCORE.STANFORD.EDU, ks-owners@PANDA.PANDA.COM Subject: Got an extra KS10? Hi there. We're looking for a cheap, working KS10. You know, 0 <= x <= $500ish. Good home, friends to play with, etc. Northeast US preferred, but don't let that stop you. Oh, if you're one of those strange people who once field-stripped a KS and stuffed the parts into a corner of the basement, but you can't quite remember why anymore, we'd like to talk to you, too. Thank you for your support... -john 18-Sep-88 13:28:07-PDT,951;000000000000 Return-Path: <@SUMEX-AIM.Stanford.EDU:MRC@PANDA.PANDA.COM> Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Sun 18 Sep 88 13:23:39-PDT Received: from PANDA.PANDA.COM by SUMEX-AIM.Stanford.EDU with Cafard; Sat, 17 Sep 88 22:25:25 PDT Date: Sat, 17 Sep 88 21:19:28 PDT From: Mark Crispin Subject: UMOVE/UMOVEM instructions To: TOPS-20@Score.Stanford.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12431440001.7.MRC@PANDA.PANDA.COM> On the KS, building a monitor with the UMOVEx macros replaced with the machine instructions (which are in all KS's) saves 2 pages of non-resident code space. It should also be faster, since the macro simply generates XCTU [MOVEx ac,user] which has to do an additional memory fetch plus the cost of executing the XCT -- perhaps 3 usecs or so. Is the KL ucode still too full to add these? ------- 20-Sep-88 11:54:05-PDT,829;000000000000 Return-Path: Received: from emx.utexas.edu by SCORE.STANFORD.EDU with TCP; Tue 20 Sep 88 11:47:22-PDT Date: Tue, 20 Sep 88 13:48:31 CDT From: blais@emx.utexas.edu (Donald E. Blais) Posted-Date: Tue, 20 Sep 88 13:48:31 CDT Message-Id: <8809201848.AA04980@emx.utexas.edu> Received: by emx.utexas.edu (5.54/5.51) id AA04980; Tue, 20 Sep 88 13:48:31 CDT To: info-CHIVES-request@lcs.mit.edu Cc: TOPS-20@score.stanford.edu In-Reply-To: Rob Austein's message of Thu, 15 Sep 1988 16:58 EDT Subject: Chives version 1.0 now available Host R20.UTEXAS.EDU is no longer in service. Please take my name off the Info-Chives distribution if I am on it. You may also want to check for other people at R20. -- Donald Blais cc.Blais@R20.UTEXAS.EDU 21-Sep-88 07:00:50-PDT,2395;000000000000 Return-Path: Received: from VAX01.AMS.COM by SCORE.STANFORD.EDU with TCP; Wed 21 Sep 88 06:57:59-PDT Return-Path: <@SEED.AMS.COM,@MATH.AMS.COM,@GIZMO.SRI.COM:RELAY-INFO-VAX@CRVAX.SRI.COM> Received: from SEED.AMS.COM by VAX01.AMS.COM via SMTP with TCP; Wed, 21 Sep 88 08:51:20-EDT Received: from MATH.AMS.COM by SEED.AMS.COM with TCP; Wed 21 Sep 88 08:52:25-EDT Received: from GIZMO.SRI.COM by MATH.AMS.COM with TCP; Wed 21 Sep 88 08:50:09-EDT Received: From KL.SRI.COM by CRVAX.SRI.COM with TCP; Tue, 20 SEP 88 22:00:07 PDT Received: from ucbvax.Berkeley.EDU by KL.SRI.COM with TCP; Tue, 20 Sep 88 21:44:01 PDT Received: by ucbvax.Berkeley.EDU (5.59/1.31) id AA17142; Tue, 20 Sep 88 09:55:58 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-vax@kl.sri.com (info-vax@kl.sri.com) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 20 Sep 88 14:11:32 GMT From: ted@mitre-bedford.arpa (Edward J. Ede) Organization: The MITRE Corporation, Bedford, Mass. Subject: Re: Wanted: MTREK/GALAXY/VAXTREK (a similar request) Message-Id: <40146@linus.UUCP> References: <18284@uflorida.cis.ufl.EDU> Sender: info-vax-request@kl.sri.com To: info-vax@kl.sri.com ReSent-date: Wed 21 Sep 88 09:34:25-EDT ReSent-from: Betsy Ramsey ReSent-to: TOPS-20@SCORE.STANFORD.EDU In article <18284@uflorida.cis.ufl.EDU> jdc@beach.cis.ufl.edu () writes: >A few years ago I enjoyed playing a game called MTREK or GALAXY >on VMS. It was a really great, multi-player star-wars type game. >Up to 8 players could control their own ship and fire phasers, >torpedoes, and seekers at the other players. Speaking of multi-player trek games, does anyone remember VTTREK for Tops-20. Its neatest features were the use of VT100 Advanced Video Option graphics for the "viewport", and the ability to use the keypad to play. Does anyone know what happened to this game? Was it ever ported to VMS? If not, does anyone have the Tops-20 source? Just curious, ted Ted Ede -- ted@mitre-bedford.arpa -- The MITRE Corporation -- Burlington Road | linus!mbunix!ted -- Bedford MA, 01730 -- Mail Stop B015 -- (617) 271-2524 | | - this line intentionally left blank - | +---------------------------------------------------------------------------+ ------- 21-Sep-88 13:13:37-PDT,715;000000000000 Return-Path: Received: from bu-it.BU.EDU by SCORE.STANFORD.EDU with TCP; Wed 21 Sep 88 13:11:42-PDT Received: from BUIT2.BU.EDU by bu-it.BU.EDU (5.58/4.7) id AA23402; Wed, 21 Sep 88 16:11:04 EDT Return-Path: Received: by buit2 (5.58/4.7) id AA20036; Wed, 21 Sep 88 16:10:57 EDT Date: Wed, 21 Sep 88 16:10:57 EDT From: budd@bu-it.bu.edu Message-Id: <8809212010.AA20036@buit2> To: info-vax@kl.sri.com, ted@mitre-bedford.ARPA Subject: Re: Wanted: MTREK/GALAXY/VAXTREK (a similar request) Cc: tops-20@score.stanford.edu Re: VTTREK.MAC I have them; check bu-it (anonymous ftp), dir "bucs20", its in games.tar.Z (a compressed tar archive) -Phil Budne 21-Sep-88 18:45:15-PDT,1244;000000000000 Return-Path: Received: from jessica.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 21 Sep 88 18:43:09-PDT Received: by jessica.Stanford.EDU; Wed, 21 Sep 88 18:41:40 PDT Date: 21 Sep 1988 1841-PDT (Wednesday) From: Philip Almquist To: Clive Dawson Cc: almquist@jessica.Stanford.EDU, tops20@score.Stanford.EDU Subject: Re: Monitor Symbol Table Problems In-Reply-To: Clive Dawson / Fri 2 Sep 88 07:56:02-CDT. <12427339736.31.AI.CLIVE@MCC.COM> Clive, It took me a while to find my old TOPS-20 notes, but I may have a hint as to your trashed symbols problem. I had a similar problem in the field test 5.1 monitor. In 5.1 (and presumably in 5.4 as well), the symbol table starts its life on top of tne RSVAR PSECT. During system startup the symbol table gets copied elsewhere, but if RSVAR variables are used early in in the initialization code you get exactly the symptoms you saw: a trashed symbol which, if you are unlucky, is one of the ones Sysdpy expects to find. The fix is to figure out which RSVAR variable(s) need to get moved to RSDAT (in 5.1 they were CASHF and CONOPG). Philip 21-Sep-88 19:21:26-PDT,702;000000000000 Return-Path: Received: from MCC.COM by SCORE.STANFORD.EDU with TCP; Wed 21 Sep 88 19:19:58-PDT Date: Wed 21 Sep 88 21:18:43-CDT From: Clive Dawson Subject: Monitor Symbol Table problems To: clynn@g.bbn.com, almquist@jessica.Stanford.EDU cc: tops20@score.stanford.edu Message-ID: <12432466596.47.AI.CLIVE@MCC.COM> Charlie and Philip-- Regarding the tip you both gave me on my monitor symbol table problem, where the value of NUFKS was getting trashed, I checked the address of the CASHF word in my monitor, and it corresponded exactly with the spot where the value of NUFKS was stored in the virgin symbol table! Many thanks!! Clive ------- 22-Sep-88 07:50:27-PDT,676;000000000000 Return-Path: Received: from RADC-TOPS20.ARPA by SCORE.STANFORD.EDU with TCP; Thu 22 Sep 88 07:47:20-PDT Date: Thu 22 Sep 88 10:47:01-EDT From: Donna Lynch Subject: IMPINC To: tops-20@SCORE.STANFORD.EDU cc: admin@RADC-TOPS20.ARPA Message-ID: <12432602820.10.ADMIN@RADC-TOPS20.ARPA> Yes, we are still running 5.4. I thought we were going to get rid of this machine, so I have not upgraded. Anyway, I am getting tons of "BUGINF IMPINC" from 10.4.0.15 (arpa-gw.cc.rochester.edu). Are they doing something they shouldn't be doing? Am I doing something I shouldn't be doing? Can you help? --Donna ------- 22-Sep-88 09:56:50-PDT,491;000000000000 Return-Path: Received: from MCC.COM by SCORE.STANFORD.EDU with TCP; Thu 22 Sep 88 09:54:11-PDT Date: Thu 22 Sep 88 11:41:01-CDT From: Clive Dawson Subject: Re: IMPINC To: ADMIN@RADC-TOPS20.ARPA cc: tops-20@SCORE.STANFORD.EDU In-Reply-To: <12432602820.10.ADMIN@RADC-TOPS20.ARPA> Message-ID: <12432623573.12.AI.CLIVE@MCC.COM> I got tired of IMPINC's long ago and disabled them by inserting a RET at IMPEC9 (module IMPDV). Clive ------- 22-Sep-88 11:01:26-PDT,1336;000000000000 Return-Path: Received: from clash.cisco.com by SCORE.STANFORD.EDU with TCP; Thu 22 Sep 88 10:58:00-PDT Received: from clash.cisco.com by clash.cisco.com with TCP; Thu, 22 Sep 88 10:53:47 PDT To: Donna Lynch Cc: tops-20@score.stanford.edu, richards@nisc.nyser.net Subject: Re: IMPINC In-Reply-To: Your message of Thu, 22 Sep 88 10:47:01 -0400. <12432602820.10.ADMIN@RADC-TOPS20.ARPA> Date: Thu, 22 Sep 88 10:53:44 PDT From: satz@clash.cisco.com 10.4.0.15 is a cisco gateway running DDN X.25. What is interesting is that a Sun behind that gateway is sending IP packets with something other then the default type of service (TOS) field. The cisco X.25 implementation will open new virtual circuits depending on the type of service field indicated. If I remember the explaination I got from BBN correctly, only the top two bits of precedence is carried across from DDN X.25 to 1822. I am not sure what ramifications this has on the incoming 1822 leader but I suspect something is different then normal and the -20 is not prepared for it. The NYSERNET people will hopefully be running new software this evening which will prevent the opening of new virtual circuits based on the IP precedence field. Your problem may go away then. Greg Satz cisco 26-Sep-88 11:37:10-PDT,872;000000000000 Return-Path: Received: from VAX02.AMS.COM by SCORE.STANFORD.EDU with TCP; Mon 26 Sep 88 11:33:47-PDT Date: Mon 26 Sep 88 14:34:29-EDT From: Betsy Ramsey Subject: PSI-20 To: TOPS-20@SCORE.STANFORD.EDU Message-ID: <591302069.0.EWR@VAX02.AMS.COM> Mail-System-Version: Is anyone out there running PSI-20? Ziff-Davis Technical Information has inherited a DEC-20, and they'd like to hear from some sites that are using PSI. If you can help them, please contact Cliff Hafen Ziff-Davis Technical Information Boston, MA 617-273-5500 If you'd rather, you can reply to me, and I'll have Cliff give you a call. (He's not on a network.) Thanks. Betsy Ramsey EWR@VAX01.AMS.COM American Mathematical Society Phone: 401-272-9500 Providence, RI ------- 27-Sep-88 01:26:45-PDT,1167;000000000000 Return-Path: Received: from SRI-NIC.ARPA by SCORE.STANFORD.EDU with TCP; Tue 27 Sep 88 01:24:55-PDT Date: Tue, 27 Sep 88 01:25:25 PDT From: Mark Lottor Subject: NFS-20 Version 1 To: tops-20@score.stanford.edu Message-ID: <12433844071.25.MKL@SRI-NIC.ARPA> I'm now releasing NFS-20 version 1. The code isn't as clean as I'd like it to be, and it hasn't been tested as much as I hoped too, and there are still some things I'd like to add someday, but since I don't know when I'm ever going to get around to it I though I'd better get a version out now. This version adds lots of changes made by Lon Willet, whom I haven't been able to contact in a long time. He took the original release and made it more useable as a real NFS server. It handles filename munging better, handles version numbering better, handles undeleting and expunging, and lots of other gross unix workarounds. It still doesn't handle unix userid to tops-20 userid mapping. The documentation notes briefly describe how to use it. To get your copy, just anonymous FTP the whole directory. SRI-NIC.ARPA:: PS: ------- 3-Oct-88 10:32:09-PDT,1124;000000000000 Return-Path: <@SUMEX-AIM.Stanford.EDU:MRC@PANDA.PANDA.COM> Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 3 Oct 88 10:29:33-PDT Received: from PANDA.PANDA.COM by SUMEX-AIM.Stanford.EDU with Cafard; Mon, 3 Oct 88 10:10:39 PDT Date: Mon, 3 Oct 88 10:09:44 PDT From: Mark Crispin Subject: another member of an endangered species dies... To: TOPS-20@Score.Stanford.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12435512384.7.MRC@PANDA.PANDA.COM> This is likely to be the last message sent from PANDA.PANDA.COM, my "in-house" 2020, for a long time. Shortly after the next Cafard run, PANDA will be shut down and its plug will be pulled, in preparation for it to be moved into storage. There is a chance that like the proverbial phoenix PANDA will rise again from the dead, assuming that I manage to get another house. But for now, a moment of silence for a very special DEC-20... -- Mark -- PS: My primary net address will be MRC@SIMTEL20.ARMY.MIL until further notice. ------- 10-Oct-88 20:22:51-PDT,766;000000000000 Mail-From: G.CLIVE created at 10-Oct-88 17:14:24 Date: Mon 10 Oct 88 17:14:24-PDT From: Clive Dawson Subject: INTFR1 BUGHLT To: tops20@Score.Stanford.EDU Reply-To: clive@mcc.com Message-ID: <12437424702.19.G.CLIVE@Score.Stanford.EDU> We had an INTFR1 BUGHLT today, months after I hoped I'd never seen one of those again...An examination of the crash dump reveals that the same IP buffer was returned to free space twice in quick succession. First, by the Internet fork (INTRBF routine in IPIPIP), and then by the user job doing an ABORT which eventually ends up in ABTCOA (TCPTCP). Has anybody seen anything like this? I wonder if there might be a race condition involving the PINTL flag? Tnx, Clive ------- 10-Oct-88 20:39:20-PDT,635;000000000000 Return-Path: Received: from TOPS20.DEC.COM by SCORE.STANFORD.EDU with TCP; Mon 10 Oct 88 11:36:40-PDT Date: 10 Oct 1988 1438-EDT From: "Rocket J. Squirrel" To: tops20@score.stanford.edu Loc/MS: "MRO1-2/L14 (Pole KL21)" Phone: "DTN 297-2346 (508-467-2346)" Subject: SEAL Message-ID: <"MS11(6044)+GLXLIB6(0)" 12437363498.92.61.184934 at TOPS20.DEC.COM> From what I understand, SEAL has been released into the public domain. Does anyone know where the homebase of the source and documentation files exist? Thanks, Mike Raspuzzi DEC TOPS-20 Monitor Group -------- 11-Oct-88 14:29:16-PDT,880;000000000000 Return-Path: Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 11 Oct 88 14:26:41-PDT Date: Tue, 11 Oct 88 14:22:38 PDT From: Andrew Sweer Subject: Re: INTFR1 BUGHLT To: clive@mcc.com cc: tops20@Score.Stanford.EDU In-Reply-To: <12437424702.19.G.CLIVE@Score.Stanford.EDU> Message-ID: <12437655576.54.SWEER@SUMEX-AIM.Stanford.EDU> Clive, I still see INTFR1s approximately once/month. Of the last 4, 3 were MMAILR forks in .ABORT, and 1 was when I restarted NETSRV. Alas, we are migrating to that other operating system at the end of this month, so I have no real plans or expectations for exterminating this bug, at least at our site. If there is anything I can do to help your hunt, like sending a crash dump for comparison, I'd be more than happy to oblige. Andy ------- 12-Oct-88 13:16:12-PDT,625;000000000000 Return-Path: Received: from GSB-HOW.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 12 Oct 88 13:16:10-PDT Date: Wed 12 Oct 88 13:16:00-PDT From: Eric M. Berg Subject: Load on LOTS To: su-tops-20@Score.Stanford.EDU Organization: Price Waterhouse Technology Centre, Menlo Park, CA Phone-#s: 415/322-0606 (PWTC), 415/329-9940 (home) Message-ID: <12437905589.153.A.ERIC@GSB-HOW.Stanford.EDU> Portia[1]: uptime 1:06pm up 4 days, 2:36, 62 users, load average: 65.41, 62.07, 58.42 It's enough to make one nostalgic for the bad old days... ------- 13-Oct-88 17:50:13-PDT,829;000000000000 Return-Path: Received: from OSU-20.IRCC.OHIO-STATE.EDU by SCORE.STANFORD.EDU with TCP; Thu 13 Oct 88 17:47:24-PDT Date: Thu 13 Oct 88 19:54:52-EDT From: Lum Johnson Subject: Is anyone out there supporting the Bliss portion of PCL now? To: TOPS-20@OSU-20.IRCC.OHIO-STATE.EDU If anyone is willing to accept it, I have a bug report for the PCL compiler. Complex PARSE statements specifying additional types to try after a FIELD type seem to be incorrectly assembled. I have a short demonstration command and detailed observations for anyone who wishes to request them. If so, thanks. -- Lum Johnson lum@osu-20.ircc.ohio-state.edu lum@tut.cis.ohio-state.edu "You got it kid -- the large print giveth and the small print taketh away." ------- 17-Oct-88 04:31:23-PDT,1388;000000000000 Return-Path: <076RONAN%SPOOL.LIVPOL.AC.UK@forsythe.stanford.edu> Received: from forsythe.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 17 Oct 88 04:26:22-PDT Received: by Forsythe.Stanford.EDU; Mon, 17 Oct 88 04:30:33 PDT Received: from RL.IB by UKACRL.BITNET (Mailer X1.25) with BSMTP id 1161; Mon, 17 Oct 88 12:22:22 BST Received: Via: UK.AC.LIVPOL.SPOOL; 17 OCT 88 12:22:18 BST Date: 17-OCT-1988 12:22:03 From: 076RONAN%SPOOL.LIVERPOOL-POLY.AC.UK@Forsythe.Stanford.EDU To: TOPS-20@SCORE.STANFORD.EDU Subject: Bypassing LEOT on tapes. Sender: JANET "076RONAN@UK.AC.LIVPOL.SPOOL" <076RONAN%SPOOL.LIVPOL.AC.UK@Forsythe.Stanford.EDU > Originally-to: EARN%"tops-20@edu.stanford.score",076RONAN Mailer: Janet_Mailshr V3.1 (19-Aug-1988) Name: Ronan P. Flood, Senior Analyst/Programmer (systems) Address: Liverpool Polytechnic, Computer Services Department, Byrom Street, Liverpool, L3 3AF, U.K Telephone: (051) 207-3581 extension 2101 Given that I "know" there is a DUMPER save-set on a tape beyond the logical EOT, (some of you may remember my previous message concerning DUMPER), how can I get to read it? DUMPER will obey the LEOT mark and not read any further. Is there any way I can get past the LEOT and read what's on the tape there? Ronan. 17-Oct-88 17:07:56-PDT,1079;000000000000 Return-Path: Received: from SCIENCE.UTAH.EDU by SCORE.STANFORD.EDU with TCP; Mon 17 Oct 88 17:06:02-PDT Date: Mon 17 Oct 88 10:16:16-MDT From: "Nelson H.F. Beebe" Subject: Re: Bypassing LEOT on tapes. To: 076RONAN%SPOOL.LIVERPOOL-POLY.AC.UK@FORSYTHE.STANFORD.EDU, TOPS-20@SCORE.STANFORD.EDU cc: Beebe@SCIENCE.UTAH.EDU In-Reply-To: Message from "076RONAN%SPOOL.LIVERPOOL-POLY.AC.UK@Forsythe.Stanford.EDU" of Mon 17 Oct 88 12:22:03-MDT X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 Message-ID: <12439172667.28.BEEBE@SCIENCE.UTAH.EDU> An EOT is just two adjacent tapemarks; that is, it looks just like an empty file. When you have read an EOT, the read head is positioned between the two tapemarks. You can usually just do a SKIP dev: 1 file to move over the second, then CONTINUE DUMPER to carry on reading the tape. The one caveat is that you can run the tape off the reel if you do this at the real EOT. ------- 18-Oct-88 11:49:04-PDT,837;000000000000 Return-Path: Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 18 Oct 88 11:46:31-PDT Date: Tue, 18 Oct 88 11:44:37 PDT From: Mark Crispin Subject: fiche? To: TOPS-20@Score.Stanford.EDU Postal-Address: P.O. Box 2652; Seattle, WA 98111-2652 USA Message-ID: <12439461819.40.CRISPIN@SUMEX-AIM.Stanford.EDU> A long while ago, DEC listed TOPS-20 source fiche as being available for purchase, and my LCG catalog even gives an order number. However, the DEC Electronic Store has no listing for those products. The fiche I have is for vanilla DEC 5.4; with 7.0 out I would like an updated fiche set. It's a non-trivial amount of effort to make fiche; I'd prefer to buy a pre-made set if possible... -- Mark -- ------- 20-Oct-88 10:13:25-PDT,977;000000000000 Return-Path: Received: from rcca.bbn.com by SCORE.STANFORD.EDU with TCP; Thu 20 Oct 88 10:10:38-PDT Date: Thu, 20 Oct 88 13:07 From: Regis McEwen Subject: VMS DUMPER program To: tops-20@score.stanford.edu, admin.mrc@score.stanford.edu I'm looking for information on a VMS DUMPER program that reads TOPS-20 DUMPER tapes and recreates them on VMS. I have DUMPER version 1.1 written by the Stevens Institute of Technology, however I was wondering if there is a more up-to-date version of the program (this version was written in BLISS around the 25th of September in 1986.). This version doesn't handle some record-type files on the tape graciously and bombs out unceremoniously. SELECTing each file is not viable option as to the multitude of files. EXCLUDing of files or file-types is not available. Any other implentations would be helpful. Thanks to all who respond. -Regis 20-Oct-88 11:18:02-PDT,686;000000000000 Return-Path: Received: from SPAR-20.SPAR.SLB.COM by SCORE.STANFORD.EDU with TCP; Thu 20 Oct 88 11:16:54-PDT Date: Thu 20 Oct 88 11:18:36-PDT From: Doug Faunt Subject: re: VMS DUMPER program To: tops-20@SCORE.STANFORD.EDU Message-ID: <12439981369.28.FAUNT@SPAR-20.SPAR.SLB.COM> Speaking of DUMPER tapes on other machines, is there a DUMPER reader for UNIX systems? Schlumberger is moving this lab to Austin Texas, and SPAR-20 is not going, but will be shut down for good. Also, is the '20 history project still going on? A pointer to it, if it's still happening would be appreciated. Thanks, ------- 20-Oct-88 12:23:41-PDT,565;000000000000 Return-Path: Received: from SIMTEL20.ARMY.MIL by SCORE.STANFORD.EDU with TCP; Thu 20 Oct 88 12:22:36-PDT Date: Thu, 20 Oct 1988 13:16 MDT Message-ID: From: "Frank J. Wancho" To: Doug Faunt Cc: tops-20@SCORE.STANFORD.EDU, WANCHO@SIMTEL20.ARMY.MIL Subject: Unix DUMPER reader In-reply-to: Msg of 20 Oct 1988 12:18-MDT from Doug Faunt Doug, See PD2:READ20.SHAR. --Frank 20-Oct-88 13:36:14-PDT,623;000000000000 Return-Path: Received: from TOPS20.DEC.COM by SCORE.STANFORD.EDU with TCP; Thu 20 Oct 88 13:35:04-PDT Date: 20 Oct 1988 1635-EDT From: "Joe Dempster, DTN 336.2023, AT&T 609.273.2023" To: faunt@spar-20.spar.slb.com cc: tops20@score.stanford.edu Subject: TOPS history project. Message-ID: <"MS11(6044)+GLXLIB6(0)" 12440006250.71.30.6242 at TOPS20.DEC.COM> Things are progressing well, but a little slow. Les Earnest and I have identified some 25+ odd chapters and have contributors lined up for most of them. Do you have a contribution? /joe -------- 24-Oct-88 07:44:16-PDT,960;000000000000 Return-Path: Received: from forsythe.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 24 Oct 88 07:41:43-PDT Received: by Forsythe.Stanford.EDU; Mon, 24 Oct 88 07:43:48 PDT Received: from RL.IB by UKACRL.BITNET (Mailer X1.25) with BSMTP id 2056; Mon, 24 Oct 88 14:37:07 GMT Received: from RL.IB by UK.AC.RL.IB (Mailer X1.25) with BSMTP id 2682; Mon, 24 Oct 88 14:37:06 GM Via: UK.AC.OU.ACSVAX Date: 24-OCT-1988 14:34:20 GMT From: I_MCDONALD%VAX.ACS.OPEN.AC.UK@Forsythe.Stanford.EDU To: TOPS20@SCORE.STANFORD.EDU Subject: Farewell It is with regret that I announce the demise 2 weeks prematurely of the surviving Open University Dec-20 triplet on 14-Oct-1988. The cause was certified to be "convulsions due to respiratory circulation failure". Regards and farewell, Ian McD PS: It died through lack of a fan not through lack of FANS.... 27-Oct-88 08:35:27-PDT,603;000000000000 Return-Path: Received: from RADC-TOPS20.ARPA by SCORE.STANFORD.EDU with TCP; Thu 27 Oct 88 08:27:39-PDT Date: Thu 27 Oct 88 08:27:04-EDT From: Donna Lynch Subject: MM To: tops-20@SCORE.STANFORD.EDU Message-ID: <12441752384.6.ADMIN@RADC-TOPS20.ARPA> I have been working on a VAX running VMS. I am unfamiliar with the MAIL system there. I hestitate to say hate, I just haven't found its good points yet. I thought there used to be an MM for the VAX. If this is true, can someone point me to where I might get it? Thanks, Donna ------- 27-Oct-88 11:06:13-PDT,1423;000000000000 Return-Path: Received: from GSB-HOW.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 27 Oct 88 11:01:12-PDT Date: Thu 27 Oct 88 10:58:48-PDT From: Eric M. Berg Subject: Re: MM To: ADMIN@RADC-TOPS20.ARPA cc: tops-20@Score.Stanford.EDU In-Reply-To: <12441752384.6.ADMIN@RADC-TOPS20.ARPA> Organization: Price Waterhouse Technology Centre, Menlo Park, CA Phone-#s: 415/322-0606 (PWTC), 415/329-9940 (home) Message-ID: <12441812775.38.A.ERIC@GSB-HOW.Stanford.EDU> There's a version of MM for VAX/VMS called "MM-32" which was done by David Kashtan at SRI and is distributed alone or as part of the MultiNet+ TCP/IP package for VAX/VMS. It's now available for purchase from either SRI (contact Desiree@KL.SRI.COM), Kashtan (contact Kashtan@TGV.COM), or Excelan. The folks at Columbia have another version of MM which runs on Unix systems and uses their CCMD library (COMND% jsys in C), but it hasn't been ported to VMS and I don't know if anyone has plans to do so. Contact BUG-MM@CUNIXC.CC.COUMBIA.EDU for more information. At Stanford GSB, we're running MM-32 on our VMS system, and it seems to work quite reasonably. Eric Berg former staff member Stanford GSB Computer Facility ------- 29-Oct-88 08:27:00-PDT,6713;000000000000 Return-Path: Received: from SCIENCE.UTAH.EDU by SCORE.STANFORD.EDU with TCP; Sat 29 Oct 88 08:24:29-PDT Date: Sat 29 Oct 88 09:23:42-MDT From: "Nelson H.F. Beebe" Subject: PCL command to loop over file lists To: tops-20@SCORE.STANFORD.EDU cc: Beebe@SCIENCE.UTAH.EDU X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 Message-ID: <12442308825.12.BEEBE@SCIENCE.UTAH.EDU> Here is a PCL command to loop over lists of files, much like the Unix csh 'foreach' command. COMMAND FOREACH ( NOISE "filename reference token (FOO is used as $FOO in commands)"; FIELD; NOISE "filelist"; FILELIST (INPUT, HELP "give list of files, followed by commands to work on them (with $FOO representing file name), followed by ""end"" to terminate the command list", DEFAULT_DEV "DSK", DEFAULT_NAM "*", DEFAULT_EXT "*") ); !------------------------------------------------------------------------ ! Purpose: ! Given a file substitution name, and a list of files, ! execute a sequence of commands. The commands are ! prompted for, and will usually contain the file ! substitution name prefixed by $; such instances will be ! replaced by the full filename. Letter case in the file ! substitution name is not significant. ! ! The command sequence is ended by a line containing only ! the word "end" (letter case is insignificant). This ! command is inspired by the Unix csh foreach command. As ! a bonus, several additional escape sequences are ! recognized in the command text, and substituted for as ! follows: ! ! \1 file device field (e.g. "DSK") ! \2 file directory field (e.g "MA.561.MA-JONES") ! \3 file name field (e.g. "MYPROG") ! \4 file extension field (e.g. "FOR") ! \5 file generation number field (e.g. "23") ! \D current date in the form "dd-mon-yy" ! \F the complete filename (same as $FOO) ! \P page mark (ASCII formfeed) ! \R last read date and time of the current file ! \T current time in the form "hh:mm:ss" ! \W last write date and time of the current file ! \\ single backslash ! ! The complete filename can be reconstructed as ! "\1:<\2>\3.\4.\5" The case of the letter following the ! backslash is not significant; \W and \w are equivalent. ! ! For convenience in communication with Unix, file names ! are converted to lower-case in the output; TOPS-20 does ! not mind. ! ! Examples: ! @foreach F a*.for ! cmd>echo $F ! cmd>copy $F scr: ! cmd>end ! ! @foreach F a*.for ! cmd>echo $F ! cmd>copy $F scr:b-\3.new ! cmd>end ! ! @foreach F a*.for ! cmd>echo $f -- last read on \r ! cmd>end ! ! Author: ! Nelson H.F. Beebe, Department of Physics, University of Utah, ! Salt Lake City, UT 84112. ! ! Date: ! [24-Sep-88] ! !------------------------------------------------------------------------ BEGIN EXTERNAL STRING PROCEDURE strlower, strsub; STRING commands, filename, filelist, keyname, line, this_command; INTEGER k; keyname = "$" + $Atom; commands = ""; ! ! Because we need to use PARSE to read the commands ($READ does not allow ! command-line editing), we save the file list with CR LF separators; ! filelist = ""; DO filelist = filelist + $FILEL + $CRLF UNTIL $NextFile = 0; ! ! Collect the command lines in a single string with CR LF separators ! PROMPT "cmd>"; PARSE TEXT; PARSE EOL; line = $Atom; WHILE strlower(line) <> "end" DO BEGIN commands = commands + line + $CRLF; PROMPT "cmd>"; PARSE TEXT; PARSE EOL; line = $Atom END; ! ! Perform filename-independent escape substitutions outside of ! file loop. ! commands = strsub(commands,"\D",$Date); commands = strsub(commands,"\T",$Time); commands = strsub(commands,"\P",$CVITC(12)); commands = strsub(commands,"\\","\"); ! ! Main loop over files. ! filelist = strlower(filelist); ! make lower-case for Unix; DO BEGIN k = $SEARCH(filelist,$CRLF); IF k > 0 THEN BEGIN filename = filelist[1:k-1]; filelist = filelist[k+2:*]; this_command = strsub(commands,keyname,filename); this_command = strsub(this_command,"\F",filename); this_command = strsub(this_command,"\1", strlower($File_Dev(filename))); this_command = strsub(this_command,"\2", strlower($File_Dir(filename))); this_command = strsub(this_command,"\3", strlower($File_Nam(filename))); this_command = strsub(this_command,"\4", strlower($File_Typ(filename))); this_command = strsub(this_command,"\5",$File_Gen(filename)); this_command = strsub(this_command,"\R", $OutputTaD($FileInfo_I(filename,$FBREF))); this_command = strsub(this_command,"\W", $OutputTaD($FileInfo_I(filename,$FBWRT))); DOCOMMAND this_command END END UNTIL k = 0; END; !foreach !----------------------------------------------------------------------- ! Miscellaneous string procedures: ! strlower(s) return lower-case copy of s ! strupper(s) return upper-case copy of s ! strsub(s,old,new) return copy of s with all substrings old ! changed to new ! [25-Sep-88] !----------------------------------------------------------------------- STRING PROCEDURE strlower(STRING s); ! Return a lower-cased copy of s, leaving s intact; BEGIN STRING scopy; INTEGER index; scopy = s; index = 1; WHILE index <= $Length(scopy) DO BEGIN IF scopy[index:1] >= "A" THEN IF scopy[index:1] <= "Z" THEN scopy = scopy[1:index-1] + $CvItC($CvCtI(scopy[index:1]) + 32) + scopy[index+1:*]; index = index + 1 END; RETURN scopy END; !strlower ! Return a copy of s with instances of old replaced by new. Letter case ! in old is ignored; letter case of new is preserved. STRING PROCEDURE strsub(STRING s; STRING old; STRING new); BEGIN STRING scopy; INTEGER index; scopy = s; index = $SEARCHRAISED(scopy,old); WHILE index > 0 DO BEGIN scopy = scopy[1:index-1] + new + scopy[index+$Length(old):*]; index = $SEARCHRAISED(scopy,old) END; RETURN scopy END; !strsub STRING PROCEDURE strupper(STRING s); ! Return an upper-cased copy of s, leaving s intact; BEGIN STRING scopy; INTEGER index; scopy = s; index = 1; WHILE index <= $Length(scopy) DO BEGIN IF scopy[index:1] >= "a" THEN IF scopy[index:1] <= "z" THEN scopy = scopy[1:index-1] + $CvItC($CvCtI(scopy[index:1]) - 32) + scopy[index+1:*]; index = index + 1 END; RETURN scopy END; !strupper ------- 1-Nov-88 10:28:37-PST,975;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SCORE.STANFORD.EDU with TCP; Tue 1 Nov 88 10:24:51-PST Date: Tue, 1 Nov 1988 13:23 EST Message-ID: From: Rob Austein To: TOPS-20@SCORE.STANFORD.EDU, Bug-CHIVES@XX.LCS.MIT.EDU Subject: Updated domain resolver sources Reply-To: Bug-CHIVES@LCS.MIT.EDU Anybody using the MIT TOPS-20 domain resolver code (CHIVES) should consider picking up a new copy from the source directory on XX. In the past few weeks we've fixed a few obscure bugs in the search path code which used to cause "Name does not exist" errors, along with a few random minor bugfixes. The search path fixes have been running on XX for a week or so without apparent problems or any recurrences of the bugs, but have not been extensively field tested. As usual, please send any queries/bug reports, etc, to BUG-CHIVES@LCS.MIT.EDU, not to me personally. --Rob 2-Nov-88 08:24:43-PST,1440;000000000000 Return-Path: Received: from VAX01.AMS.COM by SCORE.STANFORD.EDU with TCP; Wed 2 Nov 88 08:17:57-PST Return-Path: <@GIZMO.SRI.COM:RELAY-INFO-VAX@CRVAX.SRI.COM> Received: from GIZMO.SRI.COM by VAX01.AMS.COM via SMTP with TCP; Wed, 2 Nov 88 10:07:01-EDT Received: From KL.SRI.COM by CRVAX.SRI.COM with TCP; Wed, 2 NOV 88 05:21:12 PDT Received: from ornl-knsms ([128.219.128.10]) by KL.SRI.COM with TCP; Wed, 2 Nov 88 05:15:56 PST Date: 2 Nov 88 08:14:00 WET DST From: "M. S. Pung" Subject: TCP/IP To: "info-vax" cc: pung ReSent-date: Wed 2 Nov 88 10:27:16-EDT ReSent-from: Betsy Ramsey ReSent-to: TOPS-20@SCORE.STANFORD.EDU Hello, This request should probably be directed to another list but this topic is discussed heavily on INFO-VAX so I thought I would give it a try. Does anyone know of any DECsystem-10 TCP/IP implementations ? If so, could you expound on the product names and the respective companies that offer them ??? Thanks in advance. |------------------------------------------------------------------| | Mike Pung | (615) 574-8082 | | Oak Ridge National Lab | Pung%ornl-knsms@ornl-msr.arpa | | Martin Marietta Energy Systems | 128.219.128.10 | |------------------------------------------------------------------| ------- 4-Nov-88 01:26:35-PST,1547;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SCORE.STANFORD.EDU with TCP; Fri 4 Nov 88 01:23:11-PST Date: Fri 4 Nov 88 04:23:32-EST From: Clive B. Dawson Subject: Network connectivity To: tops20@SCORE.STANFORD.EDU, tcp-ip@sri-nic.arpa Reply-To: clive%mcc.com@xx.lcs.mit.edu Message-ID: <12443816123.48.CLIVE@XX.LCS.MIT.EDU> MCC.COM (10.3.0.62) has unable to establish connections with a large percentage of the Internet hosts during the past 24 hours. I believe much of this is caused by the fact that a lot of gateways have been turned off to try and prevent the spread of the Unix virus that's been going around. Furthermore it looks like there's a lot of "one-way" gateways out there. OUr SMTP listener has had a lot of connections hanging in SYN.SYN state and timing out, presumably because our SYN's aren't making it back to the host who is trying to connect to us. But I really got confused when I discovered that many of the hosts I couldn't connect to were reachable from other hosts on the 10 net (e.g. Score and XX). If anybody can offer one or more explanations for this, I would very much like to hear about it. In particular, what are the possible causes for a host being reachable from 10.a.b.c but not from 10.x.y.z? (Note that MCC.COM's "default,preferred" address IS 10.3.0.62.) The only explanation I can come up with is that something is messed up in the PSN routing tables, and that this is a problem for the NOC. Thanks, Clive ------- 4-Nov-88 07:48:54-PST,1431;000000000000 Return-Path: Received: from mitre.arpa by SCORE.STANFORD.EDU with TCP; Fri 4 Nov 88 07:46:34-PST Full-Name: Steve Goldstein Message-Id: <8811041452.AA02859@mitre.arpa> Organization: The MITRE Corp., Washington, D.C. To: clive%mcc.com@xx.lcs.mit.edu Cc: tops20@SCORE.STANFORD.EDU, tcp-ip@sri-nic.arpa, goldstei@mitre.arpa Subject: Re: Network connectivity In-Reply-To: Your message of Fri, 04 Nov 88 04:23:32 -0500. <12443816123.48.CLIVE@XX.LCS.MIT.EDU> Date: Fri, 04 Nov 88 09:52:28 EST From: Steve Goldstein Clive, I have had similar experiences a few weeks ago with a Princeton host on arpanet and reachable thru nsfnet via jvnc. The telco line from jvnc to pri on broke, and there was no way in hell that I could get through to princeton via my normal methods. Then, I logged in to a machine in Wisconsin that happened to be on arpanet and, voila! there I was getting into the princeton host! Seems that the new routes did not age properly on jvnc's EGP-server. They should have shown the new route to princeton via arpanet, but they did not. I have no idea in this current swiss cheese Internet whether or not similar things could be happening, but certainly the gated, EGP and other things that usually hum must be going bump in the night! Keep the faith, Steve Goldstein normally: goldstein@ames.arc.nasa.gov (which is down!) 4-Nov-88 08:18:23-PST,1354;000000000000 Return-Path: Received: from MCC.COM by SCORE.STANFORD.EDU with TCP; Fri 4 Nov 88 08:15:59-PST Date: Fri 4 Nov 88 07:47:40-CST From: Clive Dawson Subject: Network Connectivity - Part 2 To: tops20@score.stanford.edu, tcp-ip@sri-nic.arpa Message-ID: <12443864209.25.AI.CLIVE@MCC.COM> After sending my previous message in which I wondered what would cause only some hosts on net 10 to be able to communicate with a certain other hosts, I began doing some systematic testing to try and determine what the connectivity was really like. In the process, I discovered the answer to my own question. It turns out that all the prime gateways which my TOPS-20 system knew about were down! Some years ago, the NIC assigned certain MILNET gateways to each Arpanet host. Up until yesterday, these gateways have always been sufficient to provide all the redirect info required. But since all the Milnet gateways apparently went down because of this virus, my system had nobody left to ask. I've added a couple of other non-Milnet prime gateways to my INTERNET.GATEWAYS file, and all is well. I suspect there may be other TOPS-20 systems out there with the same problem, since the practice of having only one or two entries in the gateways file was pretty widespread for a while. Clive ------- 4-Nov-88 09:44:15-PST,1561;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SCORE.STANFORD.EDU with TCP; Fri 4 Nov 88 09:41:45-PST Date: Fri 4 Nov 88 12:41:47-EST From: Rob Austein Subject: Re: Network Connectivity - Part 2 To: AI.CLIVE@MCC.COM cc: tops20@SCORE.STANFORD.EDU, tcp-ip@sri-nic.arpa In-Reply-To: <12443864209.25.AI.CLIVE@MCC.COM> Message-ID: <12443906829.34.SRA@XX.LCS.MIT.EDU> Clive, Right. Here's the rest of the story. XX and Score are configured differently than MCC or NIC, because while all four are multi-homed hosts, XX and Score are not the sole contact points between the nets to which they are connected. Eg, XX is connected to nets 10 and 18, but so is GW.LCS.MIT.EDU. A multi-homed TOPS-20 in this configuration needs more entries in its INTERNET.GATEWAYS file than just its IMP's two assigned "mailbridge" gateways, eg, XX's also lists GW, KLUDGE.AI.MIT.EDU, SLUDGE.LCS.MIT.EDU, and SEWAGE.MIT.EDU. Yesterday XX ended up routing all of its "default" traffic via GW.LCS.MIT.EDU after it gave up on IMP44's assigned gateways. I assume something similar happened to Score. Is the "eager pinger" problem believed to be fixed? If I remember correctly, that's where the practice of having only two live core gateways known per host came from. The NIC has a file online (in NETINFO:, I think) explaining this, but it was never clear to me if the underlying problem was really fixed or simply toned down to an acceptable level if everybody stuck to the two gateway rule. --Rob ------- 4-Nov-88 09:55:59-PST,1360;000000000000 Return-Path: Received: from WSMR-SIMTEL20.ARMY.MIL by SCORE.STANFORD.EDU with TCP; Fri 4 Nov 88 09:53:39-PST Date: Fri, 4 Nov 1988 10:28 MST Message-ID: From: "Frank J. Wancho" To: Clive Dawson Cc: tcp-ip@sri-nic.arpa, tops20@SCORE.STANFORD.EDU, WANCHO@WSMR-SIMTEL20.ARMY.MIL Subject: Network Connectivity - Part 2 In-reply-to: Msg of 4 Nov 1988 06:47-MST from Clive Dawson Clive, I discovered the same problem last night caused by the fact that the prime gateways were down (either deliberately taken down, looped off the net or powered down by the NOC) in an effort to compartmentalize the spread of the worm (not virus). It is not just the TOPS20 hosts which depend on these gateways for ICMP REDIRECTs - all hosts using the prime gateways do. Once I added a couple of other gateways, everything started flowing again everywhere except across the MIL-ARPA gateways (as I believe was the intent in shutting off those gateways). The lesson to be learned from this is that we should have at least one other non-MIL-ARPA prime gateway in the list of assigned gateways should it become necessary to isolate those two nets from each other in the future. --Frank 4-Nov-88 11:42:04-PST,1574;000000000000 Return-Path: Received: from ALEXANDER.BBN.COM by SCORE.STANFORD.EDU with TCP; Fri 4 Nov 88 11:38:48-PST To: Clive Dawson cc: tops20@score.stanford.edu, tcp-ip@sri-nic.ARPA Subject: Re: Network Connectivity - Part 2 In-reply-to: Your message of Fri, 04 Nov 88 07:47:40 -0600. <12443864209.25.AI.CLIVE@MCC.COM> Date: Fri, 04 Nov 88 12:09:39 -0500 From: Frederick E Serr BBNCC 20/666 x2474 I would urge TOPS-20 administrators NOT to add more than one or two other gateways to their gateways file, if any. The MILNET Mailbridge Gateways were explicitly turned off yesterday to slow the spread of the virus. As you yourself said, their normal reliability is such that one primary gateway and one backup entry was enough to keep your host "connected" for several years without running into this problem. Presumably, turning off the Mailbridges because of external circumstances will continue to be a rare event. The reason for only having one or two entries in the file in the first place is to reduce the amount of ICMP overhead traffic on Arpanet and Milnet. TOPS-20s periodically "ping" all the gateways on their list. A few years back, this was adding up to a substantial fraction of all the traffic on the Arpanet. While one can argue that adding one more gateway to one host will result in only a small amount of traffic, it still seems worth avoiding, when the problem one is fixing is so rare. Fred Serr Network Analysis Dept. BBN Communications 5-Nov-88 14:17:04-PST,1708;000000000000 Return-Path: Received: from MCC.COM by SCORE.STANFORD.EDU with TCP; Sat 5 Nov 88 14:13:26-PST Date: Sat 5 Nov 88 16:13:49-CST From: Clive Dawson Subject: Mail problems caused by core gateway outage To: tops20@score.stanford.edu Message-ID: <12444218493.37.AI.CLIVE@MCC.COM> I wanted to mention another effect of the outage of many of the core gateways on Thursday. A problem we've been nagged by for a long time and which most people on this list are familiar with grew many times worse: attempts to connect to the 20's SMTP server failed due to "Connection rejected." It turns out that the SMTP listener (SMTJFN in this case) does an OPENF to listen for an incoming connection. As soon as the connection is established, the OPENF returns and the listener immediately does another OPENF to keep listening while the first one gets given to another fork for processing. In this case, the connection never got fully established because our SYN's couldn't make it back to the remote host. Even though I had previously shortened the timeout period from 60 to 15 seconds, anybody trying to connect during this period would get rejected, because another listening port had not yet been established. I finally got some relief by firing up about 8 SMTJFN's. Given that there will always be problem hosts and gateways out there, I'm wondering if there is a solution to this. For example, would it be reasonable to have the OPENF return before the connection is fully established, so that another listener port could be opened more quickly? The waiting time (if any) would then occur during the first attempt for input. Clive ------- 6-Nov-88 13:24:23-PST,1140;000000000000 Return-Path: Received: from WSMR-SIMTEL20.ARMY.MIL by SCORE.STANFORD.EDU with TCP; Sun 6 Nov 88 13:22:58-PST Date: Sun, 6 Nov 1988 14:23 MST Message-ID: From: "Frank J. Wancho" To: TOPS20@SCORE.STANFORD.EDU cc: WANCHO@WSMR-SIMTEL20.ARMY.MIL Subject: RTS/CTS SPR? Some time ago I bemoaned the fact that the TTY lines do not honor out-of-band flow control, a most welcome feature addition in order to be able to properly use state-of-the-art high-speed modems, stat muxes, etc. At that time, I was advised to submit an SPR. I procrastinated while other items demanded my attention, hoping that someone else might have submitted such an SPR. Has anyone done so? Is it too late? If neither, could we band together to submit a joint SPR? Send proposed wordings directly to me and I will merge and submit such an SPR on behalf of all the respondents. On the other hand, if someone has submitted an SPR on this subject and it was rejected, I would like to know the basis for the rejection. --Frank 14-Nov-88 13:46:18-PST,507;000000000000 Return-Path: Received: from SRI-NIC.ARPA by SCORE.STANFORD.EDU with TCP; Mon 14 Nov 88 13:38:48-PST Date: Mon, 14 Nov 88 13:40:14 PST From: Mark Lottor Subject: v7 tcp/ip source To: tops-20@score.stanford.edu Message-ID: <12446571677.42.MKL@SRI-NIC.ARPA> We got our v7 tapes and source a few weeks ago. One saveset contains the tcp/ip source in encrypted form. I can't find the .KEY files to decrypt them with. Does anyone know where they are? ------- 14-Nov-88 18:18:20-PST,1830;000000000000 Return-Path: Received: from SRI-NIC.ARPA by SCORE.STANFORD.EDU with TCP; Mon 14 Nov 88 18:13:23-PST Date: Mon, 14 Nov 88 17:42:59 PST From: Mark Lottor Subject: faster incrementals To: tops-20@score.stanford.edu Message-ID: <12446615869.35.MKL@SRI-NIC.ARPA> I made some DUMPER hacks to speed up incremental dumps. Use them at your own risk. The idea of the hack is to only scan directories that have changes instead of scanning the whole filesystem. If you have a structure that doesn't change much, like a source code pack, the whole incremental dump only takes a few minutes. On structures where lots of changes occur daily, the effect will be smaller. The way the code decides whether something in a directory has changed or not is by looking at a directory word not available from GTDIR% (so the code does a GTFDB and 2 DSKOPs to read it; no monitor changes required). The word contains the TAD of the last change to anything in the directory. It compares that to the time of the last incremental (saved in a special file) and if nothing has changed it skips to the next directory, otherwise dumps the changed one normally. Some differences to watch out for: - The new code scans the structure using GTJFN on *.DIRECTORY instead of stepping with RCDIR, so things come out in a different order. - The special files PS:FASTINCREMENTAL.structure - DIRECTORY information is not dumped for all directories (we do a DLUSER before each dump so this isn't a problem) - New dumper command "FAST-INCREMENTAL (of structure) xx:" - The hack won't begin working until day 2 of using it. The changes are available via anonymous FTP from SRI-NIC.ARPA as SRC:SUBSYS>DUMPER.MAC, and everything is in a NICSW marked ";QINC". ------- 15-Nov-88 01:35:29-PST,1007;000000000000 Return-Path: Received: from uunet.UU.NET by SCORE.STANFORD.EDU with TCP; Tue 15 Nov 88 01:30:28-PST Received: from munnari.UUCP by uunet.UU.NET (5.59/1.14) with UUCP id AA11789; Tue, 15 Nov 88 03:06:28 EST Message-Id: <8811150806.AA11789@uunet.UU.NET> Received: from gara.une.oz (via gwydir) by munnari.oz with SunIII (5.5) id AA12320; Tue, 15 Nov 88 18:42:41 EST (from gordon@gara.une.oz for uunet!tops20@score.stanford.edu) Received: by gara.une.oz (5.54/5.17) id AA19787; Tue, 15 Nov 88 18:41:30 EST Date: Tue, 15 Nov 88 18:41:30 EST From: munnari!gara.une.oz.au!gordon@uunet.UU.NET (Gordon Smith) To: tops20@score.stanford.edu Subject: WANTED: VAX utility to read/write DUMPER tapes. I remember seeing mention of a VAX utility to read/write TOPS-20 DUMPER tapes a long while ago. Now a friend has need of such a beastie. Any pointers please. Thanks. Gordon Smith, Computer Centre, Uni. of New England, Armidale, Australia 2351. 15-Nov-88 05:39:35-PST,1053;000000000000 Return-Path: Received: from TOPS20.DEC.COM by SCORE.STANFORD.EDU with TCP; Tue 15 Nov 88 05:36:08-PST Date: 15 Nov 1988 0837-EST From: "David Lomartire" To: Mark Lottor , tops-20@score.stanford.edu DTN: 297-5508 Mailstop: MRO1-2/L14 Pole: MRO1-2/KL21 Subject: Re: v7 tcp/ip source Message-ID: <"MS11(6044)+GLXLIB6(0)" 12446745923.143.209.46840 at TOPS20.DEC.COM> References: Message from Mark Lottor of 14-Nov-88 1658-EST In-reply-to: <12446571677.42.MKL@SRI-NIC.ARPA> The keys for the TCP monitor sources are on the TCP Distribution tape. This tape is part of the QT090 kit. It appears that this kit may not have been shipped to every customer with a TCP license. Some of you may remember that the same problem occurred with 6.1. Are other customers experiencing this problem? We are currently investigating this situation. David Lomartire LSBU Software Engineering TOPS-20 Group -------- 19-Nov-88 21:35:39-PST,2905;000000000000 Return-Path: <@CORNELLC.ccs.cornell.edu:rmf%Janus.MRC.AdhocNet.CA@UNCAEDU.BITnet> Received: from CORNELLC.ccs.cornell.edu (CORNELLC.CIT.CORNELL.EDU.#Internet) by SCORE.STANFORD.EDU with TCP; Sat 19 Nov 88 21:33:39-PST Received: from UNCAEDU.BITnet by CORNELLC.ccs.cornell.edu (IBM VM SMTP R1.2) with BSMTP id 8032; Sun, 20 Nov 88 00:34:47 EST Received: from Janus.MRC.AdhocNet.CA by UcEdu.UNCA.AdhocNet.CA with DECNET ; Sat, 19 Nov 88 21:29:16 MST Date: Sat, 19 Nov 88 21:28:41 MST From: rmf%Janus.MRC.AdhocNet.CA%UNCAEDU.BITNET@CORNELLC.ccs.cornell.edu (Russ Forster) Message-Id: <881119212825.00f@Janus.MRC.AdhocNet.CA> Subject: EMACS under TOPS-20 v 7.0 To: tops-20@score.stanford.edu I'm having a problem moving EMACS from a PS structure to a new BS structure. Once I moved EMACS and redefined the logical names, EMACS would no longer take my login driectories EMACS.INIT file. I tried to rebuild EMACS, but I've come across the errors below. I tried to rebuild TWXBTS.MID, but MACCVT.:EJ comes up with an error. I'm stumped, frustrated, and hopelessly lost. Help! /Russ 12:35:32 MONTR @midas 12:35:37 USER NOTPUR MIDAS.425 12:35:37 USER **temp_teco/T 12:35:38 USER TECO 12:35:38 USER TTY: .INSRTed, end input with ^Z ! these switches are only relevant on tops-20's that support mul tiple structures 12:35:38 USER *EMCSDV==1 12:35:38 USER *INFODV==1 12:35:38 USER *COMNDF==1 12:35:38 USER *EXITCL==1 12:35:38 USER *^Z 12:35:38 USER 12:35:39 USER END OF LOW IMPURE = 4022 [GTTYP deleted] 12:36:07 USER TOP OF PURE = 56204 12:36:07 USER TECO 12:36:20 USER EJCMD+31 34512 0. 248-034 .FBKEP Undefined 12:36:22 USER GTTYP indices for "glass ttys", separated by commas: ! Glass tty type codes 12:36:22 USER *16. 12:36:29 USER VSCPS+2 50416 1. 336-028 DP%AG1 Undefined in lit eral 12:36:29 USER VSCPS+2 50416 1. 336-028 .VTMOV Undefined in lit eral 12:36:29 USER VSSUP+7 50471 1. 336-077 DP%AG1 Undefined in lit eral 12:36:29 USER VSSUP+7 50471 1. 336-077 DP%AG2 Undefined in lit eral 12:36:29 USER VSSUP+7 50471 1. 336-077 .VTLID Undefined in lit eral 12:36:41 USER Constants area inclusive 12:36:41 USER From To 12:36:41 USER 4007 4022 12:36:41 USER 53210 56003 12:36:41 USER Run time = 45.45 12:36:41 USER 7973 Symbols including initial ones (99% used) ----- Russell M. Forster, Systems Programmer II. Mount Royal College DECnet: RMF @ Janus Computer Operations BITnet: RForster @ UncaEdu.BITnet 4825 Richard Rd. S.W. ICBM: 51 03 N / 114 05 W Calgary, Alberta Phone: (403) 240-6052 T3E 6K6 19-Nov-88 23:35:20-PST,1555;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SCORE.STANFORD.EDU with TCP; Sat 19 Nov 88 23:34:22-PST Date: Sun 20 Nov 88 02:36:14-EST From: Rob Austein Subject: Re: EMACS under TOPS-20 v 7.0 To: rmf%Janus.MRC.AdhocNet.CA%UNCAEDU.BITNET@CORNELLC.CIT.CORNELL.EDU cc: tops-20@SCORE.STANFORD.EDU In-Reply-To: <881119212825.00f@Janus.MRC.AdhocNet.CA> Message-ID: <12447990894.16.SRA@XX.LCS.MIT.EDU> Russ, A few things to try: 1) Try rebuilding just EMACS without rebuilding TECO. If this works you have saved yourself trying to figure out what the real problem is. 2) Check to make sure you have a consistant version of your sources. You should not be seeing references to the symbol .VTLID (a VTSOP% opcode) since presumably you are not running the MIT VTS monitor. 3) Try building a new version of MIDAS (with a current TNXDFU.MID, generated by running CVTUNV), then comment out the TNXBTS/TWXBTS stuff. MIDAS running on TOPS-20 is supposed to have all the MONSYM-ish bits assembled into itself (on ITS MIDAS just gets the bits on the fly from the monitor), so loading another set of MONSYM symbols on the fly might be confusing some piece of conditional assembly code. If all of this fails, send mail to BUG-TECO@MC.LCS.MIT.EDU and you might find some hardy soul with the time and inclination to help you out. At the very least you'll brighten up the day for a few people who thought that list had died due to apathy.... --Rob ------- 21-Nov-88 10:33:49-PST,2371;000000000000 Return-Path: <@CORNELLC.ccs.cornell.edu:rmf%Janus.MRC.AdhocNet.CA@UNCAEDU.BITnet> Received: from CORNELLC.ccs.cornell.edu (CORNELLC.CIT.CORNELL.EDU.#Internet) by SCORE.STANFORD.EDU with TCP; Mon 21 Nov 88 10:31:19-PST Received: from UNCAEDU.BITnet by CORNELLC.ccs.cornell.edu (IBM VM SMTP R1.2) with BSMTP id 9345; Mon, 21 Nov 88 13:32:27 EST Received: from Janus.MRC.AdhocNet.CA by UcEdu.UNCA.AdhocNet.CA with DECNET ; Mon, 21 Nov 88 11:04:33 MST Date: Mon, 21 Nov 88 11:04:00 MST From: rmf%Janus.MRC.AdhocNet.CA%UNCAEDU.BITNET@CORNELLC.ccs.cornell.edu (Russ Forster) Message-Id: <881121110400.011@Janus.MRC.AdhocNet.CA> Subject: Re: EMACS under TOPS-20 v 7.0 In-Reply-To: Your message dated 20-Nov-1988 To: JTW@XX.LCS.MIT.EDU cc: Tops-20@Score.Stanford.Edu > .FBKEP undefined is almost undoubtedly due to your TWXBTS.MID being old. > You can get the definition from the MONSYM.MAC that came with your > Rel-7 tapes, and edit it into TWXBTS by hand. Considering I'm going from 6.1 to 7.0, I'm sure this is the case. I'll lay odds on it being a 5.1 version. > The other errors are all due to the fact that you have somehow asked > TECO to include support for VTS virtual terminals. These are an MIT- > only extension to TOPS20. Check your CONFIG.MID file and make sure > that the VTS terminal type -isn't- defined. I think you are using > the file just as you got it from MIT, which won't quite work. I can't seem to find where this definition takes place. > What version of EMACS and TECO do you have? EMACS 62172 TECO 1171 MIDAS 425 If these are the most receivt copies, and I doubt they are, is there a place a non-FTP site can get them from? Mark, can I get tehm from SERVICE@SRI-NIC? > There really isn't anybody supporting this stuff anymore, but there > are a couple of us who can try to help you if you get stuck again. > Good luck... Thanks, > -john /Russ ----- Russell M. Forster, Systems Programmer II. Mount Royal College DECnet: RMF @ Janus Computer Operations BITnet: RForster @ UncaEdu.BITnet 4825 Richard Rd. S.W. ICBM: 51 03 N / 114 05 W Calgary, Alberta Phone: (403) 240-6052 T3E 6K6 23-Nov-88 00:25:46-PST,2317;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SCORE.STANFORD.EDU with TCP; Wed 23 Nov 88 00:24:11-PST Date: Wed 23 Nov 88 03:26:02-EST From: Rob Austein Subject: You've heard of the annual MIT piano drop? Well... To: TOPS-20@SCORE.STANFORD.EDU Message-ID: <12448786394.19.SRA@XX.LCS.MIT.EDU> Date: Tue 1 Nov 88 16:46:10-EST From: Jan Thomson LCS-Announcement-1/Nov/88 XX is shutting down on 15/Jan/89 The primary user services provided by the DEC 2065 system XX are (e-mail, Emacs, Scribe, TEX, File backup). These functions are available on other systems at LCS. An October 20, 1988 meeting of the Computer Resources Advisory Committee carefully reviewed the financial and space costs of XX and the technical and social consequences of shutting down XX. It concluded that: "Effective January 15, 1989 all user accounts on XX will be discontinued and all user level services will be terminated provided a system to retrieve XX tape files has been demonstrated." This decision has been reviewed and agreed to by the system manager (Austein), and the Computer Resources Advisory Committee members (Greene, Vezza, Clark, Ward, Rivest, Szolovits). Users of XX are asked to transfer their processing to their own group systems or their personal workstations. Please direct comments/suggestions to BUG-KILLING-XX@XX.LCS.MIT.EDU. ------- Before anybody panics, we will be doing something to preserve the hostname XX.LCS.MIT.EDU and the email functions associated with it. We will also figure out something to do with the CHIVES sources and other source code that somebody tells us (BUG-TWENEX@XX.LCS.MIT.EDU) is important. But we are unlikely to be doing much more Twenex development after January, and anybody still using an XX user account had better find another home. For those who care, the thing that finally killed the machine was footprint. Where it says in the enclosed notice that I agreed to the decision, it really means that I agreed that the machine probably would not run too well out in the parking lot. --Rob ... Three little Indian boys walking in the Zoo; A big bear hugged one and then there were two ... ------- 23-Nov-88 09:53:15-PST,1785;000000000000 Return-Path: <@CORNELLC.ccs.cornell.edu:rmf%Janus.MRC.AdhocNet.CA@UNCAEDU.BITnet> Received: from CORNELLC.ccs.cornell.edu (CORNELLC.CIT.CORNELL.EDU.#Internet) by SCORE.STANFORD.EDU with TCP; Wed 23 Nov 88 09:51:34-PST Received: from UNCAEDU.BITnet by CORNELLC.ccs.cornell.edu (IBM VM SMTP R1.2) with BSMTP id 2667; Wed, 23 Nov 88 12:52:43 EST Received: from Janus.MRC.AdhocNet.CA by UcEdu.UNCA.AdhocNet.CA with DECNET ; Wed, 23 Nov 88 09:56:51 MST Date: Wed, 23 Nov 88 09:56:25 MST From: rmf%Janus.MRC.AdhocNet.CA%UNCAEDU.BITNET@CORNELLC.ccs.cornell.edu (Russ Forster) Message-Id: <881123095625.042@Janus.MRC.AdhocNet.CA> Subject: EMACS on 7.0 To: Tops-20@Score.Stanford.Edu Thanks to all for the suggestions they provided. I still have a problem, most mentioned that virtual-terminal stuff, but I can't seem to find it defined anywhere. Actually, I looked at all the code and both TECO and EMACS (and MIDAS for that matter) had no machines defined. I was able to finally bebuild MIDAS, bit now none of the monsym entries are defined and nothing compiles. I did a '@set trap file' and noticed that DECDFS and TSRTNS are both read. I seem to be really lost here. I'm still looking for a place a non-FTP person can get EMACS from. Does anyone know of such a place? Would someone like to e-mail the files? Maybe a uuencoded TAR file or some such. /Russ ----- Russell M. Forster, Systems Programmer II. Mount Royal College DECnet: RMF @ Janus Computer Operations BITnet: RForster @ UncaEdu.BITnet 4825 Richard Rd. S.W. ICBM: 51 03 N / 114 05 W Calgary, Alberta Phone: (403) 240-6052 T3E 6K6 23-Nov-88 10:32:03-PST,1113;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SCORE.STANFORD.EDU with TCP; Wed 23 Nov 88 10:31:15-PST Date: Wed 23 Nov 88 13:32:34-EST From: Rob Austein Subject: Re: EMACS on 7.0 To: rmf%Janus.MRC.AdhocNet.CA%UNCAEDU.BITNET@CORNELLC.CIT.CORNELL.EDU cc: Tops-20@SCORE.STANFORD.EDU In-Reply-To: <881123095625.042@Janus.MRC.AdhocNet.CA> Message-ID: <12448896810.32.SRA@XX.LCS.MIT.EDU> TSRTNS is ok in a TOPS-20 MIDAS assembly (TS = Time Sharing, ie, not running on a bare PDP-10). DECDFS is NOT ok in a TOPS-20 assembly, it's TOPS-20 UUOs. Read the comment at the head of MIDAS.MID that describes assembly options, and assemble it as if you were cross-assembling it with TOPS-20 as the target system (ie, don't rely on MIDAS to figure out what opsys you want it to run on). Most of the VTS code in TECO is under IFN VTS,[] switches in TECTRM.MID. There are also some bits and pieces of it that are just assumed if the right VTS specific jsi are defined in TECO.MID, which is why it's important to get a coherent version of MIDAS. --Rob ------- 23-Nov-88 10:34:19-PST,571;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SCORE.STANFORD.EDU with TCP; Wed 23 Nov 88 10:32:51-PST Date: Wed 23 Nov 88 13:34:27-EST From: Rob Austein Subject: typo in previous message To: rmf%Janus.MRC.AdhocNet.CA%UNCAEDU.BITNET@CORNELLC.CIT.CORNELL.EDU cc: Tops-20@SCORE.STANFORD.EDU In-Reply-To: <881123095625.042@Janus.MRC.AdhocNet.CA> Message-ID: <12448897151.32.SRA@XX.LCS.MIT.EDU> That should have been "DECDFS is NOT ok in a TOPS-20 assembly, it's TOPS-10 UUOs" rather than "TOPS-20 UUOs". Sigh. ------- 25-Nov-88 17:03:14-PST,461;000000000000 Return-Path: Received: from WSMR-SIMTEL20.ARMY.MIL by SCORE.STANFORD.EDU with TCP; Fri 25 Nov 88 17:00:13-PST Date: Fri, 25 Nov 88 18:02:04 MST From: Mark Crispin Subject: GTHST% bug To: TOPS-20@SCORE.STANFORD.EDU Address: P.O. Box 2652; Seattle, WA 98111-2652 Message-ID: <12449492004.23.MRC@WSMR-SIMTEL20.ARMY.MIL> In MNETDV, the JUMPL P2, at GTHHNN+2 should be JUMPL P1,... ------- 28-Nov-88 13:58:23-PST,2808;000000000000 Return-Path: <@CORNELLC.ccs.cornell.edu:rmf%Janus.MRC.AdhocNet.CA@UNCAEDU.BITnet> Received: from CORNELLC.ccs.cornell.edu (CORNELLC.CIT.CORNELL.EDU.#Internet) by SCORE.STANFORD.EDU with TCP; Mon 28 Nov 88 13:53:00-PST Received: from UNCAEDU.BITnet by CORNELLC.ccs.cornell.edu (IBM VM SMTP R1.2) with BSMTP id 9802; Mon, 28 Nov 88 16:52:06 EST Received: from Janus.MRC.AdhocNet.CA by UcEdu.UNCA.AdhocNet.CA with DECNET ; Mon, 28 Nov 88 14:47:14 MST Date: Mon, 28 Nov 88 14:46:38 MST From: rmf%Janus.MRC.AdhocNet.CA%UNCAEDU.BITNET@CORNELLC.ccs.cornell.edu (Russ Forster) Message-Id: <881128144632.00j@Janus.MRC.AdhocNet.CA> Subject: Re: Re: EMACS under TOPS-20 v 7.0 In-Reply-To: Your message Is it reading EMACS.VARS from your BS: directory instead of your PS: directory ? Not its not, nor is it reading my EMACS.INIT file.... > If so I may able to help with a workaround patch. I'm not able to get the > specifics right now, but we have a patched TECPUR.EXE here. There is a spot i n > the code where it is trying to get the logged in corectory number from the > logged in user number. It does this by loading 40000 in to the left have of > AC1 returned by GJINF. This will mean that you will get the first entry in > STRTAB for the structure. Since BS: is always at STRTAB+0 and PS: is always a t > STRTAB+1, a cheap way around this is to add 1 to the structure number field. ...because according to your scenerio the following happens PS:[rmf] -> PS:[4,116] BS:[4,116] -> PS:[omega.source.new] > In our TECPUR, it is at the following addresses. The GJINF% (JSYS 13) is the > one at the lowest address in TECPUR. > 6046/ GJINF% > 6047/ TLNE 1,777777 > 6050/ TLO 1,40000 TLO 1,40001 > Since you cannot rebuild your EMACS for whatever reason, this patch should mak e > it look at PS: instead of BS:. I'll try to find out more about > this if you want me to. Applying this patch to TECPUR worked! EMACS is now using my .INIT and .VARS files just aa it does on 6.1. This makes me a very happy puppy :-) :-) :-) :-) :-)...... It concerns me though that the tlo,1,40000 gets broken, I see to remember code that I've written that does the same sort of thing. Were things always this way or is this new to 7.0. /Russ ----- Russell M. Forster, Systems Programmer II. Mount Royal College DECnet: RMF @ Janus Computer Operations BITnet: RForster @ UncaEdu.BITnet 4825 Richard Rd. S.W. ICBM: 51 03 N / 114 05 W Calgary, Alberta Phone: (403) 240-6052 T3E 6K6 28-Nov-88 23:00:58-PST,624;000000000000 Return-Path: Received: from WSMR-SIMTEL20.ARMY.MIL by SCORE.STANFORD.EDU with TCP; Mon 28 Nov 88 22:59:14-PST Date: Mon, 28 Nov 88 19:05:33 MST From: Mark Crispin Subject: RMF's problem with TECO To: TOPS-20@SCORE.STANFORD.EDU Address: P.O. Box 2652; Seattle, WA 98111-2652 Message-ID: <12450289991.24.MRC@WSMR-SIMTEL20.ARMY.MIL> The correct way to translate a user number to a PS: directory number is to use RCDIR%, not TLO ac,40000 for the reason that can be observed here -- the login structure is not necessarily the same as structure 0. ------- 29-Nov-88 08:14:06-PST,774;000000000000 Return-Path: Received: from TE.CC.CMU.EDU by SCORE.STANFORD.EDU with TCP; Tue 29 Nov 88 08:08:27-PST Date: Tue 29 Nov 88 11:07:39-EST From: C. P. Yeske Subject: Tops20 Utilities Going... To: tops20@SCORE.STANFORD.EDU Home-Phone: (412)422-4667 (422-GOOP, -IONS, -HOOP) Office: UCC A72 x2647 Organization: Carnegie Mellon Computing Services, Hardware Systems Message-ID: <12450443290.17.CY13@TE.CC.CMU.EDU> CMU is in the process of phasing out its DEC 2060's. In 9 years, I have accumulated some unique utilities, games, etc that depend on this system. Most are .exe files, some are source. Is anyone interested in these before I delete the files? Curt cy13+@andrew.cmu.edu cy13@te.cc.cmu.edu ------- 29-Nov-88 09:04:12-PST,1603;000000000000 Return-Path: <@CORNELLC.ccs.cornell.edu:rmf%Janus.MRC.AdhocNet.CA@UNCAEDU.BITnet> Received: from CORNELLC.ccs.cornell.edu (CORNELLC.CIT.CORNELL.EDU.#Internet) by SCORE.STANFORD.EDU with TCP; Tue 29 Nov 88 08:56:46-PST Received: from UNCAEDU.BITnet by CORNELLC.ccs.cornell.edu (IBM VM SMTP R1.2) with BSMTP id 1016; Tue, 29 Nov 88 11:56:10 EST Received: from Janus.MRC.AdhocNet.CA by UcEdu.UNCA.AdhocNet.CA with DECNET ; Tue, 29 Nov 88 09:54:20 MST Date: Tue, 29 Nov 88 09:53:35 MST From: rmf%Janus.MRC.AdhocNet.CA%UNCAEDU.BITNET@CORNELLC.ccs.cornell.edu (Russ Forster) Message-Id: <881129095335.01l@Janus.MRC.AdhocNet.CA> Subject: Re: RMF's problem with TECO In-Reply-To: Your message <12450289991.24.MRC@WSMR-SIMTEL20.ARMY.MIL> dated 28-Nov-1988 To: MRC@WSMR-SIMTEL20.ARMY.MIL cc: Tops-20@Score.Stanford.Edu > The correct way to translate a user number to a PS: directory > number is to use RCDIR%, not TLO ac,40000 for the reason that > can be observed here -- the login structure is not necessarily > the same as structure 0. Yes but the problem remains that I can't rebuild TECO (for whatever reason). I have successfully patched TECPUR and I do have EMACS working again. Thanks to all for all your help. /Russ ----- Russell M. Forster, Systems Programmer II. Mount Royal College DECnet: RMF @ Janus Computer Operations BITnet: RForster @ UncaEdu.BITnet 4825 Richard Rd. S.W. ICBM: 51 03 N / 114 05 W Calgary, Alberta Phone: (403) 240-6052 T3E 6K6 29-Nov-88 14:16:01-PST,589;000000000000 Return-Path: Received: from MCC.COM by SCORE.STANFORD.EDU with TCP; Tue 29 Nov 88 14:03:21-PST Date: Tue 29 Nov 88 16:02:57-CST From: Clive Dawson Subject: Re: Tops20 Utilities Going... To: CY13@TE.CC.CMU.EDU cc: tops20@score.stanford.edu In-Reply-To: <12450443290.17.CY13@TE.CC.CMU.EDU> Message-ID: <12450507973.24.AI.CLIVE@MCC.COM> Curt- It would be nice if you could put all this stuff into some anonymously ftp'able directory so that the few of us who remain can do some browsing. Is this feasible? Thanks, Clive ------- 1-Dec-88 18:34:44-PST,1797;000000000000 Return-Path: Received: from WSMR-SIMTEL20.ARMY.MIL by SCORE.STANFORD.EDU with TCP; Thu 1 Dec 88 18:31:19-PST Date: Thu, 1 Dec 1988 19:30 MST Message-ID: From: "Frank J. Wancho" To: "C. P. Yeske" Cc: tops20@SCORE.STANFORD.EDU, WANCHO@WSMR-SIMTEL20.ARMY.MIL Subject: Tops20 Utilities Going... In-reply-to: Msg of 29 Nov 1988 09:07-MST from C. P. Yeske In keeping with our reputation in other areas as a repository of all sorts of software, we request that you and anyone else planning to phase out their DEC-20 take the time to make a DUMPER tape at 6250 bpi (preferred), and mail it to me at the address below. MRC, CLIVE, and myself will attempt to maintain an organized collection online. I already have a tape from Columbia, not yet online due to disk space availability. I expect to procure four more RP07s during this FY to expand the disk space available for our ever-growing collections. To avoid any possible tape mixups in my office, please use the following address: Frank J. Wancho 10560 Lakewood El Paso, TX 79925 The last time I sent a message on this subject, I gave it the obscure title of the Seattle Project, and many of you did not make the connection. Several years ago, the aerospace industry was experiencing massive layoffs which particularly affected the Seattle area. Rumor has it that that was a billboard on one of the main arteries leading out of Seattle asking, "Would the last one out please shut off the lights?" We plan to hold on to what we got and be that last one to keep the lights burning... (I told you it was obscure, and it still is...) --Frank 2-Dec-88 06:43:30-PST,1278;000000000000 Return-Path: Received: from RADC-MULTICS.ARPA by SCORE.STANFORD.EDU with TCP; Fri 2 Dec 88 06:41:11-PST Date: Fri, 2 Dec 88 09:38 EST From: DLynch@RADC-MULTICS.ARPA Subject: NETWORK PROBLEMS To: tops-20@SCORE.STANFORD.EDU cc: DLynch@RADC-MULTICS.ARPA Message-ID: <881202143836.933976@RADC-MULTICS.ARPA> We have been having network problems for the past week. I think most of you have had some of the same problems. First it was the gateways, then our IMP, then I believe they took the Arpanet down. Some of it seems to be fixed, but we (RADC-TOPS20.ARPA) are still not able to communicate with anyone. That's why I am sending this from RADC-MULTICS.ARPA. The question: Is the Arpanet back up and running ? One of our hosts can communicate but we can't. We are getting BUGINF NTOHNG. Is it the network still or do we have some hardware or software problems? I thought one of you might be more familiar with what is going on and could save me some time/money on hardware calls. I don't have a clue as to where to start. Thanks, Donna Please reply to me directly at DLynch@RADC-MULTICS.ARPA. RADC-TOPS20.ARPA is on the mailing list, but as I said we aren't receiving any messages right now. 15-Dec-88 10:57:35-PST,778;000000000000 Return-Path: Received: from TE.CC.CMU.EDU by SCORE.STANFORD.EDU with TCP; Thu 15 Dec 88 10:53:42-PST Date: Thu 15 Dec 88 13:51:50-EST From: C. P. Yeske Subject: Re:Tops-20 programs To: tops20@SCORE.STANFORD.EDU Home-Phone: (412)422-4667 (422-GOOP, -IONS, -HOOP) Office: UCC A72 x2647 Organization: Carnegie Mellon Computing Services, Hardware Systems Message-ID: <12454667485.10.CY13@TE.CC.CMU.EDU> Do to overwhelming demand, I have the files available for anonymous FTP from PS:*.*.*@te.cc.cmu.edu. I can not make a tape of these, sorry. These files will be deleted sometime before DEC 20th, so act quickly... Let me know of any problems, but I think that this is the best I can do. Curt ------- 15-Dec-88 13:17:43-PST,712;000000000000 Return-Path: Received: from SRI-NIC.ARPA by SCORE.STANFORD.EDU with TCP; Thu 15 Dec 88 13:16:14-PST Date: Thu, 15 Dec 88 13:16:17 PST From: Mark Lottor Subject: DEC-20 day To: tops-20@score.stanford.edu Message-ID: <12454693781.34.MKL@SRI-NIC.ARPA> I'm arranging another DEC-20 day for people in the bay area. This time it will be lunch in Palo Alto. Come talk with other 20 hackers or X-20 hackers about DEC-20's. There may even be souvenirs and possibly a showing of a 20 related video tape afterwards. The date is Tuesday, Dec 20, 1988 at Noon. The place will be Theo's at 546 University Ave in Palo Alto. You should RSVP to me by Dec 19. ------- 23-Dec-88 08:59:23-PST,2091;000000000000 Return-Path: <@CORNELLC.ccs.cornell.edu:rmf%Janus.MRC.AdhocNet.CA@UNCAEDU.BITnet> Received: from CORNELLC.ccs.cornell.edu by SCORE.STANFORD.EDU with TCP; Fri 23 Dec 88 08:57:42-PST Received: from UNCAEDU.BITnet by CORNELLC.ccs.cornell.edu (IBM VM SMTP R1.2) with BSMTP id 6268; Fri, 23 Dec 88 11:58:18 EST Received: from Janus.MRC.AdhocNet.CA by UcEdu.UNCA.AdhocNet.CA with DECNET ; Fri, 23 Dec 88 09:54:24 MST Date: Fri, 23 Dec 88 09:52:12 MST From: rmf%Janus.MRC.AdhocNet.CA%UNCAEDU.BITNET@CORNELLC.ccs.cornell.edu (Russ Forster) Message-Id: <881223095212.01m@Janus.MRC.AdhocNet.CA> Subject: OPRIAC-CRASHes To: tops-20@score.stanford.edu Since moving to 7.0 AP19 we have experenced this type of OPR crash. The crash comes as soon as you issue a SHOW MESSAGES and there are too many message to display. It appears that there canot be more then 10 outstanding messages. If you go through and issue a 'RESPOND n PROCEED' where n=1 to 11 by 1 you will clear enough outstanding messages to actually do a SHOW MESSAGES command. Why do we have so many messages at boot time you ask? Well we have approx 30 remote printers via LAT what need to be accessable from all systems. While I'm here, the person that designed the OPR interface for defining remote printers must have been on drugs. That is the most convoluted pile of doggie-doo i have ever seen. Ok you system managers out there, try and explain that interface to your operators! Merry Christmas to all and a very Happy New Year! /Russ ps. How was DEC-20 day? Being in Canada its kinda hard to justify a lunch in Calafornia! :-) ----- Russell M. Forster, Systems Programmer II. Mount Royal College DECnet: RMF @ Janus Computer Operations BITnet: RForster @ UncaEdu.BITnet 4825 Richard Rd. S.W. ICBM: 51 03 N / 114 05 W Calgary, Alberta Phone: (403) 240-6052 T3E 6K6 23-Dec-88 20:13:04-PST,783;000000000000 Return-Path: Received: from SRI-NIC.ARPA by SCORE.STANFORD.EDU with TCP; Fri 23 Dec 88 20:12:28-PST Date: Fri, 23 Dec 88 20:12:03 PST From: Mark Lottor Subject: dec-20 day To: tops-20@SCORE.STANFORD.EDU Message-ID: <12456866621.15.MKL@SRI-NIC.ARPA> DEC-20 day turned out fairly well this year. Exactly half a word of people showed up for the lunch. After lunch there were some bumper stickers to commemorate the event. DEC donated a box of DECsystem-4050 3-ring binders as souvenirs. Later on we watched a video tape of some DEC-commercial skits, followed by a talk (on tape) by Alan Kotok on the origins of the PDP-6 and PDP-10. Thanks to Joe Dempster of DEC for the binders and Len Bosack of cisco for the tapes. -------