2-Jan-87 17:49:53-PST,349;000000000000 Return-Path: Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Fri 2 Jan 87 17:46:01-PST Date: Fri 2 Jan 87 17:49:22-PST From: Mark Lottor Subject: CRYPT To: tops-20@SCORE.STANFORD.EDU Message-ID: <12267834822.15.MKL@SRI-NIC.ARPA> Does anyone have sources to the standard CRYPT program? ------- 5-Jan-87 09:06:53-PST,561;000000000000 Return-Path: Received: from GSB-HOW.STANFORD.EDU by SU-SCORE.ARPA with TCP; Mon 5 Jan 87 09:04:32-PST Date: Mon 5 Jan 87 09:04:22-PST From: Eric M. Berg Subject: Re: CRYPT To: MKL@SRI-NIC.ARPA cc: tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Mark Lottor " of Fri 2 Jan 87 18:02:53-PST Phone-#s: 723-1576 (GSB-CF), 329-9940 (home), 725-6900 x.31576 (Voice mail) The sources to CRYPT seem to be available as PS:CRYPT.FAI on Sierra.Stanford.Edu. ------- 6-Jan-87 23:29:30-PST,1783;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Tue 6 Jan 87 23:28:59-PST Date: Wed 7 Jan 87 00:30:51-MST From: Frank J. Wancho Subject: ARC/MARC/XARC and a new SQ/USQ for TOPS-20 To: INFO-CPM@AMSAA.ARPA, INFO-MICRO@BRL.ARPA, INFO-IBMPC@C.ISI.EDU cc: TOPS-20@SCORE.STANFORD.EDU Message-ID: <12268945564.6.WANCHO@SIMTEL20.ARPA> The TOPS-20 versions of the MSDOS ARC program (based on the 5.12 source release and recent bug fixes from the Unix world) and a new TOPS-20 version of the SQ/USQ utilities (based on the version 3 update of the SQU-PORT release) are now available from SIMTEL20.ARPA. Both sets require the latest version of the TOPS-20 KCC C compiler and runtimes. For information on the availability of KCC, send a message to INFO-KCC-REQUEST@SRI-NIC.ARPA. Both sets also require the files LIBT20.H and LIBT20.REL, which reside in the C: directory here, if it is necessary to rebuild any of the programs. Ready-to- run executables are provided in their respective directories here. Both sets of sources contain TOPS20 conditionals to make the changes easy to identify. Some of the changes may be applicable to some Unix environments. It should be possible to eventually merge these changes with those versions being circulated for the Unix environments so that one consistent set of sources can be used to build these programs. Sources, "make" files, and executables are in PD: and PD: here on SIMTEL20.ARPA. Bug reports concerning these versions should be sent via netmail directly to me. (Sources for LIBT20 will be available at a later date, when I quit adding features and catch up with the documentation.) --Frank ------- 7-Jan-87 18:36:10-PST,644;000000000001 Return-Path: Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Wed 7 Jan 87 18:33:21-PST Date: Wed 7 Jan 87 18:35:10-PST From: Vivian Neou Subject: DUMPER tape copying? To: tops-20@SCORE.STANFORD.EDU cc: vivian@SRI-NIC.ARPA Message-ID: <12269153879.25.VIVIAN@SRI-NIC.ARPA> I've been trying to copy a dumper archive tape, and have so far been unsuccessful. The methods that worked under Rel. 5 (COPY at the EXEC, MTCOPY from swskit and TCOPY from CMU) no longer seem to work on 6.1. Does anyone have a way to copy dumper tapes that works on 6.1? Thanks. Vivian Neou ------- 7-Jan-87 18:57:44-PST,3570;000000000001 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Wed 7 Jan 87 18:56:22-PST Date: Wed 7 Jan 87 21:59:16-EST From: Ken Rossman Subject: Re: DUMPER tape copying? To: Vivian@SRI-NIC.ARPA, tops-20@SU-SCORE.ARPA In-Reply-To: <12269153879.25.VIVIAN@SRI-NIC.ARPA> Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 Message-ID: <12269158265.19.SY.KEN@CU20B.COLUMBIA.EDU> I've been trying to copy a dumper archive tape, and have so far been unsuccessful. The methods that worked under Rel. 5 (COPY at the EXEC, MTCOPY from swskit and TCOPY from CMU) no longer seem to work on 6.1. Does anyone have a way to copy dumper tapes that works on 6.1? If you want verbatim tape-to-tape dumper copies, I believe the EXEC's COPY command should still work. You will need to make sure the following parameters are set: - If the source tape is labelled, then make sure the other tape is also labelled. I am not sure, but I think somehow DUMPER's checksumming process takes into account the label info, so the label on the target tape will have to be the same as the source tape label, and you will need to go through TOPS-20 labelled tape handling (i.e. let TOPS-20 handle the label processing). This is just a gut impression I got from one of the times I worked with tape copying in the EXEC, and it might not be correct. Anyone else care to tackle this one? I'd like to know since the topic was raised. - Find out the following about the source tape, and make sure to issue the appropriate EXEC SET TAPE commands: o Was it core-dump or industry-compatible? (other formats I can't guarantee will work, but they should theoretically). Also, theoretically, SET TAPE FORMAT INDUSTRY should work in all cases, since it should just simply do straight 8 bit byte copies from one tape to the other, preserving all bits and bit positions, but for some reason, this seemed to generate checksum errors in the output tape. I never understood why, so I just made sure that the EXEC used the same parameters that matched the input tape. o Was the source tape even parity instead of odd (which is default)? o You will need to know the actual physical blocking factor of the source tape. If the DUMPER blocking factor was 1, then you will need to tell the EXEC to use a record length of 2590. Actually, this might have changed with version 6, so this might be your problem, though I don't know what to tell you about how to find out what DUMPER would now use as a blocking factor in actual bytes. Other DUMPER blocking factors would then, of course, be multiples of that magic number 2590, or whatever the new V6 magic number is now. o You'll want to probably make sure that the output density is also the same, though theoretically it doesn't have to be as long as the output tape can hold all of the data if you wish to make the output tape a lower density than the input one. The EXEC command "copy T1:*.*.* T2:*.*.*" (where T1 is the input tape and T2 is the output tape, of course) should then work. If the tape is unlabelled, then you will need to issue separate copy commands for each file on the source tape ("copy T1: T2:" -- no asterisks will work here, since unlabelled tapes know nothing about the TOPS-20 file system). /Ken ------- 7-Jan-87 23:36:44-PST,1681;000000000000 Return-Path: Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Wed 7 Jan 87 23:34:47-PST Date: Wed 7 Jan 87 23:36:50-PST From: Mark Lottor Subject: CRYPT part II To: tops-20@SCORE.STANFORD.EDU Message-ID: <12269208796.13.MKL@SRI-NIC.ARPA> Well, I had this diary of sorts that I had spent two years working on, from around '82-'84. I hadn't made an entry in a few months, and when I went to decode the file I found that I had forgotten the password. So, last week I thought I'd do something about it. I got the sources to the CRYPT program and I hacked it up to try every single key. I figured it might run for 5 or 10 years but I wasn't in a hurry. The key was 71 bits, but I found what may have been a bug that reduced it to only 35. This computed to only about 200 days. I tried a test case with a simple key, and was a bit surprised when it was decoded in about a minute. So, I fired up the batch job that was going to take all year to complete. But it finished a minute later! Yes, it was decoded. No, it didn't try every key. Hardly any matter of fact. I don't know how the algorithm was supposed to work, but it appears that lots of keys are "equal" to each other. I have found that I can decode any text file in about a minute. This is using the CRYPT program (NCRYPT.FAI) that writes out the coded file in a format like: ;crypt ahdsj jhaud oiqmn djdud djsau kasia zajza husdh ;end Just a warning to anyone using it; it's worthless. Now the questions: Was it known this program was so bad? Is there a good crypt program for Tops-20? One that's been tested? Mark ------- 8-Jan-87 10:08:39-PST,968;000000000001 Return-Path: Received: from Sierra.Stanford.EDU by SU-SCORE.ARPA with TCP; Thu 8 Jan 87 10:07:43-PST Date: Thu 8 Jan 87 10:07:00-PST From: Stu Grossman Subject: Re: CRYPT part II To: MKL@SRI-NIC.ARPA cc: tops-20@Score.Stanford.EDU In-Reply-To: <12269208796.13.MKL@SRI-NIC.ARPA> Message-ID: <12269323513.23.GROSSMAN@Sierra.Stanford.EDU> The two most common encrytpion things that people on TOPS-10 have been using for years were in BACKUP (the Tops-10 equivalent of DUMPER), and in SOS (EDIT to you TOPS-20 folks). I have no idea how well the encryption stuff works in either of these programs. By the way, VMS has a DES encryption program. You may want to look into that as I know that SRI runs VMS and has sources. Sorry I didn't mention anything on TOPS-20, but I sure that someone somewhere on the Arpanet still has copies of Tops-10 sources around. Stu Grossman ------- 8-Jan-87 11:46:17-PST,1370;000000000000 Return-Path: Received: from MCC.COM by SU-SCORE.ARPA with TCP; Thu 8 Jan 87 11:44:26-PST Date: Thu 8 Jan 87 13:46:40-CST From: Clive Dawson Subject: Re: CRYPT part II To: GROSSMAN@SIERRA.STANFORD.EDU cc: MKL@SRI-NIC.ARPA, tops-20@SCORE.STANFORD.EDU In-Reply-To: <12269323513.23.GROSSMAN@Sierra.Stanford.EDU> Message-ID: <12269341658.22.AI.CLIVE@MCC.COM> The encryption stuff found in TOPS-10 Backup and SOS is also rather unreliable. Years ago I performed a "known plaintext" attack on that algorithm and developed a program which would spit out keys instantaneously given just a few bytes of the encrypted and corresponding plaintext. If I recall correctly, the set of keys was partitioned into equivalence classes of 30 keyes each. The program would output all 30, any of which would work; but it was usually quite obvious what the original one was. It sounds as if the keys for TOPS-20's Crypt program form equivalence classes that are many times greater than 30, which would explain the success of the brute force approach. I don't know how the SOS algorithm would stand up to brute force, given that there are only 30 possible keys, but the algorithm is so weak that a semi-brute-force attack based on guessing portions of the plaintext would certainly succeed very quickly. Clive ------- 10-Jan-87 20:23:29-PST,573;000000000000 Mail-From: BILLW created at 10-Jan-87 20:23:26 Date: Sat 10 Jan 87 20:23:26-PST From: William "Chops" Westfield Subject: minitab To: su-tops-20@Score.Stanford.EDU Message-ID: <12269960022.10.BILLW@Score.Stanford.EDU> MINITAB.EXE seems to exist on various systems in quite diffeent versions. I have FTPed what appears to be the most recent (85) from LOTS, but wonder if this is legal - do we have a site license, or is each system licensed individually? (gee, such problems come up so seldomly in tops20 land....) BillW ------- 12-Jan-87 19:11:22-PST,695;000000000000 Return-Path: <@SUMEX-AIM.STANFORD.EDU:ROODE@BIONET> Received: from SUMEX-AIM.STANFORD.EDU by SU-SCORE.ARPA with TCP; Mon 12 Jan 87 19:09:15-PST Received: from BIONET by SUMEX-AIM.STANFORD.EDU with Cafard; Mon 12 Jan 87 17:27:33-PST Date: Mon 12 Jan 87 17:05:25-PST From: David Roode Subject: KPALVH BUGHLT's To: TOPS-20%BIONET@SUMEX-AIM.Stanford.EDU Phone: (415) 965-5585 Message-ID: <12270448261.51.ROODE@BIONET-20> I recall something that causes these to happen while a shutdown is pending, but I can't recall what. Can anyone out there refresh my memory? This happens in the last 10 minutes before the shutdown is set to occur. ------- 13-Jan-87 05:50:26-PST,1310;000000000000 Return-Path: Received: from R20.UTEXAS.EDU by SU-SCORE.ARPA with TCP; Tue 13 Jan 87 05:49:53-PST Date: Tue 13 Jan 87 07:53:29-CST From: Clifford A. Wilkes Subject: DECnet CTY output To: tops-20@SCORE.STANFORD.EDU Department: Computation Center - A20/R20 staff Message-ID: <12270588083.7.CC.WILKES@R20.UTEXAS.EDU> I need some help. Our other 20 has DECnet and only a 300-baud CTY. There are some 400 DECnet nodes that are defined at boot and the output to the CTY takes forever. It also wastes a lot of paper. I have tried everything I can think of to get the output to go to a file. My last attempt in our SYSTEM:DECNET.CMD file which is called from SYSTEM:SYSTEM.CMD used the following two lines. SET LOGGING FILE ALL SET LOGGING FILE SYSTEM:DECNET.LOG However, this did no good. It didn't even duplicate the output to the log file. We are currently running 6.1 with the DECnet routed over an NI. Could someone help? What am I not getting here? I've checked the DECnet manual and thought my last try would do it. Even speeding up the output with a 1200-baud CTY would be nicer but this billion-dollar university can't seem to scrape up the $200 or so necessary to buy one. Thanks. <@> ------- 13-Jan-87 06:06:33-PST,1311;000000000000 Return-Path: Received: from columbia.edu by SU-SCORE.ARPA with TCP; Tue 13 Jan 87 06:06:08-PST Received: from cunixc.columbia.edu by columbia.edu (5.54/1.14) id AA06697; Tue, 13 Jan 87 09:09:50 EST Message-Id: <8701131409.AA06697@columbia.edu> Received: by cunixc.columbia.edu (5.54/5.10) id AA04927; Tue, 13 Jan 87 09:09:08 EST Date: Tue, 13 Jan 87 09:09:08 EST From: Thomas De Bellis To: CC.Wilkes@r20.utexas.edu Cc: tops-20@SCORE.STANFORD.EDU In-Reply-To: Clifford A. Wilkes's message of Tue 13 Jan 87 07:53:29-CST Subject: Re: DECnet CTY output What kind of a Galaxy are you running? I ask this for two reasons. 1) If it isn't a vanilla 6.1 Galaxy, it may be that you are using an old QSRNET file which is still printing the topology change interrupts. If this is the case, you should either toss that old module or modify your Orion to be able to disable those messages. This is a trivial modification to make (I made it in 1983, I think). 2) Alternatively, you should check to make sure that the NCPTAB and related files that you link with your Orion are the same as what that crock NMLT20 wants. It may be that NMLT20 isn't able to understand what you are sending it. -- Tom 14-Jan-87 01:37:36-PST,676;000000000000 Return-Path: <@SUMEX-AIM.STANFORD.EDU:MRC@PANDA> Received: from SUMEX-AIM.STANFORD.EDU by SU-SCORE.ARPA with TCP; Wed 14 Jan 87 01:36:19-PST Received: from PANDA by SUMEX-AIM.STANFORD.EDU with Cafard; Wed 14 Jan 87 01:38:27-PST Date: Wed 14 Jan 87 01:23:06-PST From: Mark Crispin Subject: VAX prices To: : ; Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12270801005.7.MRC@PANDA> Midwest Systems is selling a VAX 11/730-CA (730 CPU, 2MB CMX-750 memory, TU58, DD11-DK, H9642-EC cabinet) for $1995. Be the first on your block to have your own toy computer! ------- 14-Jan-87 08:58:42-PST,1451;000000000000 Return-Path: Received: from WISCVM.WISC.EDU by SU-SCORE.ARPA with TCP; Wed 14 Jan 87 08:58:00-PST Received: from (SYSTEM)SITVXB.BITNET by WISCVM.WISC.EDU on 01/14/87 at 11:01:25 CST Date: Wed, 14 Jan 87 11:58:57 EST From: lmaltz(Leslie P Maltz)%sitvxb.BITNET@WISCVM.WISC.EDU Message-Id: <870114115857.00b@sitvxb> Subject: Software licensing To: info-vax@sri-kl.arpa , tops-20@su-score.arpa Recently a letter was mailed to all DECUS members to update everyone on the status of the DEC software license transfer issue. It contained a letter from C.W.Goldsmith, DECUS President, a response from Digital, and a postcard. In order to poll the user community in a meaningful manner, users are asked to respond to the two questions on the postcard (postage paid) as quickly as possible. The brief questionnaire is intended to provide DECUS (and DEC) with an indication of our level of acceptance of the announced policy. This is the only means available for polling the users since the policy is to begin on March 1st, which is prior to the next scheduled symposium. I urge you to respond right away so that we will have an opportunity to tabulate the responses and take appropriate action. Please share this message with other DECUS members at your site so that they will respond also. This issue is important to all of us. Leslie Maltz Chairperson, DECUS Large Systems SIG 15-Jan-87 21:39:17-PST,453;000000000000 Mail-From: G.EGK created at 15-Jan-87 21:37:53 Date: Thu 15 Jan 87 21:37:51-PST From: Edjik Subject: Native mode Ethernet To: tops-20@Score.Stanford.EDU Message-ID: <12271284289.19.G.EGK@Score.Stanford.EDU> Has anyone done any native mode Ethernet programming using the NIA-20? Are there any libraries for making Ethernet native mode connections laying arnd somewhere that anyone know of? tnx. --E+ ------- 19-Jan-87 10:07:04-PST,736;000000000000 Return-Path: Received: from TE.CC.CMU.EDU by SU-SCORE.ARPA with TCP; Mon 19 Jan 87 10:05:59-PST Date: Mon 19 Jan 87 13:09:16-EST From: David W. Mattis Subject: Talking to quasar To: tops-20@SCORE.STANFORD.EDU Message-ID: <12272207512.43.DM6Q@TE.CC.CMU.EDU> I am trying to write some code that send ipcf messages off to quasar to do some simple queue manipulation commands. I have found out that quasar wants something called a "request descriptor block" to provide information about most of these commands. I cannot figure out what the format of this bugger is. Can anyone out there point me in the right direction. Thanks, David W. Mattis ------- 19-Jan-87 18:49:27-PST,1704;000000000000 Return-Path: Received: from Sierra.Stanford.EDU by SU-SCORE.ARPA with TCP; Mon 19 Jan 87 18:48:43-PST Date: Mon 19 Jan 87 18:52:16-PST From: Stu Grossman Subject: Re: DECnet CTY output To: CC.Wilkes@R20.UTEXAS.EDU cc: tops-20@Score.Stanford.EDU In-Reply-To: <12270588083.7.CC.WILKES@R20.UTEXAS.EDU> Message-ID: <12272302720.14.GROSSMAN@Sierra.Stanford.EDU> The first things you should try should be see what options you have when you type DISABLE OUTPUT ? to OPR. One of them may disable the messages you are complaining about. Failing that, you could try DISABLE OUTPUT ALL. In any case, none of the above methods will really work all that well if you subsequently re-enable output. What will happen is that you will start getting responses to those SET NODE commands that were still pending to NMLT20 at the time that you re-enabled output. Ie: the sequence: OPR>DISABLE OUTPUT-DISPLAY ALL OPR>SET NODE 1 NAME FOO OPR>SET NODE 2 NAME BAR OPR>SET NODE ad nauseum... OPR>ENABLE OUTPUT-DISPLAY ALL will NOT properly suppress the ALL of the responses generated by the SET NODE commands. However, there may still be a solution... I beleive that there is a program on the DECnet tools tape called NODSET or SETNOD. This program will accept a file containing only a bunch of 'SET NODE number NAME name' commands, and will perform the same function that you would get by doing those commands in the NCP sub-mode of OPR. This program also runs pretty fast too, as it doesn't have the overhead of dealing with GALAXY and NMLT20 (and four IPCF packets per command!) Stu Grossman ------- 19-Jan-87 19:07:26-PST,1528;000000000000 Return-Path: Received: from Sierra.Stanford.EDU by SU-SCORE.ARPA with TCP; Mon 19 Jan 87 19:06:55-PST Date: Mon 19 Jan 87 19:10:15-PST From: Stu Grossman Subject: Re: DECnet CTY output To: sluggo%cunixc@COLUMBIA.EDU cc: CC.Wilkes@R20.UTEXAS.EDU, tops-20@Score.Stanford.EDU In-Reply-To: <8701131409.AA06697@columbia.edu> Message-ID: <12272305994.14.GROSSMAN@Sierra.Stanford.EDU> > 1) If it isn't a vanilla 6.1 Galaxy, it may be that you are using an > old QSRNET file which is still printing the topology change > interrupts. From the implications in his message, he is not getting topology change interrupts. He is getting swamped with responses to his SET NODE commands. > 2) Alternatively, you should check to make sure that the NCPTAB and > related files that you link with your Orion are the same as what > that crock NMLT20 wants. It may be that NMLT20 isn't able to > understand what you are sending it. 1) If you use the wrong NCPTAB with NMLT20, you get far stranger results than he is seeing, especially with the LOGGING class commands. NMLT20 will probably print diagnostics on the console complaining about format errors in ORION packets. 2) The commands under ENABLE/DISABLE OUTPUT are not even in NCPTAB, and never get within a mile of NMLT20. 3) If you think that NMLT20 is such a crock, then I eagerly await your suggestions for something better to replace it with. Stu Grossman ------- 20-Jan-87 08:14:12-PST,1573;000000000000 Return-Path: Received: from columbia.edu by SU-SCORE.ARPA with TCP; Tue 20 Jan 87 08:09:15-PST Received: from cunixc.columbia.edu by columbia.edu (5.54/1.14) id AA01381; Tue, 20 Jan 87 11:04:49 EST Message-Id: <8701201604.AA01381@columbia.edu> Received: by cunixc.columbia.edu (5.54/5.10) id AA07379; Tue, 20 Jan 87 11:05:28 EST Date: Tue, 20 Jan 87 11:05:28 EST From: Thomas De Bellis To: GROSSMAN@SIERRA.STANFORD.EDU Cc: CC.Wilkes@r20.utexas.edu, tops-20@su-score.arpa In-Reply-To: Stu Grossman's message of Mon 19 Jan 87 19:10:15-PST Subject: Re: DECnet CTY output Stu, I am pretty much aware of how messages are disabled--I rewrote part of that code in 1983 to be able to disable QSRADM topology change messages. Different versions of NCPTAB can cause NMLT20 to loop printing junk. Diagnostic messages??! Are you kidding? NMLT20's only diagnostic is to hang, exhaust DECnet resources and then snarf up the CPU. Differing versions of OPRCMD (where part of the disable stuff is) and incorrectly linked modules can also produce the effect of not being able to issue certain commands, such as a disable. Yes, I do think NMLT20 is a crock. Next to IBMSPL, it is the worst piece of junk that we've ever seen and we had to try very hard to get the sources out of DEC. It was such a mess that we actually did start writing one from scratch. That's a big job and we've never finished it. If you'd like some of the sources, I'll go see if I can find them. -- Tom 20-Jan-87 10:50:13-PST,850;000000000000 Return-Path: Received: from Sierra.Stanford.EDU by SU-SCORE.ARPA with TCP; Tue 20 Jan 87 10:48:54-PST Date: Tue 20 Jan 87 10:52:07-PST From: Stu Grossman Subject: Re: DECnet CTY output To: sluggo%cunixc@COLUMBIA.EDU cc: CC.Wilkes@R20.UTEXAS.EDU, tops-20@Score.Stanford.EDU In-Reply-To: <8701201604.AA01381@columbia.edu> Message-ID: <12272477455.43.GROSSMAN@Sierra.Stanford.EDU> Having spent a lot of time working on NMLT20 and NCPTAB while I was at DEC, I must admit that I never heard any complaints from anyone about some of the problems you mention. > Different versions of NCPTAB can cause NMLT20 to loop > printing junk. It sounds like you didn't follow the manufacturers installation instructions, and had a version skew between NMLT20 and NCPTAB. ------- 20-Jan-87 21:18:55-PST,749;000000000000 Return-Path: Received: from USC-ECL.ARPA by SU-SCORE.ARPA with TCP; Tue 20 Jan 87 21:17:47-PST Date: Tue 20 Jan 87 21:21:14-PST From: Bruce Tanner Subject: NI microcode To: Tops-20@SCORE.STANFORD.EDU Message-ID: <12272591983.24.CERRITOS@USC-ECL.ARPA> Since we're about to install a pair of NIA20's in a few weeks, I'd like to get the latest microcode file. I was told version 171 was the 'official' version at DECUS, but I haven't seen it yet. In a related topic, is there any way to raise DTR on a DECserver 200? I have Mark Crispin's MTOPR% patch, but that does a front end function, and I can't see how that would do anything for a non front end line. Thanks, -Bruce ------- 21-Jan-87 06:30:51-PST,869;000000000000 Return-Path: Received: from TOPS20.DEC.COM by SU-SCORE.ARPA with TCP; Wed 21 Jan 87 06:29:22-PST Date: 21 Jan 1987 0931-EST From: "Michael Raspuzzi" To: cerritos@usc-ecl.arpa cc: tops-20@score.stanford.edu Loc/MS: "MRO1-2/L14 (Pole M13)" Phone: "DTN 297-2346 (617-467-2346)" Quote: "Better be careful what you wish for, you may get it" Subject: Re: NI microcode Message-ID: <"MS11(6011)+GLXLIB5(0)" 12272692095.8.140.33898 at TOPS20.DEC.COM> Version 171 of the NI microcode is the latest and greatest. It has a fix in it that prevents KPALVH BUGHLTs. There was some kind of loop in the microcode that was hogging time on the E-bus that was causing this problem. I believe the "new" KNILDR.EXE will have this new version. I was told that it is shipped on some autopatch tape. Mike -------- 26-Jan-87 02:36:42-PST,1387;000000000000 Return-Path: Received: from bass.ARPA (NOSC.ARPA.#Internet) by SU-SCORE.ARPA with TCP; Mon 26 Jan 87 02:35:29-PST Received: by bass.ARPA (5.31/4.7) id AA23997; Mon, 26 Jan 87 02:39:02 PST Received: by humu.ARPA (5.31/4.7) id AA07464; Mon, 26 Jan 87 00:37:31-1000 Received: by uhmanoa.ICS.HAWAII.EDU (5.51/UUCP-Project/rel-1.0/11-09-86) id AA03763; Sun, 25 Jan 87 23:33:54-1000 Message-Id: <8701260933.AA03763@uhmanoa.ICS.HAWAII.EDU> Date: Sun, 25 Jan 87 23:23:26-1000 From: uhccux!uhmanoa!uhmanoa.ICS.HAWAII.EDU!jeff@nosc.ARPA (Jeffrey Blomberg) To: tops-20@score.stanford.edu Subject: Mailsystems Cc: jeff%nosc.arpa@nosc.ARPA We have implemented MM as our favored mailsystem on the -20. It appears that soon we will have to get the -20 to send mail to DECnet hosts which appear to only support mail-11. We can accomplish this by using DEC's new MS/MX system in parallel to MM/MMAILR. I am just curious to know if anyone has trained MM to talk mail-11 instead of SMTP to DECnet hosts running Ultrix or VMS? ---------------------------------------------------------------- Jeffrey Blomberg, University of Hawaii Computing Center (UHCC) UUCP: {ihnp4,seismo,ucbvax,dcdwest}!sdcsvax!nosc!uhccux!jeff ARPA: uhccux!jeff@nosc.ARPA Phone: (808) 948-7351 INTERNET: jeff@UHCC.HAWAII.EDU 26-Jan-87 15:38:49-PST,973;000000000000 Return-Path: <@SUMEX-AIM.STANFORD.EDU:MRC@PANDA> Received: from SUMEX-AIM.STANFORD.EDU by SU-SCORE.ARPA with TCP; Mon 26 Jan 87 15:35:57-PST Received: from PANDA by SUMEX-AIM.STANFORD.EDU with Cafard; Mon 26 Jan 87 15:40:06-PST Date: Mon 26 Jan 87 14:23:14-PST From: Mark Crispin Subject: Re: Mailsystems To: uhccux!jeff@NOSC.ARPA cc: tops-20@Score.Stanford.EDU In-Reply-To: <8701260933.AA03763@uhmanoa.ICS.HAWAII.EDU> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12274088751.9.MRC@PANDA> Jeff - A forthcoming version of MMailr will support MAIL-11. The code exists, it's just a matter of porting it to the current version of MMailr. Wesleyan distributes a VAX/VMS mail program which is compatible with MM using DECnet SMTP. You might want to consider that and abandon MAIL-11. MAIL-11 is trash of the lowest variety. -- Mark -- ------- 27-Jan-87 05:12:21-PST,1207;000000000000 Return-Path: <@Cs.Ucl.AC.UK,@dundee.ac.uk:Alan@dundee-tech.ac.uk> Received: from Cs.Ucl.AC.UK by SU-SCORE.ARPA with TCP; Tue 27 Jan 87 05:10:45-PST Received: from ucl-cs-vax1 by mv1.Cs.Ucl.AC.UK via Ethernet with SMTP id aa03759; 27 Jan 87 13:10 WET Received: from 44d.cs.ucl.ac.uk by vax1.Cs.Ucl.AC.UK with SMTP id aa04029; 27 Jan 87 13:07 GMT Received: from cs.ucl.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP id a000205; 27 Jan 87 13:07 GMT Via: DCT; by DUNDEE on Tuesday, 27-Jan-87 13:07:58-GMT Date: Tue 27 Jan 87 13:02:51-GMT From: Alan Greig Subject: Wordstar like editor To: tops-20@score.stanford.edu cc: alan%dundee-tech.ac.uk@Cs.Ucl.AC.UK Snail-Mail: Computer Centre / Dundee College of Tech / Dundee / Scotland Sender: Alan%dundee-tech.ac.uk@Cs.Ucl.AC.UK Does anyone know of a wordstar like editor written in C which can run under tops20 or vms/unix etc. Even if there isn't one would people be interested in it if there was one ? If there isn't one in C is there one in anything else ? Alan Greig Arpa: Alan%DCT@CS.UCL.AC.UK (Alan%DCT@UCL-CS.ARPA) Janet: Alan@UK.AC.DCT ------- 27-Jan-87 07:00:08-PST,1057;000000000000 Return-Path: Received: from R20.UTEXAS.EDU by SU-SCORE.ARPA with TCP; Tue 27 Jan 87 06:59:14-PST Date: Tue 27 Jan 87 09:04:35-CST From: Clifford A. Wilkes Subject: SETNOD, bleah! To: tops-20@SCORE.STANFORD.EDU Department: Computation Center - A20/R20 staff Message-ID: <12274271042.19.CC.WILKES@R20.UTEXAS.EDU> Well, after many (really a couple) recommendations I tried to use SETNOD to define our DECnet system and prevent all of the that tiresome output from clogging up our 300 baud CTY. Well, it got rid of the output to the CTY but didn't do much else. Unless there is a secret to doing this that I don't know it doesn't do didly. Since the documentation was sparse at best I could only try to define the system via the TAKE command. I couldn't find out how to make a binary file of definitions so unless some kind soul out there knows more and can direct me I'm going to abandon SETNOD and keep searching. Thanks in advance for any help forthcoming. <@> ------- 27-Jan-87 08:53:02-PST,873;000000000001 Return-Path: Received: from C.CS.CMU.EDU by SU-SCORE.ARPA with TCP; Tue 27 Jan 87 08:52:22-PST Received: ID ; Tue 27 Jan 87 11:55:47-EST Date: Tue 27 Jan 87 11:55:46-EST From: Vince.Fuller@C.CS.CMU.EDU Subject: TOPS-20 Domain Service To: TOPS-20@SCORE.STANFORD.EDU Message-ID: <12274291284.7.VAF@C.CS.CMU.EDU> With the recent issue of a DDN management bulletin, it would seem that people are starting to get serious about the long-delayed domain transition. I was wondering what the current status of the TOPS-20 domain system is... Does the resolver exist/work yet? How does it deal with non-fully-qualified domains, if at all? The last "official" release of the domain software that I saw (well over a year or so ago) doesn't support a resolver at all. Has this changed? Vince Fuller CMU-CSD Facilities ------- 27-Jan-87 09:58:22-PST,3583;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SU-SCORE.ARPA with TCP; Tue 27 Jan 87 09:55:13-PST Date: Tue, 27 Jan 1987 12:55 EST Message-ID: From: Rob Austein To: Vince.Fuller@C.CS.CMU.EDU Cc: TOPS-20@SCORE.STANFORD.EDU Subject: TOPS-20 Domain Service In-reply-to: Msg of 27 Jan 1987 11:55-EST from Vince.Fuller@C.CS.CMU.EDU Somehow I doubt Paul Mockapetris will answer this, so I will. There has -never- been an "official" release of the ISI TOPS-20 domain code, as far as I know. The version Vince is refering to is the V4 code that is running at the NIC as a root nameserver. Version 5 has been out for over a year. It does have a resolver. As released by ISI it has some major problems (crash and burn and maybe trash your filesystem in the process kind of problems). About a year ago I got a copy of this and made it run on XX; Stanford's 20s are now running essentially my version of the code. My version is somewhat more usable than ISI's (it no longer crashes XX, seldom crashes the Stanford machines, and will probably abort itself with a BUGCHK instead of scribbling on your bittable) but is still very fragile and I am probably the only person who can change anything in it with impunity. It also eats gross amounts of space (two sections of monitor address space) and more of the UPDL than it should (my fault, long story), and you have to reboot the machine to reload the database (this could be fixed with enough work). For the last half year I have been working on a new domain system for PDP-10s: I'm doing the TOPS-20 and ITS implementations, will be happy to give advice to anybody who wants to bring it up on TOPS-10, WAITS, whatever. The internal design is very different than the ISI code. The TOPS-20 user interface (the GTDOM% jsys) is the same as ISI's, except that I am defining a few more functions. The bulk of the code is written in C (using the Stanford/SRI KCC compiler); the monitor code will be quite minimal, and should not pose any particular problems for system reliability. Most of the code is done. How long it takes me to finish up depends on a number of external factors, but it should be in the beta-test stage by April if not before. At this point I am not doing anything with the ISI code anymore. The code is available (for a 5.4 monitor) from XX:*.*; if you want the 6.1 version, you can probabably get it from Stanford. Use at own risk. Try compiling the code before committing yourself to running it; attempting to compile it may change your mind. If you decide to go this path, you should also contact Paul Mockapetris; his version of the code has a better resolver but still has all the reliability problems I fixed. Good luck. The ISI code does not deal with names that aren't completely qualified, at all. The sollution here has been to teach the HSTNAM.MAC module (used in MM, MMAILR, TELNET, FTP, etc) how to look in both the host tables (via GTHST%) and the domain database (via GTDOM%). This has worked up until now, but with the aforementioned removal of all the non-domain nicknames we will be in the same hole as everybody else. My new code will attempt to deal with partially qualified names, probably using the method Mockapetris suggested on Namedroppers some time ago (q.v.). Hope this answers some of the questions without generating so many more that I spend the next three months answering mail instead of writing code. --Rob 27-Jan-87 12:56:59-PST,353;000000000000 Return-Path: Received: from R20.UTEXAS.EDU by SU-SCORE.ARPA with TCP; Tue 27 Jan 87 12:53:54-PST Date: Tue 27 Jan 87 14:58:46-CST From: G.ATTAYA@R20.UTEXAS.EDU Subject: modula-2 compiler To: tops-20@SCORE.STANFORD.EDU Message-ID: <12274335519.17.G.ATTAYA@R20.UTEXAS.EDU> does anyone know of one for tops-20? ------- 27-Jan-87 13:51:56-PST,1438;000000000000 Return-Path: Received: from bass.ARPA (NOSC.ARPA.#Internet) by SU-SCORE.ARPA with TCP; Tue 27 Jan 87 13:50:51-PST Received: by bass.ARPA (5.31/4.7) id AA14777; Tue, 27 Jan 87 13:55:14 PST Received: by humu.ARPA (5.31/4.7) id AA17832; Tue, 27 Jan 87 10:23:19-1000 Received: by uhmanoa.ICS.HAWAII.EDU (5.51/UUCP-Project/rel-1.0/11-09-86) id AA20965; Tue, 27 Jan 87 10:03:56-1000 Message-Id: <8701272003.AA20965@uhmanoa.ICS.HAWAII.EDU> Date: Tue, 27 Jan 87 09:54:04-1000 From: uhccux!uhmanoa!uhmanoa.ICS.HAWAII.EDU!jeff@nosc.ARPA (Jeffrey Blomberg) To: tops-20@score.stanford.edu Subject: DECnet node definitions. May I make a suggestion on the node definition problem. I assume that you are invoking OPR/NCP and TAKEing a file like NCP.CMD to define the nodes. Assuming at that phase in the system startup BATCON and NMLT20 are already running, perhaps you could create a NODES.CTL file in the OPERATOR directory and SUBMIT NODES.CTL during the system startup process to do the definitions in the background. This solution would prevent the output on the CTY. ---------------------------------------------------------------- Jeffrey Blomberg, University of Hawaii Computing Center (UHCC) UUCP: {ihnp4,seismo,ucbvax,dcdwest}!sdcsvax!nosc!uhccux!jeff ARPA: uhccux!jeff@nosc.ARPA Phone: (808) 948-7351 INTERNET: jeff@UHCC.HAWAII.EDU 27-Jan-87 17:32:09-PST,1058;000000000000 Return-Path: Received: from columbia.edu by SU-SCORE.ARPA with TCP; Tue 27 Jan 87 17:29:38-PST Received: by columbia.edu (5.54/1.14) id AA06821; Tue, 27 Jan 87 20:32:58 EST Date: Tue, 27 Jan 87 20:32:58 EST From: Chris Maio Message-Id: <8701280132.AA06821@columbia.edu> To: Vince.Fuller@c.cs.cmu.edu Cc: tops-20@score.stanford.edu Subject: Re: TOPS-20 Domain Service For those who aren't inclined to invest a lot of effort in putting the domain resolver into their monitors, and are mostly concerned about being able to send mail to hosts not listed in HOSTS.TXT, there is a relatively simple workaround. By adding a line to DOMAINS.TXT for each top-level domain, and making a minor change to MMAILR, you can arrange to have MMAILR forward mail to such hosts via some other host that does know how to use the domain name servers. The edit to MMAILR is simple; you just have to keep it from stripping off the top-level domain when it passes the address to the forwarding host. Chris 27-Jan-87 17:43:00-PST,1401;000000000000 Return-Path: Received: from bass.ARPA (NOSC.ARPA.#Internet) by SU-SCORE.ARPA with TCP; Tue 27 Jan 87 17:41:45-PST Received: by bass.ARPA (5.31/4.7) id AA16713; Tue, 27 Jan 87 17:43:54 PST Received: by humu.ARPA (5.31/4.7) id AA20838; Tue, 27 Jan 87 15:42:18-1000 Received: by uhmanoa.ICS.HAWAII.EDU (5.51/UUCP-Project/rel-1.0/11-09-86) id AA21142; Tue, 27 Jan 87 10:34:05-1000 Message-Id: <8701272034.AA21142@uhmanoa.ICS.HAWAII.EDU> Date: Tue, 27 Jan 87 10:22:35-1000 From: uhccux!uhmanoa!uhmanoa.ICS.HAWAII.EDU!jeff@nosc.ARPA (Jeffrey Blomberg) To: MRC%PANDA@SUMEX-AIM.Stanford.EDU, uhccux!jeff@nosc.ARPA Subject: Re: Mailsystems Cc: tops-20@Score.Stanford.EDU > A forthcoming version of MMailr will support MAIL-11. The >code exists, it's just a matter of porting it to the current >version of MMailr. I would be interested to know when the new version is available. > Wesleyan distributes a VAX/VMS mail program which is >compatible with MM using DECnet SMTP. You might want to >consider that and abandon MAIL-11. MAIL-11 is trash of the >lowest variety. We are looking into this package and TCP/IP for VMS also, but it will be difficult if not impossible to get all VMS sys admins to cooperate. I tend to concur with your opinion of mail-11, but will probably still need it. -jeff- 27-Jan-87 21:08:27-PST,984;000000000001 Return-Path: Received: from C.CS.CMU.EDU by SU-SCORE.ARPA with TCP; Tue 27 Jan 87 21:07:06-PST Received: ID ; Wed 28 Jan 87 00:11:00-EST Date: Wed 28 Jan 87 00:10:59-EST From: Vince.Fuller@C.CS.CMU.EDU Subject: Re: Mailsystems To: uhccux!uhmanoa!uhmanoa.ICS.HAWAII.EDU!jeff@NOSC.ARPA cc: uhccux!jeff@NOSC.ARPA, tops-20@SCORE.STANFORD.EDU In-Reply-To: <8701272034.AA21142@uhmanoa.ICS.HAWAII.EDU> Message-ID: <12274425126.7.VAF@C.CS.CMU.EDU> If you are an educational, non-profit institution, it should be fairly easy to get some VMS TCP/IP up and running - Tektronix offers a package free to Universities that we at CMU have gotten into a functional state. See the INFO-VAX or TEKTCP mailing list for details. From personal experience, I can tell you that using MAIL-11 between your 20's and VAXes is not the way to go - we had such a setup here years ago and it never really worked. Vince Fuller, CMU-CSD Facilities ------- 28-Jan-87 17:24:45-PST,1054;000000000000 Mail-From: BILLW created at 28-Jan-87 17:13:33 Date: Wed 28 Jan 87 17:13:32-PST From: William "Chops" Westfield Subject: tops20 domain service... To: tops20@Score.Stanford.EDU Message-ID: <12274644043.37.BILLW@Score.Stanford.EDU> It is also possible to run the isi domain resolver in user mode. (I have done this to the latest version on one host). This way you get the advantages of domains (?), but don't have to worry as much about it trashing your system. It does have the disadvantage that it seems to hang up a lot (probaby due to things being interupted in a state where the code would have been noint if it had been in the monitor), but fixing this is just a matter of restarting jeeves, rather than restarting the whole system. This is a good way to experiment with domains... The stanford HSTNAM lets you supply one hardwired default domain, eg if you type FOO, it looks up FOO.STANFORD.EDU. The old style host table can be tried either before or after the domain attempt. BillW ------- 1-Feb-87 23:47:48-PST,560;000000000001 Return-Path: Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Sun 1 Feb 87 23:40:59-PST Date: Sun 1 Feb 87 23:45:13-PST From: Mark Lottor Subject: fdb changes To: tops-20@SCORE.STANFORD.EDU Message-ID: <12275763922.20.MKL@SRI-NIC.ARPA> If you change the protection of a file, nothing else in the FDB changes, particularly any dates. I assume then that the file won't be backed up. Is this really true? Shouldn't a change like this cause the file to be dumped on the next incremental? Mark ------- 3-Feb-87 17:26:41-PST,1379;000000000000 Return-Path: Received: from lindy.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Tue 3 Feb 87 17:25:32-PST Received: by lindy.STANFORD.EDU; Tue, 3 Feb 87 15:29:04 PST Date: Tue, 3 Feb 87 15:30:36 PST From: Reply-To: RFORSTER%UNCAEDU.BITNET@forsythe.stanford.edu To: tops-20@score.stanford.edu Subject: BITnet to DECnet and vise versa Date: Tue, 3 Feb 87 15:33 MST From: Subject: BITnet to DECnet and vise versa To: tops-20@score.stanford.edu X-Original-To: tops-20@score.stanford.edu, RFORSTER We are currnetly in the process of tring to to find a (or write) gateway between DECnet -> BITnet and vise versa. It is to be used on a VMS machine that currently has JNET and gMAIL. We are also looking for a real SMTP server on a VMS machine to talk to the MM subsystem on the 20 side and mail the message to the VMSmail system (such as it is) We are also looking for documentation of the mail/protacal= command on VMS. If anyone can help with any of the above, we would be most greatful. /Russ BITnet: RForster@uncaedu.bitnet "You can do anything you want with TECO and DDT" (as sung to ALICE's Restaraunt) 4-Feb-87 15:32:33-PST,1422;000000000000 Return-Path: Received: from lindy.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Wed 4 Feb 87 15:02:59-PST Received: by lindy.STANFORD.EDU; Wed, 4 Feb 87 15:05:59 PST Date: Wed, 4 Feb 87 15:07:24 PST From: Reply-To: RFORSTER%UNCAEDU.BITNET@forsythe.stanford.edu To: tops-20@score.stanford.edu Subject: LGOUT% not honering ACJ denials Date: Wed, 4 Feb 87 12:51 MST From: Subject: LGOUT% not honering ACJ denials To: tops-20@score.stanford.edu X-Original-To: tops-20@score.stanford.edu, RFORSTER LGOUT% does not honor ACJ denials. Quite by accident we found out that ACJ denials were not being honored at logout time (we deny users from logging out when over perm quota). I know this worked under 5.1, however in looking at the code I cannot see any difference. TSC and I have figured out a hack for honoring the ACJ denial. $Get Monitr.Exe $Start 140 lgogok+15/ JRST SERPOF+33 jrst mretne ~Z $save Monitr.Exe From what information I got from TSC, it appears that this hack sits right in the middle if the GETOK macro. If someone else has another way to have LGOUT% honor ACJ's requests I'd be interested in hearing from you. /Russ 4-Feb-87 18:40:11-PST,986;000000000000 Return-Path: Received: from KSL-1186-4.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 4 Feb 87 18:20:28-PST Date: Wed, 4 Feb 87 18:23:48 PST From: Mark Crispin Subject: Symbolics raises price of MACSYMA by 1500% To: SU-etc@SUMEX-AIM.Stanford.EDU,TOPS-20@Score.Stanford.EDU According to the latest issue of the DEC Professional, Symbolics is now selling MACSYMA for the SUN 2, SUN 3, and MicroVAX for the low price of $7500 in quantities of 1. The last time Symbolics offered MACSYMA for the DECSYSTEM-20, they only wanted $500. So, in other words, if you had a DEC-20 with 20 users running MACSYMA at any one time and wanted to migrate those users onto a SUN, you'll end up paying $150,000 for software licenses to replace your $500 software... (to be fair, they probably do discount for volume purchases). Let's hear again about how much cheaper it would be to buy a whole bunch of SUNs... 6-Feb-87 22:52:44-PST,1326;000000000000 Return-Path: Received: from seismo.CSS.GOV by SCORE.STANFORD.EDU with TCP; Fri 6 Feb 87 22:50:00-PST Received: from munnari.oz by seismo.CSS.GOV (5.54/1.14) with UUCP id AA10734; Fri, 6 Feb 87 23:50:04 EST Message-Id: <8702070450.AA10734@seismo.CSS.GOV> Received: from neumann by munnari with SunIII (5.5) id AA18193; Sat, 7 Feb 87 13:53:41 EST Received: by neumann.une.oz (4.12/4.7) id AA11516; Sat, 7 Feb 87 13:43:06 est Date: Sat, 7 Feb 87 13:43:06 est From: munnari!neumann.une.oz!gordon@seismo.CSS.GOV (Gordon Smith [Computer Centre]) To: tops20@score.stanford.edu Subject: Mail routing... We've just installed v6.1 (no we don't have the official DEC release yet) on both our -20's, brushed the dust off the NIA20's, plugged them into the DELNI and installed PSI on the MicroVAX II. Now... I'd like to be able to have some users on the -20's send mail out on PSImail through the VAX. The reverse works fine - I can send mail out from the VAX via PSI back into the VAX then routed to a -20. Are there any tricks (or software) I'm missing to route through the VAX and out using PSImail? Gordon Smith. Computer Centre, University of New England, Armidale, Australia. P.S. Thanks for letting Australia borrow that CUP for the last three years. 7-Feb-87 15:41:46-PST,1884;000000000000 Return-Path: Received: from lindy.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Sat 7 Feb 87 15:37:38-PST Received: by lindy.STANFORD.EDU; Sat, 7 Feb 87 15:36:32 PST Date: Sat, 7 Feb 87 15:35:18 PST From: Reply-To: RFORSTER%UNCAEDU.BITNET@forsythe.stanford.edu To: tops20@score.stanford.edu Subject: Re: Mail routing... Date: Sat, 7 Feb 87 11:50 MST From: Subject: Re: Mail routing... To: tops20@score.stanford.edu X-Original-To: tops20@score.stanford.edu Gordon Smith of Computer Centre, University of New England, Armidale, Australia. Writes... >We've just installed v6.1 (no we don't have the official DEC release yet) >on both our -20's, brushed the dust off the NIA20's, plugged them into >the DELNI and installed PSI on the MicroVAX II. > >Now... I'd like to be able to have some users on the -20's send mail >out on PSImail through the VAX. The reverse works fine - I can send mail >out from the VAX via PSI back into the VAX then routed to a -20. > >Are there any tricks (or software) I'm missing to route through the >VAX and out using PSImail? > If you also have MS v11 (and heaven help you if you do), you can send mail to a PSI address from the -20's. What you do is define an alias in your MS.Init file with the following format: DEFINE ALIAS alias-name "psi%dte-addr::username"@vax-host We use this quite sucsessfully. There is one problem though, MS connot reply to the message comming from PSI. You can forwrd and send just fine though. I hope this helps. /Russ BITnet: RForster@uncaedu.BITnet >P.S. Thanks for letting Australia borrow that CUP for the last three years. Your welcome. 9-Feb-87 11:40:26-PST,1919;000000000000 Return-Path: Received: from MCC.COM by SCORE.STANFORD.EDU with TCP; Mon 9 Feb 87 11:36:42-PST Date: Mon 9 Feb 87 13:37:45-CST From: Clive Dawson Subject: Re: MACSYMA on SUN's To: tops20@SCORE.STANFORD.EDU Message-ID: <12277728643.61.AI.CLIVE@MCC.COM> Here's a bit of extra info regarding the message Mark posted a few days ago. What Symbolics would probably not like people to find out about is that MACSYMA is available from other sources for a fraction of the price. This all came about, as I understand it, from the fact that the original version of MACSYMA at MIT was developed with government money, and the government at some point insisted on receiving full sources for the software. It is now available from DOE. Here's a message from Bill Schelter, who ported MACSYMA to various systems: Date: Mon 9 Feb 87 09:27:31-CST From: Bill Schelter Subject: Re: Random message found on the net... There are a number of versions of Doe-Macsyma available from NESC (National Energy Software Center) Argonne National Laboratory, 9700 Cass Ave, Argonne IL 60439. Any site may obtain a license for all machines at a given site. The cost for the whole site is around $550 for educational sites, and about $1300 for commercial sites. The rates may be lower than this if you are a member of NESC, but joining is not necessary. It is fairly complete system. There are versions for Vax Vms (under NIL), TI Explorer and Symbolics 36xx (under common lisp), LMI version, and I believe there is one for unix 4.2 (under public franz) There may be other versions of which I am not aware. All versions come with complete sources to rebuild the system. I am responsible for the Explorer and Symbolics version. Bugs for it should go to atp.schelter@r20.utexas.edu Bill Schelter ------- ------- 9-Feb-87 13:09:45-PST,1072;000000000000 Return-Path: Received: from lindy.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Mon 9 Feb 87 13:07:52-PST Received: by lindy.STANFORD.EDU; Mon, 9 Feb 87 13:06:56 PST Date: Mon, 9 Feb 87 13:08:55 PST From: Reply-To: RFORSTER%UNCAEDU.BITNET@forsythe.stanford.edu To: tops20@score.stanford.edu Subject: Re: Mail routing... Date: Mon, 9 Feb 87 13:37 MST From: Subject: Re: Mail routing... To: tops20@score.stanford.edu X-Original-To: tops20@score.stanford.edu, RFORSTER It appears that in my previous respone to sending mail from a -20 to a vax with PSI was incomplete. In oder for that procedure to work you must also create a file in UPS: called DNHOST.TXT and insert file following line. vax-host/Strip-Quotes The Strip-Quotes switch is an undocumemted feature of MX. Sorry for the incomplete response. /Russ BITnet: RForster@UNCAEDU.BITnet 9-Feb-87 15:39:09-PST,1192;000000000000 Return-Path: Received: from bass.ARPA (NOSC.ARPA.#Internet) by SCORE.STANFORD.EDU with TCP; Mon 9 Feb 87 15:38:11-PST Received: by bass.ARPA (5.31/4.7) id AA06529; Mon, 9 Feb 87 15:38:26 PST Received: by humu.ARPA (5.31/4.7) id AA05963; Mon, 9 Feb 87 13:36:34-1000 Received: by uhmanoa.ICS.HAWAII.EDU (5.51/UUCP-Project/rel-1.0/11-09-86) id AA19108; Mon, 9 Feb 87 13:33:58-1000 Message-Id: <8702092333.AA19108@uhmanoa.ICS.HAWAII.EDU> Date: Mon, 9 Feb 87 13:16:48-1000 From: uhccux!uhmanoa!uhmanoa.ICS.HAWAII.EDU!jeff@nosc.ARPA (Jeffrey Blomberg) To: tops-20@SCORE.STANFORD.EDU Subject: TeX I am sure this question has been asked before, but I am fairly new to the Tops-20 mailing list. I have been informed that there is a version of TeX available for TOPS-20. If this is the case, would someone be willing to point me in the right direction - I have a faculty member who is sure that there is a public domain version around, but this is not a must. One other point worth mentioning. It would be best if this TeX package could generate postscript output for ease of use via LPTSPL. Aloha. -jeff- 9-Feb-87 21:56:43-PST,2304;000000000000 Return-Path: Received: from GSB-HOW.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 9 Feb 87 21:51:15-PST Date: Mon 9 Feb 87 21:46:29-PST From: Eric M. Berg Subject: Re: TeX To: uhccux!uhmanoa!uhmanoa.ICS.HAWAII.EDU!jeff@NOSC.MIL cc: tops-20@Score.Stanford.EDU In-Reply-To: <8702092333.AA19108@uhmanoa.ICS.HAWAII.EDU> Phone-#s: (415)723-1576 (GSB-CF), (415)329-9940 (home) Message-ID: <12277839458.135.A.ERIC@GSB-HOW.Stanford.EDU> Yes, "there is a version of TeX available for TOPS-20". TeX was developed on a TOPS-10 system (SU-AI), and much additional work was done on a TOPS-20 system (SU-Score.ARPA). As your message suggested, it's in the public domain. (TeX itself is completely in the public domain, although certain implementations of it, mostly for micro-computers, are not.) The preferred way of obtaining Tex is to order a TOPS-20 distribution tape from Maria Code, Data Processing Services 1371 Sydney Drive Sunnyvale, CA 94087 You'll want the TOPS-20 tape, and then either the 200/240 dpi or 300 dpi FONT tape, depending on the resolution of your printer. The TOPS-20 tape includes sources and .EXE files for TeX, METAFONT, and associated programs, as well LaTeX; the font tape includes the CM fonts (METAFONT sources and .GF files). The two tapes together will cost you $164, plus $4 shipping. Maria Code also can provide you with manuals & other documentation; you might want to write them for a price-list. "Device driver" programs (programs which convert .DVI files output by TeX into a form capable of being printed on a specific printer) are generally not included on the Maria Code tapes. There is a public-domain .DVI to PostScript program (called DVI2PS) which was written for Unix systems and recently ported to TOPS-20 at Stanford. (You can send mail to BillW@Score.Stanford.Edu to get more information.) There are other device drivers for Imagen printers, DEC LN03s, etc., etc. You probably want to ask to be added to the TeXhax mailing list (send mail to TEXHAX-REQUEST@Score.Stanford.Edu), and to join the TeX Users Group and the The TUGboat (their newsletter). The address for the TeX Users Group is P. O. Box 9506, Providence, RI, 02940. ------- 10-Feb-87 09:55:21-PST,1778;000000000000 Return-Path: Received: from seismo.CSS.GOV by SCORE.STANFORD.EDU with TCP; Tue 10 Feb 87 09:45:13-PST Received: from enea.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP id AA04226; Tue, 10 Feb 87 11:44:04 EST Received: by enea.UUCP (5.51/UUCP-Project/rel-1.0/1.15) id AA04721; Tue, 10 Feb 87 17:03:50 +0100 (MET) Received: from majestix.ida.liu.se by liuida.UUCP; Tue, 10 Feb 87 15:59:08 +0100 Received: from LISBET by majestix.ida.liu.se; Tue, 10 Feb 87 15:59:01 +0100 Date: Tue 10 Feb 87 15:55:40 From: Lennart Lovstrand Subject: Re: Mailsystems To: jeff@uhmanoa.ics.hawaii.edu Cc: TOPS-20@score.stanford.edu In-Reply-To: <8701272034.AA21142@uhmanoa.ICS.HAWAII.EDU> Organization: Dept of Comp and Info Science, Univ of Linkoping, Sweden Message-Id: <6NQUWOL.11.L-LOVSTRAND@LISBET> Jeff, I have sent Mark a REDIT file containing modifications to MMailr (v503) which will allow it to communicate to VAXen using Mail-11. The code has been used on various sites in Sweden for about a year and seems to be pretty reliable. I'd prefer if you got it from Mark, but I can send you a copy as well if you're desperate. Included is some code which makes it easy to utilize VMS Foreign Protocols as well (eg. PSI). Sorry not to have any Mail-11 Listener for you. You'll still have to use VMAIL or MX for that. --Lennart ------- Dept of Computer and Information Science, University of Linkoping, Sweden UUCP: {seismo,mcvax}!enea!liuida!lel EARN/BITNET: LEL@SELIUI51 ARPA: lel%ida.liu.se@seismo.CSS.GOV EAN/X.400: lel@ida.liu.sunet SUNET-bis: L-LOVSTRAND@LISBET PSI/X.25: PSI%240200100403::LEL ------- 10-Feb-87 12:24:13-PST,1778;000000000000 Return-Path: Received: from seismo.CSS.GOV by SCORE.STANFORD.EDU with TCP; Tue 10 Feb 87 12:22:53-PST Received: from enea.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP id AA04226; Tue, 10 Feb 87 11:44:04 EST Received: by enea.UUCP (5.51/UUCP-Project/rel-1.0/1.15) id AA04721; Tue, 10 Feb 87 17:03:50 +0100 (MET) Received: from majestix.ida.liu.se by liuida.UUCP; Tue, 10 Feb 87 15:59:08 +0100 Received: from LISBET by majestix.ida.liu.se; Tue, 10 Feb 87 15:59:01 +0100 Date: Tue 10 Feb 87 15:55:40 From: Lennart Lovstrand Subject: Re: Mailsystems To: jeff@uhmanoa.ics.hawaii.edu Cc: TOPS-20@score.stanford.edu In-Reply-To: <8701272034.AA21142@uhmanoa.ICS.HAWAII.EDU> Organization: Dept of Comp and Info Science, Univ of Linkoping, Sweden Message-Id: <6NQUWOL.11.L-LOVSTRAND@LISBET> Jeff, I have sent Mark a REDIT file containing modifications to MMailr (v503) which will allow it to communicate to VAXen using Mail-11. The code has been used on various sites in Sweden for about a year and seems to be pretty reliable. I'd prefer if you got it from Mark, but I can send you a copy as well if you're desperate. Included is some code which makes it easy to utilize VMS Foreign Protocols as well (eg. PSI). Sorry not to have any Mail-11 Listener for you. You'll still have to use VMAIL or MX for that. --Lennart ------- Dept of Computer and Information Science, University of Linkoping, Sweden UUCP: {seismo,mcvax}!enea!liuida!lel EARN/BITNET: LEL@SELIUI51 ARPA: lel%ida.liu.se@seismo.CSS.GOV EAN/X.400: lel@ida.liu.sunet SUNET-bis: L-LOVSTRAND@LISBET PSI/X.25: PSI%240200100403::LEL ------- 12-Feb-87 15:30:55-PST,1011;000000000000 Return-Path: Received: from KSL-1186-4.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 12 Feb 87 15:27:12-PST Date: Thu, 12 Feb 87 15:26:36 PST From: Mark Crispin Subject: surplus 20 stuff for sale To: TOPS-20@Score.Stanford.EDU Message-ID: <570139948.A0058.KSL-1186-4.Crispin@SUMEX-AIM.Stanford.EDU> Stanford Surplus Property Sales (415 723-3001) is selling some old DEC-20 hardware. From what I can tell, this stuff came from the NOSC system that was donated to Stanford (and is now Sushi.Stanford.EDU) but was never actually put into service at Stanford. Everything is as-is, where-is, best bid gets it. You can buy individual pieces. Item # Description Quantity S-0827-01 Ampex ARM20 memory THREE S-0827-03 DEC TU45 tape drives TWO S-0827-04 DEC MB20 core memory ONE They also have two Ampex 200MB disc drives that used to be part of the SAIL system (S-0827-02) and four Alto II workstations (S-0827-05). 14-Feb-87 10:50:16-PST,973;000000000000 Return-Path: Received: from RELAY.CS.NET by SCORE.STANFORD.EDU with TCP; Sat 14 Feb 87 10:48:15-PST Received: from relay2.cs.net by RELAY.CS.NET id ae01875; 14 Feb 87 13:35 EST Received: from uchicago by RELAY.CS.NET id bl01883; 14 Feb 87 13:31 EST Received: by gargoyle.UChicago (5.51/4.7) id AA00191; Fri, 13 Feb 87 13:19:10 CST Received: from localhost.ARPA by anubis.UChicago (4.12/4.7) id AA05875; Fri, 13 Feb 87 11:59:18 cst Message-Id: <8702131759.AA05875@anubis.UChicago> To: Mark Crispin Cc: TOPS-20@SCORE.STANFORD.EDU Subject: Re: surplus 20 stuff for sale In-Reply-To: Your message of Thu, 12 Feb 87 15:26:36 PST. <570139948.A0058.KSL-1186-4.Crispin@SUMEX-AIM.Stanford.EDU> Date: 13 Feb 87 11:59:13 CST (Fri) From: nugent%anubis.uchicago.csnet@RELAY.CS.NET They are going to have to pay someone a lot of money to take a TU45 tape drive! Todd 14-Feb-87 13:38:03-PST,944;000000000000 Return-Path: <@SUMEX-AIM.STANFORD.EDU:MRC@PANDA> Received: from SUMEX-AIM.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Sat 14 Feb 87 13:36:26-PST Received: from PANDA by SUMEX-AIM.STANFORD.EDU with Cafard; Sat 14 Feb 87 13:35:18-PST Date: Sat 14 Feb 87 12:51:33-PST From: Mark Crispin Subject: Re: surplus 20 stuff for sale To: nugent%anubis.uchicago.csnet@CSNET-RELAY.ARPA cc: Crispin@SUMEX-AIM.Stanford.EDU, TOPS-20@Score.Stanford.EDU In-Reply-To: <8702131759.AA05875@anubis.UChicago> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12279052799.8.MRC@PANDA> Actually, if you have a 2020, your choice is between a TU45 and a TU77. A TU77 consumes a good deal more power and generates more heat. You also are into serious maintenance! I paid $150 for my two spare TU45's; quite a bit cheaper than a spare/replacement TU77... ------- 14-Feb-87 20:34:45-PST,3830;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SCORE.STANFORD.EDU with TCP; Sat 14 Feb 87 20:32:16-PST Date: Sat, 14 Feb 1987 21:32 MST Message-ID: From: WANCHO@SIMTEL20.ARPA To: TOPS20@SCORE.STANFORD.EDU Subject: Mailing list queues and Return-Path: Solution About a week ago, our mail queue started growing out of all reasonable bounds of expectation. This was compounded by the fact that we run a five-day timeout instead of three to cover long weekends, and no daily notices - just failure returns. At one point, there were close to 700 messages sitting in the retransmit queue, taking up over 5,500 disk pages. Almost all of the requeued files were for hosts on the ARPANET side, and many of those hosts I knew were up. Note that we are *still* a 512KW 2040, can't run 6.1, and can't run TCP in Queue 0. That really isn't all of the problem - we just can't get there from here - the so-called mail gateway hosts are congested, and so is the net on both sides. One gateway is down and is being replaced by a BBN Butterfly. But that is still being debugged and won't be online for a while. Meanwhile, the mail *must* go through - our paying customers expect and sometimes demand that service. My first attempt to relieve the backlog was to start two more MMAILRs, thinking that the increased frequency of attempts would eventually succeed and reduce the queue. Unfortunately, all they did was trail behind each other, attempting connections to the same hosts, and failing. There's no "easy" way to get an MMAILR to start processing the retransmit queue somewhere in the middle. But that's besides the point. The longer the queue, the longer the scan cycle. The longer the scan cycle, the less of a chance to get to the regular mail buried in the middle and tail end of the queue. Thus, new regular mail in the retransmit queue was never reached, much less delivered in a timely manner. It took me a couple of days, watching the lack of progress in these MMAILRs and a couple of user complaints to arrive at that conclusion, which is so obvious by now. So, I stopped all three MMAILRs, rerouted mailing list mail to mail files, and moved the entire retransmit queue to another directory, and restarted the regular MMAILR. I moved all mailing list mail back into MAILQ: under another nameset (...REDIST-... instead of ...QUEUED-...), and created and started another version of MMAILR to handle files with that nameset. I did likewise for our Archive Server reply messages, putting them in their own queue nameset, separate from the other two queues. The handful of regular mail left over was move back as-was. Now, with the queues separated, the next logical step in handling mailing list mail came easy: just redirect the mail to a Special Network host address, which ends up as separate message files in a specially named directory. Then, run a self-perpetuating batch job which requeues each message file to the REDIST queue, and, in the process, insert the appropriate RETURN-PATH:listname-REQUEST line in the new envelope. I wrote the program in C, fully documented with the details of this approach. MRC will soon be releasing this program, either as-is, or converted to MACRO, as part of the MM/MMAILR distribution. There are a number of other possibilities to consider with this scheme. One is to further reduce the queue size by writing a batch program which when periodically run, say weekly, digestifies groups of messages to the same address and sends the result to the mailing list queue... This is quite easy to do by building an envelope program which feeds the result to one of the existing digestify programs, such as the one from Rutgers... --Frank 16-Feb-87 10:07:15-PST,1076;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SCORE.STANFORD.EDU with TCP; Mon 16 Feb 87 10:06:09-PST Date: Mon, 16 Feb 1987 11:07 MST Message-ID: From: WANCHO@SIMTEL20.ARPA To: TOPS-20@SCORE.STANFORD.EDU Subject: Is your system about to be "excessed"? We are looking to upgrade this system and I'm required to check the Excess Property Lists of goverment owned equipment before proceeding further. I have done that. However, the list does not show equipment which is about to be excessed. If you have or know of such a system which will be placed on excess in the next four to six months or so, please let me know. I am interested in the following government owned equipment only: MCA25-AA out of a DECSYSTEM-2065 4MW MG-20 out of any DECSYSTEM-20 2 RH20s 2 RP07AAs If you know of any piece(s), such as some of the memory, but not all 4MW, or one RP07AA, that will help. Please contact by net mail with the name and phone number(s) of the person to contact. Thanks, Frank 19-Feb-87 18:43:13-PST,1331;000000000000 Return-Path: Received: from KSL-1186-4.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 19 Feb 87 18:40:41-PST Date: Thu, 19 Feb 87 18:40:30 PST From: Mark Crispin Subject: found on an MIT ITS system To: TOPS-20@Score.Stanford.EDU Message-ID: <570756382.A0089.KSL-1186-4.Crispin@SUMEX-AIM.Stanford.EDU> VAXOLOGY There is a computer named VAX, Which is totally loaded with hacks, But the real piece of crap Is the overflow trap, Which an old-PC register lacks. It's got byte-string instructions galore, But the packed decimal format is poor, And the halfword length means That it isn't worth beans, Just like the 360's of yore. Oh, the branch mnemonics are losing, And the right to left numbers confusing, But the thing that's a pain, An efficiency drain, Is the miniscule page size they're using. Well, they give you lots of good stuff, And the address space size is enough, But you can't do an "exch", And it makes you say "bletch", When you see all the RSX cruft. I'm not sure who wrote this; I suspect it was Dave Moon. Anyway, at least it's some entertainment to those 10/20 folks who are in the throes of "integrating." The file, by the way, is on AI.AI.MIT.EDU as HUMOR;.VAX BUGS 21-Feb-87 00:13:34-PST,1204;000000000000 Return-Path: <@SUMEX-AIM.STANFORD.EDU:MRC@PANDA> Received: from SUMEX-AIM.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Fri 20 Feb 87 23:28:39-PST Received: from PANDA by SUMEX-AIM.STANFORD.EDU with Cafard; Fri 20 Feb 87 23:28:29-PST Date: Fri 20 Feb 87 22:12:41-PST From: Mark Crispin Subject: and it isn't even 1988 yet! To: TOPS-20@Score.Stanford.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12280727813.7.MRC@PANDA> Remember when Jupiter was cancelled, back in '83, they said we would have 5 more years of development on TOPS-20? Well, read the answer to SPR 20-21468 in the 15 January 1987 Software Dispatch. Joe Payne of 3M asked that the EXEC be taught about EDT's switches in the EDIT command, since it already knew about SED's and EDIT's switches. DEC's answer: "at this time, we do not intend to add the functionality in question...possible inclusion...should the resources to do so become available." Well, since development has ended at least a year early, let's hop to it and get more pressure going on DEC to put TOPS in the public domain... ------- 23-Feb-87 15:05:09-PST,1643;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SCORE.STANFORD.EDU with TCP; Mon 23 Feb 87 15:02:11-PST Date: Mon 23 Feb 87 18:03:55-EST From: Thomas De Bellis Subject: LPTSPL question To: Tops-20@SCORE.STANFORD.EDU Message-ID: <12281436190.22.SY.SLOGIN@CU20B.COLUMBIA.EDU> Recently I've been grumphed at by a number of people who have been trying to use the EXEC print/begin: option. For example, we have a printer on campus that is restricted to a per job page limit maximum of 20 pages. A user had a 30 (printed) page file, issued a print request with a /begin:20 switch and expected to see more or less 10 pages come out. This sounds reasonable to me. Nothing came out because LPTSPL still does accounting for the 20 pages. As soon as he went past page 20 and tried to print, he got kicked out. In other words, LPTSPL is doing accounting for pages that are not physically printed. It strikes me as rather silly to bill for output that isn't generated. So, I've been thinking of making the /begin: code in LPTSPL subtract the number of pages to be printed from J$APRT. It doesn't appear to be straightforward to make this happen correctly in the forward spacing code or make CNTDWN respect all this. For example, what would I do if the total number of pages printed remained negative? Not, print anything? Change the sign of the result? (Tee hee..) If anyone has done it, I'd like to hear from you. Opinions are welcome, also. Otherwise I'll roll up my sleeves and do it myself (sigh). -- Tom ------- 23-Feb-87 17:41:36-PST,1855;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 23 Feb 87 17:39:50-PST Received: from KSL-1186-4.Stanford.EDU by SUMEX-AIM.STANFORD.EDU with TCP; Mon 23 Feb 87 17:32:12-PST Date: Mon, 23 Feb 87 17:27:40 PST From: Mark Crispin Subject: bug in GTHST% JSYS To: TOPS-20 hackers Message-ID: <571097612.A0025.KSL-1186-4.crispin@SUMEX-AIM.Stanford.EDU> This bugfix should be considered a MUST INSTALL for all TCP/IP sites running with multiple interfaces. I wrote the original code, so I know what I'm talking about. I would appreciate an acknowledgement from DEC that it has been TCO'd into DEC's TCP/IP-20 product. Problem: Stange behavior in mailsystem, with valid mailing lists rejected as "No such directory name" Diagnosis: MMailbox fails to recognize that an address is local, and doesn't recurse on it during mailing list expansion. This is caused by the monitor being confused when the default address occurs after the preferred address in the host table. GTHST% always returns the preferred address when the local host (-1) is given as a host argument. An erroneous test is made that allows the default address to supercede the preferred address in this case. Solution: In MNETDV.MAC, at HSTI13+6, delete the two lines: CAMN T1,DEFADR ;OUR DEFAULT ADDRESS IS ALWAYS BEST JRST HSTI15 ;SO SET IT AS BEST UNCONDITIONALLY You may also want to change the comments on the next two lines to be: CAMN T1,PRFADR ;OUR PREFERRED ADDRESS IS ALWAYS BEST JRST HSTI15 ;SO SET IT AS BEST UNCONDITIONALLY That is, the fix is only to allow the ***PREFERRED*** address to be unconditionally selected as the best address. -- Mark -- 24-Feb-87 12:58:22-PST,1347;000000000000 Return-Path: Received: from TE.CC.CMU.EDU by SCORE.STANFORD.EDU with TCP; Tue 24 Feb 87 12:54:18-PST Date: Tue 24 Feb 87 15:51:22-EST From: C. P. Yeske Subject: RP07 from VMS to TOPS and back. To: info-vax@SRI-KL.ARPA, tops-20@SCORE.STANFORD.EDU Home-Phone: (412)422-4667 (422-GOOP, -IONS, -HOOP) Office: UCC A72 x2647 Organization: Carnegie Mellon Computing Center, Hardware Systems Staff-Assistant: Cathy Hays, 621-0216, CH1G@te.cc.cmu.edu Message-ID: <12281674203.29.CY13@TE.CC.CMU.EDU> Currently we have some RP07's formatted for VMS and several formatted for Tops. We would like to be able to interchange these from time to time as hardware konks out. I am aware that each system needs to see its own formatting (36 bit vs 32 bit). We are aware of how to format each type. However we have heard a rumor that it is not possible to take a Tops-20 formatted RP07 and reformat it for use on a Vax. Can anybody confirm or deny this? Please let me know and I will digest the answers back to info-vax and tops-20. Thank you all for your time and consideration, Curt Yeske Technical Administrator Carnegie Mellon Computing Center Disclaimer: The opinions express are my own and are not Carnegie Mellon's. The facts are figments of my imagination anyway. ------- 24-Feb-87 23:21:05-PST,1011;000000000000 Return-Path: Received: from bass.nosc.mil by SCORE.STANFORD.EDU with TCP; Tue 24 Feb 87 23:19:33-PST Received: by bass.nosc.mil (5.31/4.7) id AA00243; Tue, 24 Feb 87 23:23:04 PST Received: by humu.ARPA (5.31/4.7) id AA07579; Tue, 24 Feb 87 21:18:45-1000 Received: by uhmanoa.ICS.HAWAII.EDU (5.51/UUCP-Project/rel-1.0/11-09-86) id AA12710; Tue, 24 Feb 87 20:49:02-1000 Message-Id: <8702250649.AA12710@uhmanoa.ICS.HAWAII.EDU> Date: Tue, 24 Feb 87 20:34:49-1000 From: uhccux!uhmanoa!uhmanoa.ICS.HAWAII.EDU!jeff@nosc.mil (Jeffrey Blomberg) To: tops-20@SCORE.STANFORD.EDU Subject: Xmodem program We have an old version of MODEM which doesn't work very well. It has problems with a number of microcomputer modem programs. Is there a newer, more robust version of MODEM available? We don't need anything fancy for connecting out over networks, just something for our users with assorted microcomputers (who don't have Kermit). -jeff- 25-Feb-87 02:36:59-PST,833;000000000000 Return-Path: Received: from bass.nosc.mil by SCORE.STANFORD.EDU with TCP; Wed 25 Feb 87 02:35:09-PST Received: by bass.nosc.mil (5.31/4.7) id AA02286; Wed, 25 Feb 87 02:38:32 PST Received: by humu.ARPA (5.31/4.7) id AA07925; Wed, 25 Feb 87 00:34:01-1000 Received: by uhmanoa.ICS.HAWAII.EDU (5.51/UUCP-Project/rel-1.0/11-09-86) id AA13447; Tue, 24 Feb 87 23:19:03-1000 Message-Id: <8702250919.AA13447@uhmanoa.ICS.HAWAII.EDU> Date: Tue, 24 Feb 87 23:06:49-1000 From: uhccux!uhmanoa!uhmanoa.ICS.HAWAII.EDU!jeff@nosc.mil (Jeffrey Blomberg) To: tops-20@SCORE.STANFORD.EDU Subject: Xmodem program I was fairly imprecise on my last posting. The 'old' version of MODEM is version 4(316)-7. We still are looking for a newer version if one exists....Aloha. -jeff- 25-Feb-87 09:45:24-PST,985;000000000000 Return-Path: Received: from UTAH-SCIENCE.ARPA by SCORE.STANFORD.EDU with TCP; Wed 25 Feb 87 09:43:08-PST Date: Wed 25 Feb 87 10:42:50-MST From: "Nelson H.F. Beebe" Subject: Re: Xmodem program To: uhccux!uhmanoa!uhmanoa.ICS.HAWAII.EDU!jeff@NOSC.MIL, tops-20@SCORE.STANFORD.EDU cc: Beebe@UTAH-SCIENCE.ARPA In-Reply-To: <8702250919.AA13447@uhmanoa.ICS.HAWAII.EDU> X-US-Mail: "Center for Scientific Computation, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 Message-ID: <12281902027.16.BEEBE@UTAH-SCIENCE.ARPA> We have TMODEM 6.1(400621)-7 obtained from the SIMTEL-20 archives which implements assorted MODEM protocols. You can get it there, or from ANONYMOUS FTP to UTAH-SCIENCE. Get SYS:TMODEM.EXE, HLP:TMODEM.*, and DOC:TMODEM.*. Source is on APS:TMODEM.*. Most of us here have Kermit, so this has probably received little use. ------- 25-Feb-87 11:37:10-PST,1915;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SCORE.STANFORD.EDU with TCP; Wed 25 Feb 87 11:34:50-PST Date: Wed 25 Feb 87 12:29:50-MST From: Frank J. Wancho Subject: Re: Xmodem program To: Beebe@UTAH-SCIENCE.ARPA cc: uhccux!uhmanoa!uhmanoa.ICS.HAWAII.EDU!jeff@NOSC.MIL, tops-20@SCORE.STANFORD.EDU, WANCHO@SIMTEL20.ARPA In-Reply-To: <12281902027.16.BEEBE@UTAH-SCIENCE.ARPA> Message-ID: <12281921506.12.WANCHO@SIMTEL20.ARPA> Because there are certain conditionals in TMODEM.MAC, designed for variations in monitor environments, it is necessary to recompile the source in your particular environment. That is why only the current source is kept in our archives. See the file PD:TMODEM.MAC. The current version is 402. If you mail-only access to DDN, then send a message containing the single line below to ARCHIVE-REQUEST@SIMTEL20.ARPA by any path, except through SEISMO.CSS.GOV. SEND RAW PD:TMODEM.MAC You will receive the source file in about three messages which you'll need to edit together to restore it into its original form. There are other utility files which perform some of the common microcomputer functions in that same directory. To get a list, send a message to the same address as above, but include the following line instead: SEND DIR PD: Up to five requests are accepted per request message. SEND HELP is another line to use which describes the available services of the Archive Server, and is meant only for use by those who do not have FTP access to SIMTEL20.ARPA. Other directories of interest are PD: and PD:, both of which contain KCC C source files and require C:LIBT20.REL, the source of which is not yet available. Executable and relocatable files are not available through the Archive Server. --Frank ------- 26-Feb-87 10:19:25-PST,1161;000000000000 Return-Path: Received: from Xerox.COM by SCORE.STANFORD.EDU with TCP; Thu 26 Feb 87 10:16:12-PST Received: from PinotNoir.ms by ArpaGateway.ms ; 26 FEB 87 09:32:57 PST Date: 26 Feb 87 09:32 PST From: lsmith.pasa@Xerox.COM Subject: Re: RP07 from VMS to TOPS and back. In-reply-to: C. P. Yeske 's message of Tue, 24 Feb 87 15:51:22 EST To: CY13@TE.CC.CMU.EDU cc: info-vax@SRI-KL.ARPA, tops-20@SCORE.STANFORD.EDU Reply-to: lsmith.pasa@Xerox.COM Message-ID: <870226-093257-2638@Xerox> Curt: This is not a direct answer to your question of can you reformat an RP07. However, we were faced with getting data from a DEC10 RP06 disk to a VAX and solved it by using a dual-access RP06 disk drive and developing code to run under TOPS10 to access the RP06 in the VAX' Files-11 format. We were thus able to format the disk from the VAX, then dismount it from the VAX, mount it from the DEC10, write DEC10 files to it, dismount from DEC10, mount from VAX and read the data. If you'd like further details let me know. Leigh Smith Xerox Special Information Systems P.O. box 5608 Pasadena, CA 91107 27-Feb-87 05:08:02-PST,3144;000000000000 Return-Path: <@MIT-MULTICS.ARPA:Jan_Michael_Rynning@QZCOM.MAILNET> Received: from MIT-MULTICS.ARPA by SCORE.STANFORD.EDU with TCP; Fri 27 Feb 87 05:05:23-PST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2718841397367154@MIT-MULTICS.ARPA>; 26 Feb 1987 20:43:17 est Message-ID: <233402@QZCOM> Date: 13 Feb 87 18:53 +0100 From: Jan_Michael_Rynning%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-To: Jan_Michael_Rynning%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA To: TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, Tops-20@SU-SCORE.ARPA Subject: DECnet SINR%, SIBE%, and MTOPR% .MORLS problems with zero-length record. I'm trying to read from DECnet (SRV: or DCN:) asyncronously, using the interrupt system. Everything works fine, until I receive a zero-length record. This is what happens: 1) I get the interrupt, as usual. During the interrupt I must read ALL the records queued up for me, or I will not get any more interrupts. 2) I check the link status with MTOPR% function .MORLS, which returns with MO%EOM set (link has entire message to be read). 3) I check the number of bytes in the message with SIBE%, which skips, returning 0 (SIBE% seems to return the number of bytes in the next record, not the total number of bytes). Is this a correct behaviour? Though the next record is zero-length the input buffer is not empty really. 4) I read the record with SINR% (negative count and byte pointer don't change, indicating zero length). 5) I check the link status with MTOPR% function .MORLS, which again returns MO%EOM, whether there is more to read or not. THIS IS A BUG. 6) Once again I check the number of bytes to read, with SIBE%, which again skips, returning -1 (minus one byte!?), whether there is more to read or not. THIS IS ANOTHER BUG. Reading a zero-length record screws up TOPS-20 DECnet, but everything gets back to normal after reading the next record, whether that is also zero-length or not. My problem is that I can't determine if there is anything more to read after reading the zero-length record. If I try to read another record with SINR% I will hang until I receive another record of input. If I don't try to read another record and there is one I woun't get any more interrupts. Any suggestions? According to the TOPS-20 Monitor Calls Reference Manual, SIBE% should not skip if "The device is not a terminal, is open for read, and the input buffer is not empty. AC2 contains a count of the bytes remaining in the input buffer." This indicates that SIBE% should really take the non skip return, with a zero in AC2, if the next record to be read is zero-length. The current behaviour of SIBE%, not being able to differ between the next record being zero-length and an empty input queue, is both impractical and contrary to the documentation. It should be changed. MTOPR% function .MORLS returning MO%EOM, when there is nothing to read, is a bug which should be corrected. 28-Feb-87 15:49:56-PST,894;000000000000 Return-Path: <@SUMEX-AIM.STANFORD.EDU:MRC@PANDA> Received: from SUMEX-AIM.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Sat 28 Feb 87 15:47:20-PST Received: from PANDA by SUMEX-AIM.STANFORD.EDU with Cafard; Sat 28 Feb 87 15:47:04-PST Date: Sat 28 Feb 87 15:03:37-PST From: Mark Crispin Subject: DIRFDB bugchks To: TOPS-20@Score.Stanford.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12282746855.6.MRC@PANDA> In DIRECT.MAC, the instruction at DELJF2 should be CALL ADRCHK, not CAMGE A,DIRORA. Be sure to also have the patch in LOOKUP.MAC to do MOVE A,B before the JUMPE A,R in the GETFDB routine (after the CALL VERLKX succeeds). By the way, the comments in the code in these areas are total lies. Don't believe any of them. Fortunately, it isn't executed very often. ------- 1-Mar-87 13:25:01-PST,4727;000000000000 Return-Path: Received: from TE.CC.CMU.EDU by SCORE.STANFORD.EDU with TCP; Sun 1 Mar 87 13:23:52-PST Date: Sun 1 Mar 87 16:17:26-EST From: C. P. Yeske Subject: RP07 revisited To: info-vax@SRI-KL.ARPA, tops-20@SCORE.STANFORD.EDU Home-Phone: (412)422-4667 (422-GOOP, -IONS, -HOOP) Office: UCC A72 x2647 Organization: Carnegie Mellon Computing Center, Hardware Systems Staff-Assistant: Cathy Hays, 621-0216, CH1G@te.cc.cmu.edu Message-ID: <12282989669.11.CY13@TE.CC.CMU.EDU> As promised, a digestified answer is below. Basically the rumor is false. My thanks to all those who replied. Curt Yeske Technical Administrator Carnegie Mellon Computing Center CY13@te.cc.cmu.edu Disclaimer: The opinions expressed are my own and are not Carnegie Mellon's. The facts are figments of my imagination anyway. *** My message *** Currently we have some RP07's formatted for VMS and several formatted for Tops. We would like to be able to interchange these from time to time as hardware konks out. I am aware that each system needs to see its own formatting (36 bit vs 32 bit). We are aware of how to format each type. However we have heard a rumor that it is not possible to take a Tops-20 formatted RP07 and reformat it for use on a Vax. Can anybody confirm or deny this? Please let me know and I will digest the answers back to info-vax and tops-20. *** Exact Information *** From: Willis Dair Your rumor is wrong. The RP07 has the capability to format itself to 18-bit (TOPS-20) or 16-bit (VAX). The little microprocessor inside will do the actual formatting. Your local field person should be able to do the formatting. We have some TOP-20 RP07 disks that were converted to be VAX disks. These are pretty smart drives. Willis *** Exact Information *** From: Carl Fussell That is not true. We have two RP07s that were running on our TOPS20 there were reformatted (on site) and are now running on our VAX/VMS system. The operation amounts to removing a jumper from the backplane of the drive and then formatting. Carl Fussell *** Other information *** From: "ROBERT CURLEY" I recently purchased the RP07 from the Medical School Computer Facility here at Penn. It had been connected to a DEC10. I wanted it connected to my 780. During the installation process the Field Service person mumbled something about the format problem - but overcame it. I will ask him about the details if you wish. *** Other *** From: Curt, I don't know about TOPS-20 format packs, but we had no trouble at all when converting our RP07 first from VMS format to TOPS-10 and later from TOPS-10 format to VMS format. In addition to a different block size (TOPS-10 has 128 36bit words per block: 640 bytes instead of 512) the disk was formatted without interleaving while we used it on the 10, but we are using it with interleaving on our 8600. As I recall, the DEC VAX diagnostic that did the reformatting had to run stand-alone because of the stringent timing requirements. I hope this helps. Selden E. Ball, Jr. *** Other Information *** From: 114RONAN%UK.AC.LIVPOL.VAX@AC.UK Hi. Sorry I can't really help you with your RP07 problem, but we had an RA81 delivered for our VAXcluster which had been formatted for 36 instead of 32 bits, and we had to wait weeks while DEC took it back and got another one - they did NOT re-format the original, so maybe it's a hardware thing. On another topic, I notice that your message was also sent to TOPS-20 at Stanford. Can I assume that this is a TOPS-20 version of INFO-VAX? If so, how can I get myself registered on it? We also have a 2065, and if TOPS-20 is anything like INFO-VAX, it will prove a fountain of useful information. I presume there would be no problem getting messages through to here in the U.K.? [try TOPS-20@SCORE.STANFORD.EDU -curt] Ronan Flood, *** Other Information *** From: lsmith.pasa@Xerox.COM This is not a direct answer to your question of can you reformat an RP07. However, we were faced with getting data from a DEC10 RP06 disk to a VAX and solved it by using a dual-access RP06 disk drive and developing code to run under TOPS10 to access the RP06 in the VAX' Files-11 format. We were thus able to format the disk from the VAX, then dismount it from the VAX, mount it from the DEC10, write DEC10 files to it, dismount from DEC10, mount from VAX and read the data. If you'd like further details let me know. Leigh Smith ------- 2-Mar-87 09:11:47-PST,689;000000000000 Return-Path: Received: from C.CS.CMU.EDU by SCORE.STANFORD.EDU with TCP; Mon 2 Mar 87 09:05:20-PST Received: ID ; Mon 2 Mar 87 12:04:44-EST Date: Mon 2 Mar 87 12:04:42-EST From: Vince.Fuller@C.CS.CMU.EDU Subject: Daylight savings time To: TOPS-20@SCORE.STANFORD.EDU Message-ID: <12283205805.24.VAF@C.CS.CMU.EDU> A few months ago, it was mentioned that TOPS-20's concept of Daylight Savings Time will need to be updated this year to agree with the latest Congressional decision. Has anyone written the code to check for year >1987 and apply the new rule? I'd like to know before I go and implement something myself... --Vince ------- 2-Mar-87 12:07:43-PST,1256;000000000000 Return-Path: <@SUMEX-AIM.STANFORD.EDU:MRC@PANDA> Received: from SUMEX-AIM.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Mon 2 Mar 87 12:05:21-PST Received: from PANDA by SUMEX-AIM.STANFORD.EDU with Cafard; Mon 2 Mar 87 11:36:26-PST Date: Mon 2 Mar 87 10:36:40-PST From: Mark Crispin Subject: Re: DECnet SINR%, SIBE%, and MTOPR% .MORLS problems with To: Jan_Michael_Rynning%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20@Score.Stanford.EDU In-Reply-To: <233402@QZCOM> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12283222548.8.MRC@PANDA> It isn't at all clear that using the interrupt system to do asynchronous I/O is the way to go. It is easily possible for PSI's to be doubled or missed entirely under the right conditions. The standard way of doing this is to have two forks running, one handling input and one handling output. Then you can let the input fork block to its heart's content without hanging the other fork. You also guard against deadlocks that are caused by attempting to do output that won't go through until you do input. -- Mark -- ------- 2-Mar-87 19:42:20-PST,2045;000000000000 Return-Path: Received: from Sierra.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 2 Mar 87 19:38:12-PST Date: Mon 2 Mar 87 19:38:49-PST From: Stu Grossman Subject: Re: DECnet SINR%, SIBE%, and MTOPR% .MORLS problems with To: MRC%PANDA@SUMEX-AIM.Stanford.EDU cc: Jan_Michael_Rynning%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20@Score.Stanford.EDU In-Reply-To: <12283222548.8.MRC@PANDA> Message-ID: <12283321241.28.GROSSMAN@Sierra.Stanford.EDU> Mark, I don't think that his problem has anything to do with PSIs. From his description of the problem he is not doing anything inherently incorrect. As long as he attempts to empty the input queue before DEBRKing, he should wake up at the correct time. Even if the queue becomes non-empty between the time he checks it (with an MTOPR) and the DEBRK, DECnet will still deliver a PSI to him. The 'standard way' you talk about is may be your standard way to drive input and output streams, but it ain't necessarily mine, or anybody elses. I have seen (and used) quite a few techniques to accomplish the goal of driving seperate input and output streams, and the method you mention is no more standard than any of the others. If I really wanted to be picky, I could talk about the system impact of running the streams in seperate forks versus internally timesharing the streams in one fork. Since I have no idea what Jan's constraints are, I will not turn this into a programming lesson. I can say however, that what he wants to do is perfectly reasonable, and from his description of the problem it sure sounds like he found a bug in (gasp! Oh my gosh!) DECnet! By the way Jan, what version of TOPS-20 are you running? With respect to DECnet, there is quite a difference between version 6.1 and anything before that. If it's 6.1, you would have a much better chance of getting your problem fixed. Stu Grossman ------- 3-Mar-87 06:42:34-PST,3293;000000000000 Return-Path: Received: from seismo.CSS.GOV by SCORE.STANFORD.EDU with TCP; Tue 3 Mar 87 06:39:52-PST Received: from enea.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP id AA08884; Tue, 3 Mar 87 09:41:16 EST Received: by enea.UUCP (5.51/1.18) id AA12781; Tue, 3 Mar 87 14:43:39 +0100 (MET) Received: by kuling.UUCP; Tue, 3 Mar 87 13:57:09 -0100 Date: Tue, 3 Mar 87 13:57:09 -0100 From: enea!kuling!victor@seismo.CSS.GOV (Bjorn Victor) Message-Id: <8703031257.AA10415@kuling.UUCP> To: TOPS-20@score.stanford.edu Subject: DECnet solutions? Hi fellows, We're having some kind of problem here, I think. Let me explain our situation: Our site, ICU of Uppsala University, Sweden, is going to join the Swedish University Network (SUNET), which is built up with DECnet all over the country. We seem to have a couple of choices as to how to do it, and I'd like to hear your opinion. Any suggestions, or experiences of similar situations, are very welcome! SUNET is built in areas, with central routers for each area. The Uppsala area router is downtown, about 5km from our building. Our possible DECnet machines are our two 2060s and a MicroVAX-II running Ultrix. Since the default ways of running DECnet on 2060s is that you either run it on Ethernet (too short cables) or with a DN20, and since a MicroVAX can run it without a new FE, it seemed clever to attach the router to the MicroVAX, and have the 20s talk to the MicroVAX on Ethernet. Now, obviously, DECnet for Ultrix is only end-node, so it can't route things for the 20s. We don't want to buy DN20s because they're too expensive, so we seem to have two or three choices: 1) Have the uVAX on SUNET, and have the 20s talk DECnet or TCP/IP with some amount of software on the uVAX to simulate routing for parts of the "application layer" (NFT, FTP, SMTP etc). If we were to choose this model and the TCP/IP case, we'd be able to use SUNET from any machine in-house (since everybody talks TCP/IP). It would probably be very hard for people on SUNET to reach anything but the uVAX, though. 2) Have the uVAX on SUNET, and basically only use it as a mail gateway as far as the 20s are concerned. File transfers done by hand, logging in on Ultrix... or maybe... 3) Have a 20 on SUNET through the normal FE, routing things for the other over DECnet on Ethernet. Is this possible? How poor performance would we get? Etc etc. Things that might be of importance: When we get our NIA-20s, we won't be using the standard FE for terminals (more than one or two). Both DECnet-36, TCP/IP and NIA-20s are ordered for the 20s, but we still haven't decided whether to get DECnet for Ultrix or not. It's more important for us to get the 20s on SUNET than the uVAX (at least I think so). Any ideas? Please include me explicitly in replies, since my entry on the list (Victor%AIDA.UPPSALA.SE@SEISMO.CSS.GOV) is off the "net" for yet another week or two. -- Bjorn Victor UUCP: {mcvax,seismo}!enea!kuling!victor Dept. of Computer Systems ARPA: Victor%CARMEN.UPPSALA.SE@SEISMO.CSS.GOV, ICU, Uppsala University Victor%PANDA@SUMEX-AIM.Stanford.EDU SWEDEN EAN: victor@idt.uu.sunet 3-Mar-87 13:53:53-PST,1598;000000000000 Return-Path: <@wiscvm.wisc.edu:IMHW400@INDYCMS.BITNET> Received: from wiscvm.wisc.edu by SCORE.STANFORD.EDU with TCP; Tue 3 Mar 87 13:50:34-PST Received: from INDYCMS.BITNET by wiscvm.wisc.edu on 03/03/87 at 15:30:55 CST Received: by INDYCMS (Mailer X1.23b) id 1575; Tue, 03 Mar 87 16:27:22 EDT Date: Tue, 3 Mar 1987 16:07 EDT From: Mark H. Wood Subject: Routing off an Ethernet To: ,TOPS-20@SCORE.STANFORD.EDU Regarding your mail to the TOPS-20 mailing list, which concerns your need to hook an Ethernet to SUNET: I'm not exactly a DECnet expert, but it seems to me that you have another option (if you have some money). You can buy a DECSA-EA for just about half the cost of a DN20. The box will run synchronous lines at up to 500kb/s (with an add-in DCSAX-LA or -LB) and should do all the routing for your Ethernet. This is one of the primary functions of the DECSA, so support should be good; you may get no more than sympathy if you report problems with a DN20. Also, I think that the DN20 code is still at Phase III, so it may not be able to understand the network on the other side of your local area-router. I have no actual EXPERIENCE with a DECnet, but judging from the product bulletins and catalogs, I would avoid both the DN20 approach (because of the area-routing) and the MicroVAX approach (because DECnet/Ultrix is end-node-only). Maybe some real experts can tell you how to make one of those methods work. I wish you good luck in any case. 3-Mar-87 14:43:08-PST,1890;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SCORE.STANFORD.EDU with TCP; Tue 3 Mar 87 14:42:10-PST Date: Tue 3 Mar 87 17:33:52-EST From: Ken Rossman Subject: Re: Routing off an Ethernet To: IMHW400%INDYCMS.BITNET@WISCVM.WISC.EDU, ENEA!KULING!VICTOR@SEISMO.CSS.GOV, TOPS-20@SCORE.STANFORD.EDU In-Reply-To: Message from "Mark H. Wood " of Tue 3 Mar 87 17:05:27-EST Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 Message-ID: <12283527871.191.SY.KEN@CU20B.COLUMBIA.EDU> Re: DECSA Routers: The DECSA might not be long for this world either. Although it does currently run Phase IV DECnet (we run one here, currently configured to talk to up to 41 areas), and it seems to do its job fairly well (except when we get bad Ethernet jams, which we've been seeing lately for some other reasons), I've heard from various places that there'll be some kind of VAX-based follow-on to replace it before long. So far all I have is some rumors and word of mouth stuff, so don't take any of this as fact. However, the distinct *impression* I'm getting is that the DECSA will be another thing that will fade away. I can only hope that support for the DECSA will not evaporate as fast as TOPS-20 support seems to be. Anyway, there's certainly no reason to pick up a DN20 at this point (other than that you can probably pick up used ones dirt cheap). Since DEC only went up to Phase III routing with them, unless you write your own code, it's probably not worth it. Also, DECSA's are a LOT smaller (we have ours sitting on top of one of our KL's, instead of next to it taking up floor space). Except for some problems trying to run the DECSA fully configured for 63 areas and 1023 nodes per area, I'm very happy with it. /Ken ------- 3-Mar-87 14:58:34-PST,996;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SCORE.STANFORD.EDU with TCP; Tue 3 Mar 87 14:57:46-PST Date: Tue 3 Mar 87 17:51:29-EST From: Ken Rossman Subject: Re: DECnet solutions? To: enea!kuling!victor@SEISMO.CSS.GOV, TOPS-20@SCORE.STANFORD.EDU In-Reply-To: <8703031257.AA10415@kuling.UUCP> Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 Message-ID: <12283531078.191.SY.KEN@CU20B.COLUMBIA.EDU> Forgot to mention about the DECSA before, there are only two DEC supported machines that can download this box: a VAX/VMS system and an RSX-11 system. We do neither, however. We download here from our TOPS-20 systems, and it seems to work just fine. The software gen process still has to take place on a VAX/VMS system, however. Anyone from DEC care to comment on how likely it will be that Ultrix will support DECSA's (or whatever the follow-on VAX router will be)??? /Ken ------- 5-Mar-87 00:47:47-PST,2288;000000000000 Return-Path: Received: from BIONET-20.ARPA ([128.92.192.5].#Internet) by SCORE.STANFORD.EDU with TCP; Thu 5 Mar 87 00:46:14-PST Date: Thu 5 Mar 87 00:47:42-PST From: David Roode Subject: file archiving To: info-vax@SRI-KL.ARPA, Yonke@INTELLICORP.ARPA cc: TOPS-20@SCORE.STANFORD.EDU Phone: (415) 962-7322 Message-ID: <12283901762.18.ROODE@BIONET-20.ARPA> I saw a message that talked about a primitive system of file archiving. We need on VMS what we enjoy on TOPS-20: an integrated file archiving and retrieval system. 1. System manager can identify files not read or written in a specified period (i.e. deadwood). Users can optionally be sent message listing such files. After potentially waiting for them to respond, the system manager can move the files to tape, leaving a pointer behind for the user, ONLINE. 2. Users can have two quotas, working and permanent. Users over their permanent quota at a pre-defined time (2 a.m. MWF) are subject to forced migration of files to offline storage, with pointers left behind ONLINE. Users can identify files to leave on line at all costs, and specify the order for selection of files to move offiline. 3. Users can selectively request archive of files in offline storage, WITH ONLINE POINTERS. A queue is maintained of files to be processed, with movement to offline status (ONLINE pointers) at a pre-defined time, i.e. 1AM MTWThF), as a part of normal system tape procedures, e.g. backup. 4. Retrievals are requested at users' convenience. An interactive command issued to review files currently in offline storage and to request retrieval of same. A queue is maintained, with files retrieved according to system policy, i.e. continuously during the day, within 1 hour, within 4 hours, daily at night, etc. 5. All of this benefits from operational practice that once moved offline, 90% of files are never sought again by their owners. However, users are many times more amenable to removing data from online storage when online pointers and a retrieval path are maintained. Disk usage can be reduced by up to 50%, with minimal increase in operational overhead. And, DIGITAL HAS IT NOW, in TOPS-20, order number QT100. ------- 5-Mar-87 12:16:56-PST,1119;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SCORE.STANFORD.EDU with TCP; Thu 5 Mar 87 12:16:51-PST Date: Thu, 5 Mar 1987 15:16 EST Message-ID: From: Rob Austein To: vaf@C.CS.CMU.EDU, su-tops-20@SCORE.STANFORD.EDU cc: sra@XX.LCS.MIT.EDU Subject: .PRESS files I have just acquired a new boss. He just spent the morning being cried on by some of our users because our crufty old Xerox Dover is down again. Among the thing people were crying about was the fact that when the Dovers really and truely lose, they will not be able to print out their old ILLUSTRATE press files anymore. So my new boss has asked me to find out if anybody has written a program that converts .PRESS files to DVI, Impress, Postscript, or anything else "modern". I have about as much interest in this as I have in learning VAX/VMS assembler, but if somebody at one of the other schools with Dovers has done all this work, I could make my new boss very happy by telling him about it. Don't all shout at once.... Thanks. --Rob 8-Mar-87 14:43:46-PST,1612;000000000000 Mail-From: BILLW created at 8-Mar-87 14:40:41 Date: Sun 8 Mar 87 14:40:41-PST From: William "Chops" Westfield Subject: bug in 6.1 ap14: re: incompletely created files... To: tops-20@Score.Stanford.EDU Message-ID: <12284839834.10.BILLW@Score.Stanford.EDU> Our monitor, based on tops20 v6.1 ap14 or so, does not seem to properly get rid of "incompletely created files" when a fork is reset. Do other people have this bug, or is it suppsoed to be somehow considered a feature (realted to CFS, i presume) (We do not have a CI, and we do not use CFS... Enjoy BillW REepeat by: [PHOTO: Recording initiated Sun 8-Mar-87 2:28PM] !cd <2scRATCH> !v %No files match this specification - !in d SCO:<2SCRATCH> 0 Pages assigned 1000 Working pages, 1000 Permanent pages allowed 3453 Pages free on SCO:, 72547 pages used. !ftp score < SCORE.STANFORD.EDU FTP Server Process 5Z(50)-7 at Sun 8-Mar-87 14:29-PST Setting default transfer type to paged. FTP>get system:monitr.exe (to local file) foo.foo < Please log in first, with USER, PASS and ACCT. < User ANONYMOUS logged in at Sun 8-Mar-87 14:29-PST, job 15. PS:MONITR.EXE.37 => <2SCRATCH>FOO.FOO.1;P775202 !!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!^C !reset !v %No files match this specification - !in d SCO:<2SCRATCH> 311 Pages assigned 1000 Working pages, 1000 Permanent pages allowed 3138 Pages free on SCO:, 72862 pages used. !exp, !!purgE (NOT COMPLETELY CREATED FILES) !! SCO:<2SCRATCH> [311 pages freed] !po [PHOTO: Recording terminated Sun 8-Mar-87 2:31PM] ------- 8-Mar-87 15:39:14-PST,912;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SCORE.STANFORD.EDU with TCP; Sun 8 Mar 87 15:36:58-PST Date: Sun 8 Mar 87 18:38:13-EST From: Ken Rossman Subject: Re: bug in 6.1 ap14: re: incompletely created files... To: BILLW@SCORE.STANFORD.EDU, tops-20@SCORE.STANFORD.EDU Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 Message-ID: <12284850305.141.SY.KEN@CU20B.COLUMBIA.EDU> We have 6.1, a CI, and CFS, and I believe we've seen that problem also in the past, although I was unable just now to recreate it. I even tried doing exactly what you did, Bill, and FTPed a chunk of SCORE's monitor over here before ^C-ing out (figured maybe it was just SCORE's MONITR.EXE that was causing the whole problem :-), but couldn't get it to break. I know I've seen this plenty of times before though. /Ken ------- 9-Mar-87 04:05:35-PST,1138;000000000000 Return-Path: <@SUMEX-AIM.STANFORD.EDU:MRC@PANDA> Received: from SUMEX-AIM.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Mon 9 Mar 87 04:03:40-PST Received: from PANDA by SUMEX-AIM.STANFORD.EDU with Cafard; Mon 9 Mar 87 04:03:53-PST Date: Mon 9 Mar 87 00:17:31-PST From: Mark Crispin Subject: BBN TCP To: TOPS-20@Score.Stanford.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12284944842.7.MRC@PANDA> SIMTEL20 is considering migrating to the BBN TCP, mostly to get the advantages of RFNM counting and repacketizing on retransmission. I would be interested in hearing what experiences other sites have had with it. Specifically, is any functionality in the DEC TCP lost by going to the BBN TCP? Is the NI code known to work in BBN TCP? Also, has anyone implemented RFNM counting in the DEC TCP? I looked at it somewhat and it's hairy... I guess what I'm really interested in is hearing if there are any reasons NOT to migrate to the BBN TCP, given that the level of (non-)support seems to be about the same. ------- 9-Mar-87 07:35:51-PST,1026;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SCORE.STANFORD.EDU with TCP; Mon 9 Mar 87 07:34:03-PST Date: Mon, 9 Mar 1987 10:34 EST Message-ID: From: Rob Austein To: Mark Crispin Cc: TOPS-20@SCORE.STANFORD.EDU Subject: BBN TCP In-reply-to: Msg of 9 Mar 1987 03:17-EST from Mark Crispin Back when XX was running 5.0, it used to hang its AN20 once every few days, and the only way to clear it was to bring down the system, powercycle (!!) the AN20, and bring the machine back up. When we put up 5.4 this behavior went away. Our local monitor guru looked into this and came to the conclusion that somehow the 5.0 code was being screwed by having RFNM counting enabled. I don't remember the details anymore, and this may have been fixed since then, but if you make this changeover and your AN20 starts hanging, you'll know what happened.... --Rob 9-Mar-87 10:09:41-PST,2434;000000000000 Return-Path: Received: from UTAH-SCIENCE.ARPA by SCORE.STANFORD.EDU with TCP; Mon 9 Mar 87 10:06:28-PST Date: Mon 9 Mar 87 09:48:59-MST From: "Nelson H.F. Beebe" Subject: Unix tar (tape archive) implementations on Tops-20 To: tops-20@SCORE.STANFORD.EDU cc: BEEBE@UTAH-SCIENCE.ARPA, hack@PREP.AI.MIT.EDU X-US-Mail: "Center for Scientific Computation, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 Message-ID: <12285037951.23.BEEBE@UTAH-SCIENCE.ARPA> A few years ago, Marshall Rose and John Romine at UC-Irvine wrote an implementation of the Unix TAR (tape archive) utility in MACRO. I acquired a copy about 3 yr ago with our PCC-20 distribution, and have been intermittently adding features. It has now gotten to the point of being quite useful, with automatic byte size recognition and relative directory paths. In recent correspondence with John Romine, I obtained their most recent version, plus a copy of an independent one, also in MACRO, done by Chris Maio at Columbia in June 1983. At the top of my wishlist for future work is the conversion of this facility to C, to facilitate porting to other non-Unix systems. Neither the AT&T Unix TAR nor a public domain implementation posted on net.sources last fall seem to be suitable starting points, because (a) they lack the nice TOPS-20 COMND JSYS interface (for which I propose to use Kermit code), and (b) they know too much about Unix shells and directory structure. Since my version of the Rose/Romine TAR is now perfectly useful to me, a recoding and merging of features of the three MACRO versions is a lower-priority project which may or may not take place over the next several months, as time permits. The question I am posing here is, Has anyone else already done this, or developed yet another Tops-20 TAR, that they would be willing to share for the purposes of producing a version of wide utility and availability (I intend to support at least VAX VMS and IBM PC DOS, in addition to Tops-20)?" Any modifications to either of the cited implementations would also be of interest. If a recoded version of TAR is prepared, I will certainly place it in the public domain. Presumably the GNU project will be producing a TAR too, but it may be closely tied to the underlying Unix operating system too. ------- 9-Mar-87 12:02:22-PST,687;000000000000 Return-Path: Received: from HAMLET.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Mon 9 Mar 87 12:00:50-PST Date: Mon 9 Mar 87 12:01:41-PST From: Rich Alderson Subject: Re: BBN TCP To: MRC%PANDA@SUMEX-AIM.STANFORD.EDU cc: TOPS-20@SCORE.STANFORD.EDU In-Reply-To: <12284944842.7.MRC@PANDA> Message-ID: <12285073032.115.A.ALDERSON@HAMLET.STANFORD.EDU> LOTS uses the Stanford standard monitor, which includes the BBN TCP code rather than DEC's. This monitor runs on an SC-30M with an EI, the Systems Concepts NI workalike, so I suspect that a DEC NI will work with the BBN code as well. Rich ------- 9-Mar-87 13:31:09-PST,1062;000000000000 Mail-From: BILLW created at 9-Mar-87 13:28:44 Date: 9 Mar 1987 13:28-PST Sender: BILLW@SCORE.STANFORD.EDU Subject: Re: BBN TCP From: William "Chops" Westfield To: A.ALDERSON@Hamlet.Stanford.EDU Cc: MRC%PANDA@SUMEX-AIM.Stanford.EDU Cc: TOPS-20@Score.Stanford.EDU Message-ID: <[SCORE.STANFORD.EDU] 9-Mar-87 13:28:43.BILLW> In-Reply-To: <12285073032.115.A.ALDERSON@HAMLET.STANFORD.EDU> the Stanford monitor DOES NOT use the BBN TCP networking code. A single modulde from the BBN code was adapted to the DEC monitor when the DEC code was found to be excessively buggy (IPFREE), but the rest of the code is based on the DEC monitor. The Stanford monitor DOES include many TCP performance enhancements that are orthogonal to the BBN improvements. It would be a real win if someone managed to merge the two togehter. Sadly, the BBN code is based on 5.x, and just getting it to run under 6.1 is a major task. (if anyone gets 1 6.1 monitor with the BBN TCP code, id be happy to add the stanford changes...) BillW 9-Mar-87 13:53:16-PST,1289;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SCORE.STANFORD.EDU with TCP; Mon 9 Mar 87 13:51:25-PST Date: Mon 9 Mar 87 16:01:53-EST From: Ken Rossman Subject: Re: Unix tar (tape archive) implementations on Tops-20 To: Beebe@UTAH-SCIENCE.ARPA, tops-20@SCORE.STANFORD.EDU cc: hack@PREP.AI.MIT.EDU In-Reply-To: <12285037951.23.BEEBE@UTAH-SCIENCE.ARPA> Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 Message-ID: <12285083992.141.SY.KEN@CU20B.COLUMBIA.EDU> Neither the AT&T Unix TAR nor a public domain implementation posted on net.sources last fall seem to be suitable starting points, because (a) they lack the nice TOPS-20 COMND JSYS interface (for which I propose to use Kermit code), and (b) they know too much about Unix shells and directory structure. If you plan to COMNDize a C program, don't use the existing Kermit code. You might want to use instead a more general interface written here at Columbia, called CCMD. I say "might" because it's really still in beta test, although for the most part, it seems to be working fine. The CCMD distribution can be found on CU20B.COLUMBIA.EDU in WS:, and should be anonymously FTPable. /Ken ------- 9-Mar-87 21:35:18-PST,1890;000000000000 Return-Path: Received: from SRI-NIC.ARPA by SCORE.STANFORD.EDU with TCP; Mon 9 Mar 87 21:28:34-PST Date: Mon 9 Mar 87 21:30:37-PST From: Mark Lottor Subject: ipfree bug To: tops-20@SCORE.STANFORD.EDU Message-ID: <12285176604.18.MKL@SRI-NIC.ARPA> Here's a bug report on IPFREE space problems. It's not complete but it could be helpful to people who have been crashing a lot due to this problem. I do NOT recommend installing it unless you have the same problem described. We've been running about a month on this fix without hitting the listed bughlt's below. While we run the Stanford monitor with who knows who's network code, I think this might apply to most other monitors also. For us, installing the fix below caused other code which relied on the bug to break. The only problem noted was that we could no longer accept TCP packets of the Maximum Segment Size that we were announcing. Because of that and other inconsistencies relating to packet count/sizes I upped the value INTBSZ in STG by 20 (octal) words but I suspect we could have used less. That seemed to fix the TCP MSS bug. Someone really needs to spend a bunch of time fixing all the packet size related counts throughout the monitor. Program: 6.1 AP14 Monitor with Stanford mods. IPFREE module. Problem: Internet buffer head and tail words get clobbered causing at least INTFR0 and INTSUC bughlts and probably other random failures. Reason: GETBBK does not preserve SIZ when calling GETBK0 and so the block size returned is wrong and the block may be overwritten by whoever uses it. Fix: In routine GETBB0, replace the two calls to GETBK0 with MOVE T1,SIZ CALL GETBL0 MOVE BLK,T1 Note that your older monitor may not have a GETBL0 routine so you'll have to write your own fix. ------- 10-Mar-87 10:46:28-PST,1181;000000000000 Mail-From: BILLW created at 10-Mar-87 10:46:22 Date: Tue 10 Mar 87 10:46:22-PST From: William "Chops" Westfield Subject: New version of TOPS20 "WHOIS" program. To: su-computers@Score.Stanford.EDU cc: su-tops-20@Score.Stanford.EDU Message-ID: <12285321464.17.BILLW@Score.Stanford.EDU> the WHOIS program that runs on the campus tops20 systems has traditionally been used to look up "official arpanet users" by remotely accessing a database stored at the Network Information Center (at SRI). This program has now been updated to access a similar database of Stanford specific information stored at ACIS Networking. For example: @whois score (host information about score) @whois staffmember (look up info on staff member (equivilent to the staff/faculty phone book)) @whois studentname (equivilent to student phonebook (not yet installed)) If you want to use the old version, use NWHOIS (for NicWhois). The new WHOIS and NWHOIS programs have been installed on Score, Sushi, and Truffle, and will probably shortly propagate to other campus 20's. the sources are in SCORE::WHOIS.FAI. Enjoy BillW ------- 10-Mar-87 11:33:20-PST,528;000000000000 Mail-From: BILLW created at 10-Mar-87 11:33:09 Date: Tue 10 Mar 87 11:33:09-PST From: William "Chops" Westfield Subject: NWHOIS renamed to NICNAME. To: su-computers@Score.Stanford.EDU cc: su-tops-20@Score.Stanford.EDU Message-ID: <12285329982.17.BILLW@Score.Stanford.EDU> The name for the OLD version of WHOIS on Score/Sushi/Truffle has been changed from NWHOIS to NICNAME. Andy Sweer pointed out that this is apparently the officially sanctioned name for that program. BillW ------- 11-Mar-87 03:01:45-PST,1663;000000000000 Return-Path: Received: from bass.nosc.mil by SCORE.STANFORD.EDU with TCP; Wed 11 Mar 87 02:54:52-PST Received: by bass.nosc.mil (5.31/4.7) id AA20847; Wed, 11 Mar 87 02:57:42 PST Received: by humu.ARPA (5.31/4.7) id AA21716; Wed, 11 Mar 87 00:55:03-1000 Received: by uhmanoa.ICS.HAWAII.EDU (5.51/UUCP-Project/rel-1.0/11-09-86) id AA14606; Tue, 10 Mar 87 23:04:19-1000 Message-Id: <8703110904.AA14606@uhmanoa.ICS.HAWAII.EDU> Date: Tue, 10 Mar 87 22:49:05-1000 From: uhccux!uhmanoa!uhmanoa.ICS.HAWAII.EDU!jeff@nosc.mil (Jeffrey Blomberg) To: BILLW@SCORE.STANFORD.EDU, sy.Ken@CU20B.COLUMBIA.EDU, tops-20@SCORE.STANFORD.EDU Subject: Re: bug in 6.1 ap14: re: incompletely created files... We have encountered the incomplete file problem quite a bit lately. We have students writing programs which manage to consume their directory allocations and stop. A RESET does not free the allocated space and EXPUNGE, PURGE must be used. I called CSC and got the impression that they thought thats the way it was supposed to work. I plan to research and possibly SPR the problem soon ( a little side tracked lately). I might add that depending on the programming language (Pascal vs. FORTRAN), the problem may not occur. I suspect its related to the way OPENF is done. We are running v6.1 ap14 (w/tcp). I believe the problem started after ap14. To reproduce the problem, I simply tried using a program like REV to copy a big file to a small directory. Sorry I can't offer a solution, but I wanted to at least mention that we are having the same thing happening. -jeff- 11-Mar-87 05:52:01-PST,1309;000000000000 Return-Path: <@wiscvm.wisc.edu:IMHW400@INDYCMS.BITNET> Received: from wiscvm.wisc.edu by SCORE.STANFORD.EDU with TCP; Wed 11 Mar 87 05:47:44-PST Received: from INDYCMS.BITNET by wiscvm.wisc.edu on 03/11/87 at 07:45:42 CST Received: by INDYCMS (Mailer X1.23b) id 0937; Wed, 11 Mar 87 08:11:08 EDT Date: Wed, 11 Mar 1987 07:59 EDT From: Mark H. Wood Subject: Re: bug in 6.1 AP14: incompletely created files To: I wonder if this is in any way related to my observation that ANY file, when deleted, may hang around for a few minutes before relinquishing its portion of one's quota? Several of our users have complained that they have deleted a large file and found no immediate change in their quotas. The space always seems to be deallocated eventually. The file disappears from the directory immediately, but still takes up space. I suspect that this problem is related to OFN caching. Do the incompletely-created files EVER go away if you wait for a few minutes? Also, can anybody think of a good reason not to turn off OFN caching when the boot code determines that there is no KLIPA? For non-CFS sites (pronounced "most sites"), it looks like a waste of time and page frames. 11-Mar-87 12:20:39-PST,1995;000000000000 Return-Path: Received: from Sierra.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 11 Mar 87 12:19:20-PST Date: Wed 11 Mar 87 11:00:22-PST From: Stu Grossman Subject: Re: bug in 6.1 AP14: incompletely created files To: IMHW400%INDYCMS.BITNET@WISCVM.WISC.EDU cc: TOPS-20@Score.Stanford.EDU In-Reply-To: Message from "Mark H. Wood " of Wed 11 Mar 87 06:46:39-PST Message-ID: <12285586158.31.GROSSMAN@Sierra.Stanford.EDU> It sounds like the quota anomalies experienced by your users may be caused by the fact that they still have the files in question opened by some fork. They should try doing a RESET * followed by an EXPUNGE. It's also possible that their file may be opened by someone else (in another job). If either of these cases is true, then you should be able to see the files in question as being deleted (the command DIR,DEL will show them). Re: OFN cacheing, To clear the air a little (actually before it gets fogged up), OFN cacheing (conceptually) has nothing to do with CFS. Essentially, what it does is it keeps the monitor from flushing out all of it's information about a file when nobody is currently accessing it. This means that the next reference to a file will be able to take advantage of the cached data. This is a big win for frequently accessed files. It also is (again conceptually) independant of CFS. It interacts with CFS to the extent that OFNs are managed by CFS, and the consistency of the cached OFNs is maintained by CFS interlocking. To wit, my system does not have CFS, but when I put up AP14 I noticed an appreciable improvement in disk I/O bound stuff. The resource consumption due to OFN cacheing is pretty minimal. The OFNs get swapped out when nobody is using them. In addition, I think that there is a little extra table space (one or two words per OFN maybe?). Stu Grossman ------- 11-Mar-87 15:05:18-PST,1944;000000000000 Return-Path: Received: from lindy.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Wed 11 Mar 87 15:04:57-PST Received: by lindy.STANFORD.EDU; Wed, 11 Mar 87 09:13:42 PST Date: Wed, 11 Mar 87 09:12:41 PST From: Reply-To: RFORSTER%UNCAEDU.BITNET@forsythe.stanford.edu To: tops-20@score.stanford.edu Subject: Re: bug in 6.1 ap14: re: incompletely created files... Date: Wed, 11 Mar 87 10:12 MST From: Subject: Re: bug in 6.1 ap14: re: incompletely created files... To: tops-20@score.stanford.edu X-Original-To: sy.ken@cu20b.columbia.edu,billw@score.stanford.edu, tops-20@score.stanford.edu, RFORSTER We too have encountered the incomplete file problem here. Its almost a virus. Our environment is primarally students. We found that our problems are directly related to the .TMP files created by COBOL (at ap14). The student will ~C out of COBOL and will find that all there space is used up. We go through the same ritual of RESET, CLOSE, EXPUNGE with PURGE to clear the problem. Its so bad here that I mailed the to procedure to the students just to keep them off my back. Until it was mentioned here, I thought we just had the problem so I put to student carelessness in there codeing. /Russ -- "We must acknowledge, once and for all, that the purpose of diplomacy is to prolong a crisis." - Spock Russell M Forster BITnet: RForster@UNCAEDU.BITnet ARPA: OC.Russ@CU20B.Columbia.Edu CPS: Mount Royal College 4825 Richard Rd. SW. Calgary, Alberta Canada, T3E 6K6 Voice: (403) 240-6052 Opinions expressed herein are my own, and do not necessarily represent those of my employer or anyone else for that matter. 12-Mar-87 21:04:03-PST,2724;000000000000 Return-Path: <@SUMEX-AIM.STANFORD.EDU:MRC@PANDA> Received: from SUMEX-AIM.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Thu 12 Mar 87 20:56:35-PST Received: from PANDA by SUMEX-AIM.STANFORD.EDU with Cafard; Thu 12 Mar 87 20:51:29-PST Date: Thu 12 Mar 87 14:24:08-PST From: Mark Crispin Subject: TOPS-20 MACSYMA To: JPG@Allegheny.SCRC.Symbolics.COM cc: TOPS-20@Score.Stanford.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12285885395.6.MRC@PANDA> Jeff - I was forwarded a message from you regarding TOPS-20 MACSYMA, to the effect that "[Symbolics does't] offer MACSYMA [for the DEC-20]. [Symbolics] stopped shipping DEC-20 MACSYMA at least a couple of years ago." There are, however, a number of organizations with DEC-20's that would like to get ahold of DEC-20 MACSYMA. Can I construe Symbolics' position on DEC-20 MACSYMA to be one of abandonment, and that Symbolics is willing to forgo its proprietary rights on DEC-20 MACSYMA so that it may be placed in the public domain? Alternatively, if Symbolics continues to claim ownership of DEC-20 MACSYMA, will it be willing to grant various interested parties, such as myself, a no-fee licese to use and redistribute MACSYMA? If either is the case, I request a statement from Symbolics in writing so that everyone's legal rights are protected. I propose, provided Symbolics permits it, to distribute DEC-20 MACSYMA as part of a general large volume of public-domain and semi- public-domain tools which I already distribute at very close to my cost. A MACSYMA distribution would probably be about $50, although if I have to deal with making people sign license agreements I'll have to up the cost to $100 to cover my overhead. That is still quite within the cost of "freeware" and "shareware" distribution. My preference would be for Symbolics to get out of the DEC-20 business altogether and abandon its ownership of DEC-20 MACSYMA. This would be the best means to facilitate maximum possible distribution of MACSYMA. I am willing, as a concession to Symbolics' commercial interests, to acknowledge your donation to our community in all associated documentation and to emphasize that more advanced versions of MACSYMA with larger capacity are available for other CPU's from Symbolics. The impact to Symbolics may end up being positive, as this would provide free advertising (consider how DEC-20 EMACS provided the base for consumer demand for commercial versions of EMACS on other CPU's). Thank you very much for you consideration. Regards, -- Mark -- ------- 12-Mar-87 22:23:22-PST,443;000000000000 Return-Path: Received: from SRI-NIC.ARPA by SCORE.STANFORD.EDU with TCP; Thu 12 Mar 87 22:18:42-PST Date: Thu 12 Mar 87 17:14:39-PST From: Mark Lottor Subject: tcb max To: tops-20@SCORE.STANFORD.EDU Message-ID: <12285916437.22.MKL@SRI-NIC.ARPA> Has anyone modified their Monitor to support more than 50 TCBs? It looks like major work so I'm hoping someone else already did it. Mark ------- 12-Mar-87 22:51:36-PST,1049;000000000000 Mail-From: BILLW created at 12-Mar-87 22:50:21 Date: 12 Mar 1987 22:50-PST Sender: BILLW@SCORE.STANFORD.EDU Subject: Re: tcb max From: William "Chops" Westfield To: MKL@SRI-NIC.ARPA Cc: tops-20@Score.Stanford.EDU Message-ID: <[SCORE.STANFORD.EDU]12-Mar-87 22:50:20.BILLW> In-Reply-To: <12285916437.22.MKL@SRI-NIC.ARPA> The stanford monitor supports more than 50 TCBs (currently 75). It isn't as difficult as it looks - the main problem is that there would not be enough wait bits (which would truly be a pain to add), except that the stimate of the number of wait bits used in STG is much larger than what is actually required. (it assumes 10 per TCB/Connection, but TVTs (which account for most of your connections) only use 2, TCP: connections use a max of 6. A few are used by locks and such, but only a full fledged BBN interface connection is going to use all 10! (it's 2 per TCB, +1 per BFR)). All the Stanford 20's regurally have more than 50 TCP connections, and it works OK... BillW 13-Mar-87 07:30:53-PST,865;000000000000 Return-Path: Received: from nmfecc.arpa by SCORE.STANFORD.EDU with TCP; Fri 13 Mar 87 07:27:25-PST Received: from 11.mfenet by ccx.mfenet with MfeMail ; Fri, 13 Mar 87 06:58:00 PST Date: Fri, 13 Mar 87 06:58:00 PST From: HAMMON%11.MFENET@nmfecc.arpa Message-Id: <870313065800.09o@nmfecc.arpa> To: TOPS-20@SU-SCORE.ARPA Subject: Good Bye From: HAMMON@11.MFENET To: TOPS-20@SU-SCORE.ARPA Date: Fri 13 Mar 87 06:59:02-PST Subject: Good Bye From: Randy Hammon To: tops-20@kSU-SCORE.ARPAk Our Dec-20 is supposed to be taken away today, so I just wanted to say good-by and thanks to the tops-20 community for all the help over the years. This is the Dec-20 at Lawrence Livermore Lab signing off for good, Randy Hammon ( new address hammon%llv.mfenet@nmfecc.arpa ) ------- 13-Mar-87 10:11:01-PST,1220;000000000000 Return-Path: Received: from Sierra.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 13 Mar 87 10:10:53-PST Date: Thu 12 Mar 87 19:06:37-PST From: The Mailer Daemon To: GROSSMAN@Sierra.Stanford.EDU Subject: Message of 12-Mar-87 19:06:33 ReSent-Date: Fri 13 Mar 87 10:13:26-PST ReSent-From: Stu Grossman ReSent-To: su-tops-20@Score.Stanford.EDU ReSent-Message-ID: <12286101901.21.GROSSMAN@Sierra.Stanford.EDU> Message failed for the following: su-tops20@Score.Stanford.EDU.#Internet: 550 No such local mailbox as "su-tops20", recipient rejected ------------ Date: Thu 12 Mar 87 19:06:33-PST From: Stu Grossman Subject: CD%STF and SC%STF To: su-tops20@Score.Stanford.EDU Message-ID: <12285936807.17.GROSSMAN@Sierra.Stanford.EDU> Does anyone know why we need a CD%STF bit? It seems that the bit SC%STF fulfills the function of "staff mode" quite nicely. It's also much more accessible. Currently, LOTS is the only site using SC%STF. Everybody else gets CD%STF if they specify the "staff" command when in the EXECs directory building mode. Stu ------- ------- 13-Mar-87 10:37:44-PST,1480;000000000000 Return-Path: <@SUMEX-AIM.STANFORD.EDU:MRC@PANDA> Received: from SUMEX-AIM.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Fri 13 Mar 87 10:36:17-PST Received: from PANDA by SUMEX-AIM.STANFORD.EDU with Cafard; Fri 13 Mar 87 10:35:38-PST Date: Fri 13 Mar 87 10:00:36-PST From: Mark Crispin Subject: bogons in Phase IV DECnet code To: TOPS-20@Score.Stanford.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12286099564.6.MRC@PANDA> At the beginning of .NODE and .NTINF, there are spurious EA.ENT macros. Not only are they completely unnecessary on a model B CPU (since jsi are always called in section 1) but in fact they a bug on model A CPU's. When $EAENT (in APRSRV) recognizes that the PC is in section 0, it tries to jump into section 1 and then does a HRRZS (P) to make sure the caller's return PC is a section 0 PC. The problem is that at the entry point to a JSYS there isn't a return PC on the stack. The next thing on the stack is the PC flags, which were clobbered by this HRRZS (P). This fooled MRETN into thinking this was a from-the-monitor JSYS and eventually I ended up with an OPOPAC bughlt. There are multiple approaches to fixing this problem. One is to delete the bogus EA.ENT's from the affected jsi. Another is to change the HRRZS into a PUSH P,[0,,R]. I'm the sort of guy who wears both a belt and suspenders; I did both. ------- 13-Mar-87 14:10:12-PST,632;000000000000 Return-Path: Received: from Sierra.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 13 Mar 87 14:09:22-PST Date: Fri 13 Mar 87 14:11:30-PST From: Stu Grossman Subject: Re: bogons in Phase IV DECnet code To: MRC%PANDA@SUMEX-AIM.Stanford.EDU cc: TOPS-20@Score.Stanford.EDU In-Reply-To: <12286099564.6.MRC@PANDA> Message-ID: <12286145240.39.GROSSMAN@Sierra.Stanford.EDU> EA.ENT was intended to be a null macro on model A processors and 2020's. There is no reason for all the hand waving it does (right or wrong) on a non-extended addressing machine. ------- 16-Mar-87 10:09:41-PST,6706;000000000001 Return-Path: Received: from MARLBORO.DEC.COM by SCORE.STANFORD.EDU with TCP; Mon 16 Mar 87 10:07:27-PST Date: 16 Mar 1987 1311-EST From: "Joe Dempster, DTN: 336.2252 AT&T: 609.665.8711" To: TOPS-20@SU-SCORE.ARPA, AILIST@SRI-STRIPE.ARPA, INFO-VAX@SRI-KL.ARPA, TOPS-20_EXPERTS_MAILING_LIST%OZCOM.MAILNET@MIT-MULTICS.ARPA Subject: Announcement of the DEC 10 and PDP-6 history project (PROJECT-10262) Message-ID: <"MS11(5206)+GLXLIB5(0)" 12286887993.13.48.64591 at MARLBORO.DEC.COM> This message originates from 2 sources: Les Earnest Computer Science Department STANFORD UNIVERSITY Stanford, CA 94305 415.723.9729 ARPA: LES@SAIL.STANFORD.EDU Joe Dempster DIGITAL EQUIPMENT CORPORATION 6 Cherry Hill Executive Campus Route 70 Cherry Hill, NJ 08002 609.665.8711 ARPA: DEMPSTER@MARLBORO.DEC.COM (MARKET) The goal of this project is to publish an analysis and history of the evolution, implementation and use of Digital's 36 bit systems. This period began with the PDP-6 in 1964 and continues today with TOPS 10/20 development, which is scheduled to end in 1988. We are working aggressively to finish the project, and have it published, by March/April 1988. This will require that the completed manuscript be ready to go into the publication cycle by August 1987! The project will attempt to answer the following questions: 1. In what markets/applications were these systems used? 2. Who were the users of these systems and what impact did roughly 2,500 TOPS 10/20 systems have on their organizations? 3. Who were the principle system architects of these systems? What features, and if there had been sufficient time to implement them, would have significantly improved the architecture? 4. What impact did the decision to continue to examine design extensions to the architecture have on the usefulness and acceptability of these systems. This is in contrast to a more common practice today to work from a detailed design specification, sometimes dated, building follow-on systems which provide increased performance through the use of new component technologies and packaging techniques. 5. What part of the overall design (TOPS10/20) was technology dependent and what can still be considered "unequaled" in relation to other computer architectures still undergoing active development? 6. What type of development environment (both HW and SW) supported and contributed to the evolution of 36 bit systems? 7. What influence did TOPS 10/20 have on other vendors system development? This history will undoubtedly be assembled from many sources and participants. Some information will be anecdotal; there will be interviews with the people involved (users and developers) and technical papers will be solicited. Of course there will also be the packaging and assembly of facts as we see them. The result will hopefully have sufficient depth to serve as: 1. An introductory or advanced text on system design and hardware/system software implementation. 2. A analysis of the success and difficulties of marketing complex systems into a very crowded market of competing alternatives. 3. A catharsis for those of us who have contributed to the development and use these systems and who will now move onto new computing architectures and opportunities. In addition to interviewing directly 25-50 developers, users and product managers we will continue to work to identify contributors and significant events up to when the final draft is submitted to the publisher. Two "topics" are already under development: 1. Rob Gingell from SUN is working on a paper which looks at extensions to TOPS 20 which would have enhanced its capabilities. 2. Frank da Cruz and Columbia are summarizing 10 years of experience and development of TOPS 20 systems. Some effort will also be made to detail the process which lead to their selection of a follow-on architecture to TOPS 20. There is a need to develop additional topics which represent the use and application of the technology (TOPS 10/20) in other areas. Specific recommendations are welcome as are proposals to develop them. A short abstract should accompany any such proposal. Every effort will be made to work with individuals or organizations interested in making such a contribution. There will be a standalone (no network connections) DECSYSTEM 2020 (YIPYIP) dedicated to supporting the project. This system has a 3 line hunt group, with all lines accessible from a single number (201.874.8612). Both YIPYIP and MARKET will have "public" directories for remote login (DEMPSTER.PROJECT-10262 LCGLCG). MARKET can be accessed by modem (617.467.7437), however disk quota is limited. MARKET's primary purpose is ARPAnet TELNET access. YIPYIP is a dedicated PROJECT-10262 system. MAIL can also be sent to DEMPSTER on either system. YIPYIP and MARKET will keep a running summary of ideas and comments up on Columbia's BBOARD software. KERMIT also runs on each system for uploads. SAIL.STANFORD.EDU will support ARPAnet transfers to a "public" area: FTP CONNECT SAIL.STANFORD.EDU SEND AFN.EXT DSK: AFN.EXT [PUB,LES] SAIL runs WAITS, an operating system similiar to TOPS 10. File names are limited to 6 characters and extensions limited to 3. Implementation details: 1. User input is welcomed and desired from all application and geographic areas. 2. Input from past and present developers is also desired. 3. Throughout the project a secondary goal will be to build a list of users/locations (installation date, duration and disposition) of PDP-6 and KA, KI, KL and KS systems. Serial numbers, if available, are requested. 4. We anticipate that this project will generate a large volume of information (which we hope will arrive electronically). Some information, for any number of reasons, may not be in line with the project's stated goals. Therefore, all notes, interview material and submissions will be donated to the Computer Museum in Boston at the the completion of the project to be available for future reference and research. Ideas, contributions, suggestions and criticism are welcome. As these 36 bit systems were the products of a multitude of people, so too will be the writing of their history. -------- 18-Mar-87 14:25:50-PST,1639;000000000001 Return-Path: Received: from R20.UTEXAS.EDU by SCORE.STANFORD.EDU with TCP; Wed 18 Mar 87 14:23:36-PST Date: Wed 18 Mar 87 16:26:42-CST From: Betsy Ramsey Subject: Daylight Savings Time To: TOPS-20@SCORE.STANFORD.EDU Organization: American Mathematical Society Message-ID: <12287458728.9.G.RAMSEY@R20.UTEXAS.EDU> Apparantly there *is* a daylight savings time patch; it's in the AP15 monitor. Here's the extract from the T26V61.D15 file: EDIT 7388 FOR MONITOR V6.1 [SYMPTOM] New law states that daylight savings time in 1987 will start on the first Sunday in April as to the current law of last Sunday in April. [DIAGNOSIS] Currently, daylight savings time starts in last Sunday in April and there is no code to implement the new law. [CURE] Add code in routine NLSS to check whether the new or the old law applies (base on the year) and return the first or last Sunday in April as the day DST is to be started. ------- (Does anyone know if this patch has been published? I couldn't find it in a quick skim of the dispatches.) For non-source sites running pre-AP15 monitors, TSC provided the following patch: In module DATIME, change the contents of location DSTON from 167 octal to 141 octal. Here's a photo of this patch using my AP13 monitor: @ENABLE $GET SYSTEM:MONITR.EXE $START 140 DDT datime$: dston/ INCODL+2 =167 141 ^Z $SAVE SYSTEM:NEW-MONITR.EXE NEW-MONITR.EXE.1 Saved $DISABLE I have not actually applied or tested this patch. ------- 18-Mar-87 14:48:33-PST,997;000000000001 Return-Path: <@MCC.COM:Billy@Mcc.Com> Received: from MCC.COM by SCORE.STANFORD.EDU with TCP; Wed 18 Mar 87 14:48:06-PST Received: from Otus.Ai.Mcc.Com by MCC.COM with TCP; Wed 18 Mar 87 16:49:46-CST Received: by Otus.Ai.Mcc.Com (1.1/SMI-3.0DEV3) id AA06281; Wed, 18 Mar 87 16:51:02 CST Date: Wed, 18 Mar 87 16:51:02 CST From: Billy Brown Message-Id: <8703182251.AA06281@Otus.Ai.Mcc.Com> To: G.Ramsey@R20.UTEXAS.EDU, TOPS-20@SCORE.STANFORD.EDU Subject: Re: Daylight Savings Time We're using the following patch (5.4 monitor) that works... NLSS: MOVE E,BB ;DATE TODAY SUB E,D ;-DAY OF YEAR TODAY = BEG OF YEAR ADD E,DSTON ;LAST POSSIBLE DAY FOR DST START HLRZ F,B ;[*] GET YEAR CAIL F,^D1987 ;[*] 1987 OF AFTER? SUBI E,^D23 ;[*] YES, USE FIRST SUNDAY INSTEAD OF LAST ADDI E,DWFUDG+^D701 ;+1 TO MAKE SUNDAY, NOT MONDAY, =0. 20-Mar-87 10:31:59-PST,571;000000000000 Return-Path: Received: from Sierra.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 20 Mar 87 10:31:50-PST Date: Fri 20 Mar 87 10:34:23-PST From: Stu Grossman Subject: New fix for IPFREE To: su-tops-20@Score.Stanford.EDU Message-ID: <12287940723.13.GROSSMAN@Sierra.Stanford.EDU> I have just fixed a fencepost error in IPFREE.MAC. This problem normally results in INTSUCs, but other forms of IP free space corruption are possible. The new source is on SIERRA::M61:IPFREE.MAC. Stu ------- 20-Mar-87 11:05:15-PST,1926;000000000000 Return-Path: <@SUMEX-AIM.STANFORD.EDU:MRC@PANDA> Received: from SUMEX-AIM.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Fri 20 Mar 87 11:02:47-PST Received: from PANDA by SUMEX-AIM.STANFORD.EDU with Cafard; Fri 20 Mar 87 11:04:34-PST Return-Path: <@SUMEX-AIM,@Score.Stanford.EDU,@wiscvm.wisc.edu:REWILBUR@SUNRISE.BITNET> Received: from SUMEX-AIM by PANDA with Cafard; Fri 20 Mar 87 09:51:02-PST Received: from Score.Stanford.EDU by SUMEX-AIM.STANFORD.EDU with TCP; Fri 20 Mar 87 09:05:56-PST Received: from wiscvm.wisc.edu by SCORE.STANFORD.EDU with TCP; Fri 20 Mar 87 09:03:02-PST Received: from SUNRISE.BITNET by wiscvm.wisc.edu on 03/20/87 at 11:04:13 CST Date: Fri, 20 Mar 87 12:03 EST From: (Richard E. Wilbur) Subject: SPSS under TOPS To: admin.mrc@su-score.arpa X-Original-To: "admin.mrc@su-score.arpa", REWILBUR ReSent-Date: Fri 20 Mar 87 10:58:57-PST ReSent-From: Mark Crispin ReSent-To: TOPS-20@Score.Stanford.EDU ReSent-Message-ID: <12287945197.8.MRC@PANDA> To TOPS-20 list coordinator: If appropriate, can you forward this message to the TOPS-20 list please? We have a faculty member here at Syracuse who has some SPSS system files which were written using SPSS on a TOPS-20 system at another site. Since the time the files were written, that site has replaced its DEC-20. In order to recover the data, the files need to be read back in using SPSS under TOPS, and rewritten as formatted data files. The procedure is straight forward, but we need to find a TOPS site running SPSS that would be willing to reformat the data. Any assistance would be appreciated. Since I am not a member of the list, please reply directly to me. Richard E. Wilbur Computing and Network Services Syracuse University 210 Machinery Hall Syracuse, NY 13244 (315) 423-3817 REWILBUR@SUNRISE.BITNET 22-Mar-87 01:53:37-PST,3711;000000000000 Return-Path: <@SUMEX-AIM.STANFORD.EDU:MRC@PANDA> Received: from SUMEX-AIM.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Sun 22 Mar 87 01:52:37-PST Received: from PANDA by SUMEX-AIM.STANFORD.EDU with Cafard; Sun 22 Mar 87 01:50:40-PST Date: Sat 21 Mar 87 22:40:42-PST From: Mark Crispin Subject: real solution to the summer time madness To: TOPS-20@Score.Stanford.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12288335089.10.MRC@PANDA> Here is the fix I use for the new law. Note that all you have to do when Congress plays around again is make an addition to the RULES macro. Enjoy! -- Mark -- **** FILE DATIME.MAC ;;; This represents an attempt to make it easier to change the ;;; summer time rules to reflect the latest games Congress chooses ;;; to play with when summer time starts and ends. In theory, you ;;; should be able to make an appropriate addition to the RULES ;;; macro. Of course, if your country doesn't play along by US law, ;;; you will have to make some additional modifications. ;;; Note that VAX/VMS doesn't have any algorithm for summer time! RADIX <5+5> ;DECIMAL RADIX ;;; First and last Sundays of certain useful months FSTJAN==7-1 ;FIRST SUNDAY IN JANUARY LSTFEB==31+29-1 ;LAST SUNDAY IN FEBRUARY FSTAPR==31+29+31+7-1 ;FIRST SUNDAY IN APRIL LSTAPR==31+29+31+30-1 ;LAST SUNDAY IN APRIL LSTOCT==31+29+31+30+31+30+31+31+30+31-1 ;LAST SUNDAY IN OCTOBER DEFINE RULES < DST 1987,FSTAPR,LSTOCT DST 1976,LSTAPR,LSTOCT DST 1975,LSTFEB,LSTOCT DST 1974,FSTJAN,LSTOCT DST 1967,LSTAPR,LSTOCT ;;; Prior to 1967 there was no uniform application of DST in the USA, ;;; although most areas used the "last Sunday in April until last Sunday ;;; in October" rule. There was also "war time" during WW II... This ;;; entry is here for easy patching DST 1946,LSTAPR,LSTOCT >;DEFINE RULES DEFINE DST(YEAR,START,END) DSTBGN::RULES DEFINE DST(YEAR,START,END) DSTON:: RULES DEFINE DST(YEAR,START,END) DSTOFF::RULES NRULES==.-DSTOFF IFE NRULES, ;SANITY CHECK RADIX <4+4> ;BACK TO OCTAL **** FILE DATIME.DEC DSTBGN::^D1975 DSTON:: ^D<31+29+31+30>-1 ;LAST SUNDAY IN APRIL DSTOFF:^D<31+29+31+30+31+30+31+31+30+31>-1 ;LAST SUNDAY IN OCTOBER *************** **** FILE DATIME.MAC MOVSI F,-NRULES ;INDEX INTO RULES TABLE DO. CAML E,DSTBGN(F) ;IS THIS RULE VALID FOR THIS YEAR? EXIT. ;YES, USE IT FOR SUMMER TIME AOBJN F,TOP. ;TRY NEXT RULE JRST ODAY9 ;NO SUMMER TIME ENDDO. **** FILE DATIME.DEC CAMGE E,DSTBGN ;AFTER CURRENT LAW WENT INTO EFFECT? JRST ODAY9 ;NO, NO DST *************** **** FILE DATIME.MAC MOVSI F,-NRULES ;INDEX INTO RULES TABLE DO. CAML E,DSTBGN(F) ;IS THIS RULE VALID FOR THIS YEAR? EXIT. ;YES, USE IT FOR SUMMER TIME AOBJN F,TOP. ;TRY NEXT RULE JRST ODAY9 ;NO SUMMER TIME ENDDO. **** FILE DATIME.DEC CAMGE E,DSTBGN ;AFTER LAW WENT INTO EFFECT? JRST ODAY9 ;NO, NO DST *************** **** FILE DATIME.MAC ;CALLED WITH RULE INDEX IN F NLSS: MOVE E,BB ;DATE TODAY SUB E,D ;-DAY OF YEAR TODAY = BEG OF YEAR ADD E,DSTON(F) ;LAST POSSIBLE DAY FOR DST START **** FILE DATIME.DEC NLSS: MOVE E,BB ;DATE TODAY SUB E,D ;-DAY OF YEAR TODAY = BEG OF YEAR ADD E,DSTON ;LAST POSSIBLE DAY FOR DST START *************** **** FILE DATIME.MAC MOVE F,DSTOFF(F) ;LAST POSSIBLE DAY FOR DST END ADD F,BB SUB F,D **** FILE DATIME.DEC MOVE F,BB SUB F,D ADD F,DSTOFF ;LAST POSSIBLE DAY FOR DST END *************** ------- 22-Mar-87 16:23:58-PST,5699;000000000000 Return-Path: <@SUMEX-AIM.STANFORD.EDU:MRC@PANDA> Received: from SUMEX-AIM.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Sun 22 Mar 87 16:23:14-PST Received: from PANDA by SUMEX-AIM.STANFORD.EDU with Cafard; Sun 22 Mar 87 16:19:14-PST Date: Sun 22 Mar 87 15:46:36-PST From: Mark Crispin Subject: latest and greatest summer time patch! To: TOPS-20@Score.Stanford.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12288521849.6.MRC@PANDA> This patch accounts for the two "war times" during WWI and WWII and also fixes a bug in NLSS where F (the index into the rules) was clobbered by an IDIVI. So install this patch instead of the one I sent earlier. Note that the second edit is installed in two places in the code, one for IDTIM and one for ODTIM. ***** DATIME.DEC DSTBGN::^D1975 DSTON:: ^D<31+29+31+30>-1 ;LAST SUNDAY IN APRIL DSTOFF:^D<31+29+31+30+31+30+31+31+30+31>-1 ;LAST SUNDAY IN OCTOBER ***** DATIME.MAC ;;; This represents an attempt to make it easier to change the ;;; summer time rules to reflect the latest games Congress chooses ;;; to play with when summer time starts and ends. In theory, you ;;; should be able to make an appropriate addition to the RULES ;;; macro. Of course, if your country doesn't play along by US law, ;;; you will have to make some additional modifications. ;;; Note that VAX/VMS doesn't have any algorithm for summer time! RADIX <5+5> ;DECIMAL RADIX ;;; First and last Sundays of certain useful months FSTJAN==7-1 ;FIRST SUNDAY IN JANUARY LSTFEB==31+29-1 ;LAST SUNDAY IN FEBRUARY LSTMAR==31+29+31-1 ;LAST SUNDAY IN MARCH FSTAPR==31+29+31+7-1 ;FIRST SUNDAY IN APRIL LSTAPR==31+29+31+30-1 ;LAST SUNDAY IN APRIL LSTSEP==31+29+31+30+31+30+31+31+30-1 ;LAST SUNDAY IN SEPTEMBER LSTOCT==31+29+31+30+31+30+31+31+30+31-1 ;LAST SUNDAY IN OCTOBER DEFINE RULES < DST 1987,FSTAPR,LSTOCT ;; Changed again DST 1976,LSTAPR,LSTOCT ;; Energy conservation legislation expired ;; Note: contrary to what some people (and certain operating systems) believe, ;; there was not year-round DST in 1974. At the last minute Congress restored ;; the end-of-October restoration of standard time. DST 1975,LSTFEB,LSTOCT ;; Rule changed in October 1974 DST 1974,FSTJAN,LSTOCT ;; Energy conservation emergency DST 1967,LSTAPR,LSTOCT ;; Congress established national standard ;;; Prior to 1967 there was no uniform application of DST in the USA, ;;; although many areas used the "last Sunday in April until last Sunday ;;; in October" rule. These entries cannot be taken seriously. DST 1946,LSTAPR,LSTOCT ;; assumes you had DST ; DST 1946,400,400 ;; this would probably be better DST 1945,0,LSTSEP ;; WWII "War Time" ended Sunday 30 Sep 45 DST 1943,0,400 ;; WWII "War Time" was all year 1943-1944 DST 1942,31+9,400 ;; WWII "War Time" started Monday 9 Feb 42 DST 1920,400,400 ;; no real standard existed DST 1918,LSTMAR,LSTOCT ;; temporary summer time during WWI >;DEFINE RULES DEFINE DST(YEAR,START,END) DSTBGN::RULES DEFINE DST(YEAR,START,END) DSTON:: RULES DEFINE DST(YEAR,START,END) DSTOFF::RULES NRULES==.-DSTOFF IFE NRULES, ;SANITY CHECK RADIX <4+4> ;BACK TO OCTAL ***** Note!! This change is installed in TWO places in the code ***** ***** DATIME.DEC CAMGE E,DSTBGN ;AFTER CURRENT LAW WENT INTO EFFECT? JRST ODAY9 ;NO, NO DST ***** DATIME.MAC MOVSI F,-NRULES ;INDEX INTO RULES TABLE DO. CAML E,DSTBGN(F) ;IS THIS RULE VALID FOR THIS YEAR? EXIT. ;YES, USE IT FOR SUMMER TIME AOBJN F,TOP. ;TRY NEXT RULE JRST ODAY9 ;NO SUMMER TIME ENDDO. ***** Remember!! Install this twice ***** ***** DATIME.DEC NLSS: MOVE E,BB ;DATE TODAY SUB E,D ;-DAY OF YEAR TODAY = BEG OF YEAR ADD E,DSTON ;LAST POSSIBLE DAY FOR DST START ADDI E,DWFUDG+^D701 ;+1 TO MAKE SUNDAY, NOT MONDAY, =0. ;700 IS ARBITRARY MULTIPLE OF 7 TO MAKE SURE ;QUANTITY IS POSITIVE DURING DIVISION EVEN ;IN 1858, WHEN NLSAPR AND NLSOCT ARE NEGATIVE. IDIVI E,7 ;DIVIDE INTO WEEKS AND DAY OF WEEKS IMULI E,7 ;CONVERT BACK, DISCARDING DAY OF WEEK SUBI E,DWFUDG+^D701 ;UNFUDGE AND WE'VE GOT IT! ;DATE OF LAST SUNDAY IN OCTOBER (NLSOCT) THIS YEAR TO F. MOVE F,BB SUB F,D ADD F,DSTOFF ;LAST POSSIBLE DAY FOR DST END ADDI F,DWFUDG+^D701 IDIVI F,7 IMULI F,7 SUBI F,DWFUDG+^D701 RET ***** DATIME.MAC NLSS: MOVE E,BB ;DATE TODAY SUB E,D ;-DAY OF YEAR TODAY = BEG OF YEAR ADD E,DSTON(F) ;LAST POSSIBLE DAY FOR DST START CALL NLEAP ;IS IT A LEAP YEAR? SKIPA ;YES SUBI E,1 ;NO, CAN'T BE SUNDAY, MAY 1! PUSH P,DSTOFF(F) ;SAVE RETURN TIME MOVE F,DSTBGN(F) ;GET YEAR CAIE F,^D1942 ;WAR TIME STARTED ON A MONDAY IFSKP. ADDI E,DWFUDG+^D700 ;SO DON'T ADJUST FOR SUNDAY FOR THIS YEAR! IDIVI E,7 IMULI E,7 SUBI E,DWFUDG+^D700 ELSE. ADDI E,DWFUDG+^D701 ;+1 TO MAKE SUNDAY, NOT MONDAY, =0. ;700 IS ARBITRARY MULTIPLE OF 7 TO MAKE SURE ;QUANTITY IS POSITIVE DURING DIVISION EVEN ;IN 1858, WHEN NLSAPR AND NLSOCT ARE NEGATIVE. IDIVI E,7 ;DIVIDE INTO WEEKS AND DAY OF WEEKS IMULI E,7 ;CONVERT BACK, DISCARDING DAY OF WEEK SUBI E,DWFUDG+^D701 ;UNFUDGE AND WE'VE GOT IT! ENDIF. ;DATE OF LAST SUNDAY IN OCTOBER (NLSOCT) THIS YEAR TO F. POP P,F ;LAST POSSIBLE DAY FOR DST END ADD F,BB SUB F,D CALL NLEAP ;IS IT A LEAP YEAR? SKIPA ;YES SUBI F,1 ;NO, CAN'T BE SUNDAY, NOVEMBER 1! ADDI F,DWFUDG+^D701 IDIVI F,7 IMULI F,7 SUBI F,DWFUDG+^D701 RET ------- 22-Mar-87 23:39:46-PST,965;000000000000 Return-Path: <@SUMEX-AIM.STANFORD.EDU:MRC@PANDA> Received: from SUMEX-AIM.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Sun 22 Mar 87 23:39:17-PST Received: from PANDA by SUMEX-AIM.STANFORD.EDU with Cafard; Sun 22 Mar 87 23:41:09-PST Date: Sun 22 Mar 87 23:36:38-PST From: Mark Crispin Subject: %Error reading HOME block on device To: TOPS-20@Score.Stanford.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12288607417.7.MRC@PANDA> If you get the subject message ever time you spin up a disk drive in the new monitor you've just built, it may be because the CHBHB1/CHBHB2 vector (200 words in all) is split across a page boundary. I don't know if this happens on KL's, but on 2020's this seems to provoke the RH11 into getting a channel NXM. A possible fix is to move CHBHB1 and CHBHB2's definitions in STG.MAC to after the definition of CST5. ------- 23-Mar-87 13:41:05-PST,583;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SCORE.STANFORD.EDU with TCP; Mon 23 Mar 87 13:38:14-PST Date: Mon 23 Mar 87 16:41:20-EST From: Ittai Hershman Subject: Re: bug in 6.1 ap14: re: incompletely created files... To: Tops-20@SCORE.STANFORD.EDU Message-ID: <12288761189.32.NYU.ITTAI@CU20B.COLUMBIA.EDU> A friend who has a TSC contract passed along the following patch: delfil+17/move a,.fbctl(d) for AP14 monitors. It is appearently fixed in AP15. I have not tested it... -Ittai ------- 23-Mar-87 16:17:36-PST,1756;000000000001 Return-Path: Received: from XX.LCS.MIT.EDU by SCORE.STANFORD.EDU with TCP; Mon 23 Mar 87 16:16:58-PST Date: Mon 23 Mar 87 19:19:23-EST From: Betsy Ramsey Subject: Arpanet Monitor Parameters To: TOPS-20@SCORE.STANFORD.EDU Organization: American Mathematical Society Message-ID: <12288789962.55.EWR@XX.LCS.MIT.EDU> I'm trying to maximize the number of free pages in my Autopatch 15 AN/DECnet MONMAX monitor because I run AMAR, and it needs 24 snoop pages. I can get 24 free pages by eliminating unneeded device support and reducing the number of JSB free pages as follows (these are the actual values from my PARAM0 file; the changed values are marked with an asterisk): * NJOBS==:^D128 IPNIN==:1 NTTPTY==:^D50 * IPCIN==:0 * NTTLAH==:^D128 * NTTTVT==:^D32 * NDHL==:^D32 * NTTCTH==:^D10 SSPT==:5000 PCDPN==:0 NDST==:^D20000 CDPN==:0 MAXCOR==:20000 PLTN==:0 * STRN==:^D16 SPLTN==:0 * MXSTRU==:3 * LPTN==:1 SWDST==:^D15000 * FELPTN==:1 EXADF==:-1 * CDRN==:0 * NJSBPG==:^D36 * FECDRN==:0 DCN==:1 * MTAN==:2 NETN==:1 * FEN==:2 * ANXN==:0 My concern is with the JSB free pages. Am I likely to get into trouble reducing this value to ^d36? (It was ^d40 in the default DECnet/AN parameter file, and is ^d50 in the default non-AN parameter file.) Is there anything else I should worry about? (I have not tested the monitor at all -- I'm still in the process of building it. I am not a source site.) ------- 24-Mar-87 10:18:32-PST,1684;000000000000 Return-Path: Received: from SRI-STRIPE.ARPA by SCORE.STANFORD.EDU with TCP; Tue 24 Mar 87 10:17:04-PST Date: Tue 24 Mar 87 10:19:38-PST From: David L. Edwards Subject: AMAR-20 version 4.3 available To: tops-20@SCORE.STANFORD.EDU Message-ID: <12288986614.14.DLE@SRI-STRIPE.ARPA> AMAR-20 has been revised for version 6.1 and is now available via anonymous FTP from KL.SRI.COM (aka SRI-KL.ARPA). PS: contains all of the files/programs required for AMAR. There are 40 files totalling 1663 pages. PS: contains all documentation for AMAR. (69 files/747 pages) PS: contains sources, binaries etc. These are not required to be able to use AMAR. (135 files/3209 pages) Many files in are duplicated in but I decided not to remove them so as to match the distribution tape. Additionally, I have created an AMAR-USERS mailing address to share problems and improvements. If you are interested in being placed on the mailing list, send a request to AMAR-USERS-REQUEST@KL.SRI.COM. For those who are unaware of what AMAR is, I quote the description from the recent DECUS product revision announcement... "AMAR-20 is a unique performance tool that was formerly a Digital Equipment Corporation product. AMAR-20 maintains two very distinct data bases; one records operating system performance metrics; the other characterizes the timesharing workload. AMAR-20 retains data at user specified granularity which allows for easy analysis and problem identification." AMAR-20 is also available via DECUS (617)480-3418. -dle ------- 29-Mar-87 14:05:30-PST,1147;000000000000 Return-Path: <@SUMEX-AIM.STANFORD.EDU:MRC@PANDA> Received: from SUMEX-AIM.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Sun 29 Mar 87 14:02:52-PST Received: from PANDA by SUMEX-AIM.STANFORD.EDU with Cafard; Sun 29 Mar 87 14:03:48-PST Date: Sun 29 Mar 87 12:53:42-PST From: Mark Crispin Subject: ILMNRF bughlt caused by WINDOW program To: TOPS-20@Score.Stanford.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12290325381.8.MRC@PANDA> This may or may not be applicable to 6.1 monitors; it is applicable to all 5.x monitors with EDIT 6686 of 31-Jan-85 installed. Edit 6686 added a call to TTYIN3 in a path which could have either a JFN or a .TTDES+tty# designator in JFN. Since TTYIN3 only expected JFN's, it would get an ILMNRF trying to access things like FILDDN(JFN). The fix is to insert CAIL JFN,400000 ;JFN or 400000+LINE NUMBER? JRST TTYIN0 ;TERMINAL DESIGNATOR as the first two instructions of the TTYIN3 routine in FILMSC.MAC. At least on PANDA, the bug could be reproduced by running the WINDOW program. ------- 30-Mar-87 13:00:05-PST,1583;000000000000 Return-Path: <@SUMEX-AIM.STANFORD.EDU:MRC@PANDA> Received: from SUMEX-AIM.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Mon 30 Mar 87 12:56:49-PST Received: from PANDA by SUMEX-AIM.STANFORD.EDU with Cafard; Mon 30 Mar 87 12:57:12-PST Date: Mon, 30 Mar 87 11:03:35 PST From: Mark Crispin Subject: RFC 822 format date/time To: TOPS-20@Score.Stanford.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12290567479.6.MRC@PANDA> I have gotten tired of waiting for DEC to define an ODTIM% bit for RFC 822 format bits, so I have defined one myself. Bit 35 in AC 3 in ODTIM% and AC 5 of ODTNC% is the RFC 822 format flag (modulo the -1 rule for flags). If set, the effect is as if OT%DAY, OT%SPA, OT%TMZ, and OT%SCL are set, with the following modifications: (1) a comma is inserted after the day, (2) a space delimits the timezone instead of a hyphen. For example, in DEC monitors the closest you can get to RFC 822 is: Mon 30 Mar 87 11:00:21-PST whereas with the new bit, which I have called OT%822, you get: Mon, 30 Mar 87 11:00:21 PST The mailsystem has been taught to use this new bit. For compatibility with vanilla monitors, the other bits are also set so there is no problem unless you have defined bit 35 in the flags to mean something else. If you have, you had better speak up NOW, or you may get strange behavior with the mailer! I will see what I can do to get DEC to adopt the trivial changes to add OT%822. -- Mark -- ------- 31-Mar-87 15:43:11-PST,1143;000000000000 Return-Path: Received: from bass.nosc.mil by SCORE.STANFORD.EDU with TCP; Tue 31 Mar 87 15:39:09-PST Received: by bass.nosc.mil (5.31/4.7) id AA02528; Tue, 31 Mar 87 15:43:33 PST Received: by humu.ARPA (5.31/4.7) id AA16637; Tue, 31 Mar 87 13:42:57-1000 Received: by uhmanoa.ICS.HAWAII.EDU (5.51/UUCP-Project/rel-1.0/11-09-86) id AA00559; Tue, 31 Mar 87 13:04:50-1000 Message-Id: <8703312304.AA00559@uhmanoa.ICS.HAWAII.EDU> Date: Tue, 31 Mar 87 12:48:01-1000 From: uhccux!uhmanoa!uhmanoa.ICS.HAWAII.EDU!jeff@nosc.mil (Jeffrey Blomberg) To: tops-20@SCORE.STANFORD.EDU Subject: TOPS-20/Ultrix(UNIX) Mail I am having problems getting mail to run from our VAX running Ultrix to the -20 via TCP. The basic problem is that we devised an ID scheme on the -20 of the form DEPT.F-LASTNAME and I am having difficulty figuring how to train sendmail (via sendmail.cf under Ultrix) to handle the periods properly - documentation on this is sparse. Is there anyone in TOPS-20 land willing to share a model sendmail.cf with me which has this problem solved? Aloha. -jeff- 1-Apr-87 01:42:23-PST,1378;000000000000 Return-Path: Received: from SRI-NIC.ARPA by SCORE.STANFORD.EDU with TCP; Wed 1 Apr 87 01:41:00-PST Date: Wed 1 Apr 87 01:44:08-PST From: Mark Lottor Subject: Tops-20 NFS To: tops-20@SCORE.STANFORD.EDU cc: unix-wizards@BRL.ARPA, nowicki@SUN.COM, rusty@SUN.COM Message-ID: <12290989922.17.MKL@SRI-NIC.ARPA> This is an announcement of an implementation of SUN NFS for Tops-20. It is called NFS-20, of course, and the name refers to the whole collection of programs and libraries. The first release, NFS-20 1.0, is a server only. It is a BETA TEST version and it works fairly well. Expect an updated release in a few months. Included with the NFS server are a UDP library, XDR conversion routines, RPC client and server routines, an RPC port mapper, an NFS mount server, an RPCInfo program, and debugging tools. If you want to use a SUN as a client, it will need release 3.0 or better. It has not yet been tested with anything but a SUN client. To get it all, just retrieve everything on SRI-NIC.ARPA in directory PS:. Yes, it's all written in MIDAS. For more info and details read the file NFS.DOC. Also send me a note so I can add you to a bug report/announcement mailing list. I'm interested in comments, suggestions, and bug reports. Nice comments are especially welcome. Mark ------- 1-Apr-87 09:31:43-PST,1607;000000000000 Return-Path: Received: from ohio-state.ARPA by SCORE.STANFORD.EDU with TCP; Wed 1 Apr 87 09:27:57-PST Return-Path: Received: from OSU-20 (osu-20.ARPA) by ohio-state.ARPA (4.12/6.1.OSU-CIS) id AA11777; Wed, 1 Apr 87 12:28:20 est Message-Id: <8704011728.AA11777@ohio-state.ARPA> Date: Wed 1 Apr 87 12:28:23-EST From: Bryan Dunlap Subject: talking to Proteon P4200 To: tops-20%OSU-20@ohio-state.ARPA Please excuse any naivete here; I'm new at this... We are running Stanford's 6.1 monitor on a 2060 which is attached to a class B network made up of subnets attached by Proteon P4200 boxes. We can talk fine to hosts on our own wire (128.146.8.foo), but not to anything on the other side of the Proteon (e.g., 128.146.6.foo). When we try to telnet to a host on the other side, the user gets a 'host not up, network trouble' message and we don't even observe any ARPs coming from the -20 looking for the remote host. None of the things I have tried in HOSTS.TXT or INTERNET.GATEWAYS have helped. Since it will send ARPs if we try a host on 128.146.8.0 that isn't in the ARP table already, it seems that if I get it to treat all of 128.146 the same, it should work. Is there anyone out there who has done this? Someone at Proteon told me MIT had -20s talking to P4200s, but he didn't have any names for me to contact. Any pointers would be greatly appreciated. Bryan Dunlap ARPANET: bcd@ohio-state.arpa UUCP: ...cbosgd!osu-eddie!bcd Phone: 614/292-0886 ------- 1-Apr-87 14:42:10-PST,1697;000000000001 Return-Path: Received: from cs.utah.edu by SCORE.STANFORD.EDU with TCP; Wed 1 Apr 87 14:40:17-PST Received: by cs.utah.edu (5.54/utah-1.0) id AA23286; Wed, 1 Apr 87 15:45:19 MST Date: Wed, 1 Apr 87 15:45:19 MST From: jee@cs.utah.edu (John E. Ellsworth) Message-Id: <8704012245.AA23286@cs.utah.edu> To: tops-20@score.stanford.edu Subject: DEC 2060 for sale The Department of Computer Science at the University of Utah has for immediate sale a DEC System 2060 with ARPA Net Interface, Ethernet Interface, 32 Async Lines, 1-3/4 MW MF Memory, 3 RH20s, and 2 add-on Unibus Adapters (remember utah-20). For sale as a system: CPU cabinet: KL10-PM CPU KL-10PV Extended Addressing 3 each RH20 Internal Channels 2 each DTE-20 add-on unibus adapters Expansion Cabinet: MCA20 Cache memory MG20-LC 1 Megaword Int/Ext Second Mem. 60Hz MF20 Mem 756K words Front end cabinet: RX01 Floppies PDP11/40 CPU Cabinet 64K words memory RH11 MassBuss PDP11/40 Expansion Cabinet DH/DM DH (DM available) Additional items: NIA20-AA Ethernetport AdaptKL10-E 120V AN20-AA ARPA Network Interface RP06 Disk Drive 256K words MF memory The above equipment is available immediately, and has been under continuous DEC maintenance coverage. Buyer will provide de-installation, packing, and shipping. DEC de-installation and certification is available at buyers expense. Equipment is sold "as-is" and payment is due in full prior to receipt of equipment. Send all inquiries and offers in written form to: Mr. Paul Madsen Property Management University of Utah Building 437 Salt Lake City, Utah 84112 1-Apr-87 16:35:15-PST,8495;000000000000 Return-Path: Received: from MCC.COM by SCORE.STANFORD.EDU with TCP; Wed 1 Apr 87 16:31:25-PST Date: Wed 1 Apr 87 18:34:47-CST From: Clive Dawson Subject: Final(?) Solution to vanishing IP Free Space To: tops20@SCORE.STANFORD.EDU Message-ID: <12291152060.19.AI.CLIVE@MCC.COM> I finally decided to get serious about tracking down the vanishing IP free space problem which has been plaguing many sites for months. The most common symptom reported was a rash of IPGCOL's and INTFR6's after which the only way to recover was to reload TOPS-20. In the process of tracking down the specific bug which caused all the free space to disappear, I found several other bugs which could produce a variety of related symptoms, including ILLUUO, ILMNRF, and various INTFRx Bughlts. The following set of patches seems to have fixed all of our problems related to IP free space, at least so far. I should mention that I was a bit frustrated after the fact to find that several of these fixes had been known by one site or another for quite a while, although nobody had 'em all. I think this demonstrates the need for a central repository of TOPS-20 patches. Given that most TOPS-20 maintainers on the net that I know of don't submit many SPR's, and given that DEC does not consider problem/fix reports which reach them over the net to be "official", and given that DEC will eventually be out of the picture anyway, it would certainly help to establish a library of bugfixes/enhancements somewhere. But I digress....Here are the IP free space fixes I mentioned. ====================================================================== Problem: Free space disappears, causing continuous IPGCOLs and INTFR6's. System must be reloaded. Diagnosis: A GTJFN% on device TCP: causes a "prototype TCB" to be allocated from IP free space. A subsequent OPENF% causes a "real TCB" to be allocated, and information from the prototype TCB is copied over. Then the prototype TCB is returned to free storage. However, whenever the OPENF% fails because of a shortage of network connections (no more TCB slots), the prototype TCB is not being returned to free space. When the JFN gets released the 128 word block is lost forever. A typical scenario which causes 100K words of free space to disappear in less than 1 minute involves the NETSRV program. When NETSRV opens listening connections on various ports, a failure return from the OPENF% branches immediately to the start of the routine where the GTJFN/OPENF sequence is repeated. This can happen hundreds of times in just a few seconds. Cure: At TCPOP5, return the prototype TCB to free storage. The following patch is one which has apparently been in the Stanford monitor for several years, and is a bit more elaborate than mine: In TCPJFN.MAC, insert the following code at TCPOP5: TCPOP5: ;here on error return from the OPEN% Repeat 1,< ;;; Note that this routine must never be called at any point other than ;;;the ERJMP from the OPEN%. In particular, it assumes that FILTCB has ;;;no relation to any JCN that OPEN% may have made!! hrrzm t1,tcpoer ;save error code ldb t2,[point 5,t1,35] ;get just error byte ldb t1,[point 17,t1,17] ;and possible jcn (without 400000 bit?) ifn. t1 ;have a jcn cain t2,^d6 ;already exists? anskp. ;no txo t1,tcp%js ;it is a jcn abort% ;release it erjmp .+1 endif. skipe t1,filtcb(jfn) ;get tcb prototype address (should never skip) call retblk ;return it to internet free storage move t1,tcpoer ;error code >;Repeat 1 SETZRO ;not blocking now ============================================================================= Problem: ILMNRF BUGHLTs at NQ: when free space is exhausted. Diagnosis: The TRMPKT routine calls GETBLK to allocate a block of storage. If this call fails, a zero is returned in T1, but this result is not saved while T1 is used in a call to the Packet Printer. TRMPKT continues, thinking that T1 has a pointer to a block, when in fact it has a packet printer bit-mask. Cure: In TCPTCP.MAC, replace the following code in the TRMPKT routine: JUMPE T1,[MOVX T1,PT%TKT ; Killed because no space TDNE T1,INTTRC ; Want trace? CALL PRNPKT ; Yes JRST TRMPK9] ; Don't copy into non-X packet with: JUMPE T1,[MOVX T1,PT%TKT ; Killed because no space TDNE T1,INTTRC ; Want trace? CALL PRNPKT ; Yes SETZ T1, ; Restore the 0 in T1 JRST TRMPK9] ; Don't copy into non-X packet Comment: I fully agree with the observation (originally by Bill Westfield, I believe) that the TRMPKT routine fragments IP free space horribly, and therefore shouldn't be called at all. To accomplish this, remove the following two instructions at PRCPK7: CALL TRMPKT ; Trim it size or flush PKT for space JUMPE PKT,PRCPKX ============================================================================= Problem: Occasional failure to allocate storage block, even when storage exists, causing lost free space. Other random problems when storage runs out. Diagnosis: An obvious coding error in IPFREE. The GETBK0 routine returns its result in BLK, but the code at GETBB0 is checking for it in T1. I was curious why such a seemingly serious error hadn't been caught long ago. It turns out that on a successful return from GETBK0, T1 contains a "random" hashing of the block's size and location, which is stored at the head of the block and checked for integrity when the block is returned. I ran a small test and discovered that for the most common block sizes requested, and for all possible block addresses in free space, the hash computation actually returns 0 in about 175 cases. In this unlikely event, a block would be allocated, but the caller would be told it failed. Much more serious is the case where the allocation really does fail, but a successful return is made with a random value which the caller will think is a block of storage. Cure: In IPFREE.MAC, at GETBB0+3, change: JUMPN T1,GETBBX ; Exit if we got the max. size block to JUMPN BLK,GETBBX ; Exit if we got the max. size block Comment: On March 9, Mark Lottor posted a messge to TOPS-20 in which he proposed changes to the AC usage surrounding the two calls to GETBK0. It was his message that led to the discovery of the above bug, which exists only in DEC's version of IPFREE. We have since determined that the problem which Mark observed is limited only to those systems which are running BBN's IPFREE with improvements by Stu Grossman at Stanford. Furthermore, Stu has recently found a simpler patch. ========================================================================== Problem: Occasional failure to allocate blocks of the size requested. Diagnosis: Code which ensures that block sizes are quantized is a bit too conservative. Cure: In IPFREE.MAC, at GETBB2, change CAILE SIZ,BSMALL ; Unless it is a small block, ANDCMI SIZ,BSQUAN-1 ; Round down to the next smaller quantization CAMGE SIZ,MINSIZ ; Is the biggest block acceptable? to: CAILE SIZ,BSMALL ; If it's a small block.. TRNN SIZ,BSQUAN-1 ; ..or an exact quantum, JRST GETBB3 ; then leave it alone. SUBI SIZ,FBLKSZ ; we will need this much extra to split it, CAILE SIZ,BSMALL ; and unless it's now a small block, ANDCMI SIZ,BSQUAN-1 ; round down to the next smaller quantization GETBB3: CAMGE SIZ,MINSIZ ; Is the biggest block acceptable? ============================================================================== Final note: In the process of tracking this stuff down, I made quite a few improvements to the IP debugging code in the IPFDSW conditional. I also have various programs which can examine the state of the free space while the system is running and track various events. (Many thanks to Don Watrous of Rutgers for providing the original program upon which most of these tools were based.) If anybody continues to have IP free space trouble and would like to get some of this stuff, let me know. Clive P.S. Oh, I forgot to mention another important patch which fixes problems with IP buffers and prevents INTFRx's, etc. This is the "negative window" patch posted to TOPS-20 by Andy Sweer from SUMEX on 8-Dec-86. ------- 1-Apr-87 22:34:28-PST,8496;000000000000 Return-Path: Received: from MCC.COM by SCORE.STANFORD.EDU with TCP; Wed 1 Apr 87 22:32:56-PST Date: Thu 2 Apr 87 00:36:18-CST From: Clive Dawson Subject: Final(?) Solution to Vanishing IP Free Space To: tops-20@SCORE.STANFORD.EDU Message-ID: <12291217873.13.AI.CLIVE@MCC.COM> I finally decided to get serious about tracking down the vanishing IP free space problem which has been plaguing many sites for months. The most common symptom reported was a rash of IPGCOL's and INTFR6's after which the only way to recover was to reload TOPS-20. In the process of tracking down the specific bug which caused all the free space to disappear, I found several other bugs which could produce a variety of related symptoms, including ILLUUO, ILMNRF, and various INTFRx Bughlts. The following set of patches seems to have fixed all of our problems related to IP free space, at least so far. I should mention that I was a bit frustrated after the fact to find that several of these fixes had been known by one site or another for quite a while, although nobody had 'em all. I think this demonstrates the need for a central repository of TOPS-20 patches. Given that most TOPS-20 maintainers on the net that I know of don't submit many SPR's, and given that DEC does not consider problem/fix reports which reach them over the net to be "official", and given that DEC will eventually be out of the picture anyway, it would certainly help to establish a library of bugfixes/enhancements somewhere. But I digress....Here are the IP free space fixes I mentioned. ====================================================================== Problem: Free space disappears, causing continuous IPGCOLs and INTFR6's. System must be reloaded. Diagnosis: A GTJFN% on device TCP: causes a "prototype TCB" to be allocated from IP free space. A subsequent OPENF% causes a "real TCB" to be allocated, and information from the prototype TCB is copied over. Then the prototype TCB is returned to free storage. However, whenever the OPENF% fails because of a shortage of network connections (no more TCB slots), the prototype TCB is not being returned to free space. When the JFN gets released the 128 word block is lost forever. A typical scenario which causes 100K words of free space to disappear in less than 1 minute involves the NETSRV program. When NETSRV opens listening connections on various ports, a failure return from the OPENF% branches immediately to the start of the routine where the GTJFN/OPENF sequence is repeated. This can happen hundreds of times in just a few seconds. Cure: At TCPOP5, return the prototype TCB to free storage. The following patch is one which has apparently been in the Stanford monitor for several years, and is a bit more elaborate than mine: In TCPJFN.MAC, insert the following code at TCPOP5: TCPOP5: ;here on error return from the OPEN% Repeat 1,< ;;; Note that this routine must never be called at any point other than ;;;the ERJMP from the OPEN%. In particular, it assumes that FILTCB has ;;;no relation to any JCN that OPEN% may have made!! hrrzm t1,tcpoer ;save error code ldb t2,[point 5,t1,35] ;get just error byte ldb t1,[point 17,t1,17] ;and possible jcn (without 400000 bit?) ifn. t1 ;have a jcn cain t2,^d6 ;already exists? anskp. ;no txo t1,tcp%js ;it is a jcn abort% ;release it erjmp .+1 endif. skipe t1,filtcb(jfn) ;get tcb prototype address (should never skip) call retblk ;return it to internet free storage move t1,tcpoer ;error code >;Repeat 1 SETZRO ;not blocking now ============================================================================= Problem: ILMNRF BUGHLTs at NQ: when free space is exhausted. Diagnosis: The TRMPKT routine calls GETBLK to allocate a block of storage. If this call fails, a zero is returned in T1, but this result is not saved while T1 is used in a call to the Packet Printer. TRMPKT continues, thinking that T1 has a pointer to a block, when in fact it has a packet printer bit-mask. Cure: In TCPTCP.MAC, replace the following code in the TRMPKT routine: JUMPE T1,[MOVX T1,PT%TKT ; Killed because no space TDNE T1,INTTRC ; Want trace? CALL PRNPKT ; Yes JRST TRMPK9] ; Don't copy into non-X packet with: JUMPE T1,[MOVX T1,PT%TKT ; Killed because no space TDNE T1,INTTRC ; Want trace? CALL PRNPKT ; Yes SETZ T1, ; Restore the 0 in T1 JRST TRMPK9] ; Don't copy into non-X packet Comment: I fully agree with the observation (originally by Bill Westfield, I believe) that the TRMPKT routine fragments IP free space horribly, and therefore shouldn't be called at all. To accomplish this, remove the following two instructions at PRCPK7: CALL TRMPKT ; Trim it size or flush PKT for space JUMPE PKT,PRCPKX ============================================================================= Problem: Occasional failure to allocate storage block, even when storage exists, causing lost free space. Other random problems when storage runs out. Diagnosis: An obvious coding error in IPFREE. The GETBK0 routine returns its result in BLK, but the code at GETBB0 is checking for it in T1. I was curious why such a seemingly serious error hadn't been caught long ago. It turns out that on a successful return from GETBK0, T1 contains a "random" hashing of the block's size and location, which is stored at the head of the block and checked for integrity when the block is returned. I ran a small test and discovered that for the most common block sizes requested, and for all possible block addresses in free space, the hash computation actually returns 0 in about 175 cases. In this unlikely event, a block would be allocated, but the caller would be told it failed. Much more serious is the case where the allocation really does fail, but a successful return is made with a random value which the caller will think is a block of storage. Cure: In IPFREE.MAC, at GETBB0+3, change: JUMPN T1,GETBBX ; Exit if we got the max. size block to JUMPN BLK,GETBBX ; Exit if we got the max. size block Comment: On March 9, Mark Lottor posted a messge to TOPS-20 in which he proposed changes to the AC usage surrounding the two calls to GETBK0. It was his message that led to the discovery of the above bug, which exists only in DEC's version of IPFREE. We have since determined that the problem which Mark observed is limited only to those systems which are running BBN's IPFREE with improvements by Stu Grossman at Stanford. Furthermore, Stu has recently found a simpler patch. ========================================================================== Problem: Occasional failure to allocate blocks of the size requested. Diagnosis: Code which ensures that block sizes are quantized is a bit too conservative. Cure: In IPFREE.MAC, at GETBB2, change CAILE SIZ,BSMALL ; Unless it is a small block, ANDCMI SIZ,BSQUAN-1 ; Round down to the next smaller quantization CAMGE SIZ,MINSIZ ; Is the biggest block acceptable? to: CAILE SIZ,BSMALL ; If it's a small block.. TRNN SIZ,BSQUAN-1 ; ..or an exact quantum, JRST GETBB3 ; then leave it alone. SUBI SIZ,FBLKSZ ; we will need this much extra to split it, CAILE SIZ,BSMALL ; and unless it's now a small block, ANDCMI SIZ,BSQUAN-1 ; round down to the next smaller quantization GETBB3: CAMGE SIZ,MINSIZ ; Is the biggest block acceptable? ============================================================================== Final note: In the process of tracking this stuff down, I made quite a few improvements to the IP debugging code in the IPFDSW conditional. I also have various programs which can examine the state of the free space while the system is running and track various events. (Many thanks to Don Watrous of Rutgers for providing the original program upon which most of these tools were based.) If anybody continues to have IP free space trouble and would like to get some of this stuff, let me know. Clive P.S. Oh, I forgot to mention another important patch which fixes problems with IP buffers and prevents INTFRx's, etc. This is the "negative window" patch posted to TOPS-20 by Andy Sweer from SUMEX on 8-Dec-86. ------- 1-Apr-87 22:52:13-PST,8495;000000000000 Return-Path: Received: from MCC.COM by SCORE.STANFORD.EDU with TCP; Wed 1 Apr 87 22:50:57-PST Date: Thu 2 Apr 87 00:54:16-CST From: Clive Dawson Subject: Final(?) solution to vanishing IP free space To: tops20@SCORE.STANFORD.EDU Message-ID: <12291221143.13.AI.CLIVE@MCC.COM> I finally decided to get serious about tracking down the vanishing IP free space problem which has been plaguing many sites for months. The most common symptom reported was a rash of IPGCOL's and INTFR6's after which the only way to recover was to reload TOPS-20. In the process of tracking down the specific bug which caused all the free space to disappear, I found several other bugs which could produce a variety of related symptoms, including ILLUUO, ILMNRF, and various INTFRx Bughlts. The following set of patches seems to have fixed all of our problems related to IP free space, at least so far. I should mention that I was a bit frustrated after the fact to find that several of these fixes had been known by one site or another for quite a while, although nobody had 'em all. I think this demonstrates the need for a central repository of TOPS-20 patches. Given that most TOPS-20 maintainers on the net that I know of don't submit many SPR's, and given that DEC does not consider problem/fix reports which reach them over the net to be "official", and given that DEC will eventually be out of the picture anyway, it would certainly help to establish a library of bugfixes/enhancements somewhere. But I digress....Here are the IP free space fixes I mentioned. ====================================================================== Problem: Free space disappears, causing continuous IPGCOLs and INTFR6's. System must be reloaded. Diagnosis: A GTJFN% on device TCP: causes a "prototype TCB" to be allocated from IP free space. A subsequent OPENF% causes a "real TCB" to be allocated, and information from the prototype TCB is copied over. Then the prototype TCB is returned to free storage. However, whenever the OPENF% fails because of a shortage of network connections (no more TCB slots), the prototype TCB is not being returned to free space. When the JFN gets released the 128 word block is lost forever. A typical scenario which causes 100K words of free space to disappear in less than 1 minute involves the NETSRV program. When NETSRV opens listening connections on various ports, a failure return from the OPENF% branches immediately to the start of the routine where the GTJFN/OPENF sequence is repeated. This can happen hundreds of times in just a few seconds. Cure: At TCPOP5, return the prototype TCB to free storage. The following patch is one which has apparently been in the Stanford monitor for several years, and is a bit more elaborate than mine: In TCPJFN.MAC, insert the following code at TCPOP5: TCPOP5: ;here on error return from the OPEN% Repeat 1,< ;;; Note that this routine must never be called at any point other than ;;;the ERJMP from the OPEN%. In particular, it assumes that FILTCB has ;;;no relation to any JCN that OPEN% may have made!! hrrzm t1,tcpoer ;save error code ldb t2,[point 5,t1,35] ;get just error byte ldb t1,[point 17,t1,17] ;and possible jcn (without 400000 bit?) ifn. t1 ;have a jcn cain t2,^d6 ;already exists? anskp. ;no txo t1,tcp%js ;it is a jcn abort% ;release it erjmp .+1 endif. skipe t1,filtcb(jfn) ;get tcb prototype address (should never skip) call retblk ;return it to internet free storage move t1,tcpoer ;error code >;Repeat 1 SETZRO ;not blocking now ============================================================================= Problem: ILMNRF BUGHLTs at NQ: when free space is exhausted. Diagnosis: The TRMPKT routine calls GETBLK to allocate a block of storage. If this call fails, a zero is returned in T1, but this result is not saved while T1 is used in a call to the Packet Printer. TRMPKT continues, thinking that T1 has a pointer to a block, when in fact it has a packet printer bit-mask. Cure: In TCPTCP.MAC, replace the following code in the TRMPKT routine: JUMPE T1,[MOVX T1,PT%TKT ; Killed because no space TDNE T1,INTTRC ; Want trace? CALL PRNPKT ; Yes JRST TRMPK9] ; Don't copy into non-X packet with: JUMPE T1,[MOVX T1,PT%TKT ; Killed because no space TDNE T1,INTTRC ; Want trace? CALL PRNPKT ; Yes SETZ T1, ; Restore the 0 in T1 JRST TRMPK9] ; Don't copy into non-X packet Comment: I fully agree with the observation (originally by Bill Westfield, I believe) that the TRMPKT routine fragments IP free space horribly, and therefore shouldn't be called at all. To accomplish this, remove the following two instructions at PRCPK7: CALL TRMPKT ; Trim it size or flush PKT for space JUMPE PKT,PRCPKX ============================================================================= Problem: Occasional failure to allocate storage block, even when storage exists, causing lost free space. Other random problems when storage runs out. Diagnosis: An obvious coding error in IPFREE. The GETBK0 routine returns its result in BLK, but the code at GETBB0 is checking for it in T1. I was curious why such a seemingly serious error hadn't been caught long ago. It turns out that on a successful return from GETBK0, T1 contains a "random" hashing of the block's size and location, which is stored at the head of the block and checked for integrity when the block is returned. I ran a small test and discovered that for the most common block sizes requested, and for all possible block addresses in free space, the hash computation actually returns 0 in about 175 cases. In this unlikely event, a block would be allocated, but the caller would be told it failed. Much more serious is the case where the allocation really does fail, but a successful return is made with a random value which the caller will think is a block of storage. Cure: In IPFREE.MAC, at GETBB0+3, change: JUMPN T1,GETBBX ; Exit if we got the max. size block to JUMPN BLK,GETBBX ; Exit if we got the max. size block Comment: On March 9, Mark Lottor posted a messge to TOPS-20 in which he proposed changes to the AC usage surrounding the two calls to GETBK0. It was his message that led to the discovery of the above bug, which exists only in DEC's version of IPFREE. We have since determined that the problem which Mark observed is limited only to those systems which are running BBN's IPFREE with improvements by Stu Grossman at Stanford. Furthermore, Stu has recently found a simpler patch. ========================================================================== Problem: Occasional failure to allocate blocks of the size requested. Diagnosis: Code which ensures that block sizes are quantized is a bit too conservative. Cure: In IPFREE.MAC, at GETBB2, change CAILE SIZ,BSMALL ; Unless it is a small block, ANDCMI SIZ,BSQUAN-1 ; Round down to the next smaller quantization CAMGE SIZ,MINSIZ ; Is the biggest block acceptable? to: CAILE SIZ,BSMALL ; If it's a small block.. TRNN SIZ,BSQUAN-1 ; ..or an exact quantum, JRST GETBB3 ; then leave it alone. SUBI SIZ,FBLKSZ ; we will need this much extra to split it, CAILE SIZ,BSMALL ; and unless it's now a small block, ANDCMI SIZ,BSQUAN-1 ; round down to the next smaller quantization GETBB3: CAMGE SIZ,MINSIZ ; Is the biggest block acceptable? ============================================================================== Final note: In the process of tracking this stuff down, I made quite a few improvements to the IP debugging code in the IPFDSW conditional. I also have various programs which can examine the state of the free space while the system is running and track various events. (Many thanks to Don Watrous of Rutgers for providing the original program upon which most of these tools were based.) If anybody continues to have IP free space trouble and would like to get some of this stuff, let me know. Clive P.S. Oh, I forgot to mention another important patch which fixes problems with IP buffers and prevents INTFRx's, etc. This is the "negative window" patch posted to TOPS-20 by Andy Sweer from SUMEX on 8-Dec-86. ------- 2-Apr-87 10:49:08-PST,693;000000000000 Return-Path: Received: from DREA-XX.ARPA by SCORE.STANFORD.EDU with TCP; Thu 2 Apr 87 10:47:56-PST Date: Thu 2 Apr 87 14:49:10-AST From: Perry M. Sisk Subject: C COMPILER FOR TOPS20 To: TOPS20@SCORE.STANFORD.EDU cc: BROOME@DREA-XX.ARPA Phone: (902) 426-3100 x173 Postal-Address: P.O. Box 1012, 9 Grove St., Dartmouth, NS B2Y 3Z7, Canada Message-ID: <12291351288.28.SISK@DREA-XX.ARPA> I am in search of a C language compiler for our DEC20. We are currently running TOPS20 V5.4 but will soon go to V6.1. Does anyone know of such a compiler? Any information on contacts, costs, problems, considerations etc. would be helpful. ------- 2-Apr-87 12:26:26-PST,1863;000000000001 Return-Path: Received: from SRI-NIC.ARPA by SCORE.STANFORD.EDU with TCP; Thu 2 Apr 87 12:25:39-PST Date: Thu 2 Apr 87 12:25:52-PST From: Ken Harrenstien Subject: Re: C COMPILER FOR TOPS20 To: SISK@DREA-XX.ARPA, TOPS20@SCORE.STANFORD.EDU cc: BROOME@DREA-XX.ARPA, KLH@SRI-NIC.ARPA In-Reply-To: <12291351288.28.SISK@DREA-XX.ARPA> Message-ID: <12291368891.33.KLH@SRI-NIC.ARPA> Yes -- in fact, there are several. At SRI-NIC we actively maintain and develop the C compiler known as "KCC", which includes a complete portable library. For more information on the compiler, you can use anonymous FTP to retrieve the file "C:CC.DOC" from SRI-NIC.ARPA; for details on installation, get the file "KCCDIST:INSTAL.DOC". There is a mailing list which you can join by sending a message to INFO-KCC-REQUEST@SRI-NIC.ARPA. KCC completely implements C as per Harbison & Steele's "C: A Reference Manual", which is a superset of K&R. Chars are normally 9 bits, 4 per word. We prefer to distribute it over the net. There is also "NMIT C" from New Mexico Tech, which was derived from a much earlier version of KCC. This implements V7 K&R C. Chars are 7 bits, 5 per word. Distribution charge is $100 for a tape, I believe. Then there is PCC-20 from Utah. Chars are 36 bits, 1 per word. I think a UNIX license is required, which is prohibitive unless you are an educational institution. Finally, I have heard of a product called "Sargasso C" which is licensed and sold like regular software. I don't know what the price is, or where it comes from. Other people may be able to elaborate on the alternatives -- obviously I am biased. We use KCC for most of our applications programming at the NIC, and will be upgrading it to the ANSI draft standard level (if that will just hold still!) ------- 2-Apr-87 22:56:33-PST,1145;000000000000 Mail-From: G.JOESMITH created at 2-Apr-87 22:54:44 Date: Thu 2 Apr 87 22:54:44-PST From: Joe Smith Subject: Daylight savings is easy with a table system. To: tops20@Score.Stanford.EDU Message-ID: <12291483373.10.G.JOESMITH@Score.Stanford.EDU> I noticed all the fuss over the hassles of convincing TOPS20 how to understand the new rules about daylight savings time. The TYMCOM-X operating system (an offshoot of TOPS-10) uses GMT and outputs the date in user-local time. (The local time zone is set on a per-user basis, based on the login info.) The following DDT patch shows how simple it is to change the starting date/time in a table based system. It moves the start up by 3 weeks (21*24 hours). "\DAYLIT.PAT - change to make daylight savings start on 5-Apr-87./ "\This patch applies to TYMCOM-X prior to version P035/B02.\ UUOCON$: DLTTAB+2*1987.-2*1964.[ $Q-21.*24. Has DEC come out with an official solution for TOPS-20? Joe Smith TYMCOM-X Support Group McDonnell Douglas Field Service Company (formerly TYMSHARE) JMS%X930.TYMNET@OFFICE-1.ARPA ------- 3-Apr-87 07:16:18-PST,646;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SCORE.STANFORD.EDU with TCP; Fri 3 Apr 87 07:15:45-PST Date: Fri 3 Apr 87 10:16:36-EST From: Ken Rossman Subject: 11-HALT TTT To: TOPS-20@SCORE.STANFORD.EDU Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 Message-ID: <12291574735.193.SY.KEN@CU20B.COLUMBIA.EDU> We're currently experiencing '11-HALT TTT's on one of our -20's, and this halt code is not documented in any manuals I have currently. We are running RSX-20F V15-50. Anyone else ever see this, and/or know what it is? /Ken ------- 3-Apr-87 10:15:29-PST,1244;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SCORE.STANFORD.EDU with TCP; Fri 3 Apr 87 10:14:19-PST Date: Fri 3 Apr 87 09:10:18-EST From: Betsy Ramsey Subject: .EIRCC Function of NI% Jsys To: TOPS20@SCORE.STANFORD.EDU Organization: American Mathematical Society Message-ID: <12291562664.11.EWR@XX.LCS.MIT.EDU> I'm testing my AP15 TOPS-20 AN monitor. I am running program IPHOST.EXE version 6.1(45), built from the source file on the TCP/IP-20 distribution tape. When I issue privileged IPHOST command ETHERNET STATUS, my system crashes with an ILLUUO bughlt when the program attempts to execute the NI% jsys at NIRCC+16 to return the Ethernet channel counters. It's not clear from the documentation exactly what the arguments to the .EIRCC function should be. IPHOST is assuming that the argument block pointed to by AC1 should look like this: argblk+.EIFCN/ 10,,.EIRCC +1/ : +5/ argblk+.EIAR1/ length of return argblk argblk+.EIAR2/ address of return argblk I can reproduce the bughlt in SDDT by setting up the NI% arguments to look like that and then executing the jsys. Has anyone seen this problem? ------- 3-Apr-87 11:27:57-PST,2023;000000000000 Return-Path: Received: from TOPS20.DEC.COM by SCORE.STANFORD.EDU with TCP; Fri 3 Apr 87 11:24:30-PST Date: 3 Apr 1987 1424-EST From: "Mark Pratt" To: Betsy Ramsey , TOPS20@SCORE.STANFORD.EDU Phone: "617-467-6455, DTN 297-6455" Subject: Re: .EIRCC Function of NI% Jsys Message-ID: <"MS11(6014)+GLXLIB5(0)" 12291619888.29.51.24115 at TOPS20.DEC.COM> References: Message from Betsy Ramsey of 3-Apr-87 1322-EST In-reply-to: <12291562664.11.EWR@XX.LCS.MIT.EDU> It's interesting that you just saw this because I just fixed this bug yesterday. The bug has been there since 85. Luckily only whoprs can induce the bug. Anyway the problem is because someone, thru bad coding practices and misuse of the extended code PSECT macros, caused some code which was supposed to be assembled inline got assembled in a different PSECT. The fix is to get the code in the correct PSECTs but since that can't be fixed with DDT, here is a patch to fix it for you. -- Mark ;DDT PATCH FOR REL 6.1 ; Due to the nature of the code and problem, the ; location which the code should jump to cannot be found ; directly in the .EXE file. Depending upon the version of ; the monitor you are running, the location may be ; different. ; ; Two approximate labels to the same location are: ; ; KILLIS+4 and CTRLOP-40 ; ; The code found at that location is: MOVE T1,FORKX ; ; Before patching, you should verify that the code after ; the location matches the following code: ; ; --> MOVE T1,FORKX ; MOVE T1,FKINT(T1) ; TLNN T1,200000 $GET SYSTEM:MONITR.EXE $START 140 DDT NIURC1+54/ JSP CX,EDMS0 JRST FFF FFF/ 0 JSP CX,EDMS0 FFF+1/ 0 JRST KILLIS+4 FFF+2/ 0 FFF: KILLIS+4/ MOVE T1,FORKX CTRLOP-40/ MOVE T1,FORKX ^Z $SAVE SYSTEM:MONITR.EXE SYSTEM:MONITR.EXE.2 Saved $ -------- 3-Apr-87 13:18:44-PST,873;000000000000 Return-Path: Received: from Sierra.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 3 Apr 87 13:17:30-PST Date: Fri 3 Apr 87 13:19:51-PST From: Stu Grossman Subject: Re: .EIRCC Function of NI% Jsys To: EWR@XX.LCS.MIT.EDU cc: TOPS20@Score.Stanford.EDU In-Reply-To: <12291562664.11.EWR@XX.LCS.MIT.EDU> Message-ID: <12291640863.13.GROSSMAN@Sierra.Stanford.EDU> I suspect that the problem has to do with the NI% JSYS code being moved to XCDSEC. I suspect that you may just have to patch a dispatch table to contain an IFIW or something like that. By the way, I agree with you that the descriptions have some deficiencies. In particular, the descriptions of the functions Read Portal Counters and Read Channel Counters do not describe the arg blocks needed by these functions. Stu ------- 3-Apr-87 17:00:46-PST,1699;000000000000 Return-Path: Received: from cs.utah.edu by SCORE.STANFORD.EDU with TCP; Fri 3 Apr 87 16:59:44-PST Received: by cs.utah.edu (5.54/utah-1.0) id AA21700; Fri, 3 Apr 87 18:04:30 MST Date: Fri, 3 Apr 87 18:04:30 MST From: jee@cs.utah.edu (John E. Ellsworth) Message-Id: <8704040104.AA21700@cs.utah.edu> To: tops-20@score.stanford.edu Subject: DEC 2060 for sale The Department of Computer Science at the University of Utah has for immediate sale a DEC System 2060 with ARPA Net Interface, Ethernet Interface, 32 Async Lines, 1-3/4 MW MF Memory, 3 RH20s, and 2 add-on Unibus Adapters (remember utah-20). For sale as a system: CPU cabinet: KL10-PM CPU KL-10PV Extended Addressing 3 each RH20 Internal Channels 2 each DTE-20 add-on unibus adapters Expansion Cabinet: MCA20 Cache memory MG20-LC 1 Megaword Int/Ext Second Mem. 60Hz MF20 Mem 756K words Front end cabinet: RX01 Floppies PDP11/40 CPU Cabinet 64K words memory RH11 MassBuss PDP11/40 Expansion Cabinet DH/DM DH (DM available) Additional items: NIA20-AA Ethernetport AdaptKL10-E 120V AN20-AA ARPA Network Interface RP06 Disk Drive 256K words MF memory The above equipment is available immediately, and has been under continuous DEC maintenance coverage. Buyer will provide de-installation, packing, and shipping. DEC de-installation and certification is available at buyers expense. Equipment is sold "as-is" and payment is due in full prior to receipt of equipment. Send all inquiries and offers in written form to: Mr. Paul Madsen Property Management University of Utah Building 437 Salt Lake City, Utah 84112 3-Apr-87 18:16:36-PST,1185;000000000000 Return-Path: Received: from SUMEX-AIM.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Fri 3 Apr 87 18:16:33-PST Date: Fri 3 Apr 87 18:07:01-PST From: Andrew Sweer Subject: Re: PUP miscserver time To: Brad@CSLI.STANFORD.EDU, henry@CSLI.STANFORD.EDU cc: su-tops-20@SCORE.STANFORD.EDU In-Reply-To: <12291673964.38.BRAD@CSLI.Stanford.EDU> Message-ID: <12291693138.20.SWEER@SUMEX-AIM.STANFORD.EDU> For those that depend on time info from PUP miscellaneous servers, here is a change to PUPMSV.MAC for the new DST. ; SS:PUPMSV.MAC.58 & SS:PUPMSV.MAC.57 3-Apr-87 1803 PAGE 1 LINE 1, PAGE 1 1) ;PUPMSV.MAC.58, 1-Apr-87 13:16:57, Edit by SWEER 1) ; Change LTPARS DST start day from 121 to 98 1) ;PUPMSV.MAC.57, 27-Aug-85 13:09:13, Edit by LOUGHEED LINE 1, PAGE 1 2) ;PUPMSV.MAC.57, 27-Aug-85 13:09:13, Edit by LOUGHEED LINE 61, PAGE 10 1) LTPARS: BYTE(8) ^D8, 0 (16) ^D98, ^D305 ;CS36 Zone, DST start day, DST e nd day 1) ^L LINE 61, PAGE 10 2) LTPARS: BYTE(8) ^D8, 0 (16) ^D121, ^D305 ;CS36 Zone, DST start day, DST end day ------- 10-Apr-87 16:39:22-PST,889;000000000000 Return-Path: Received: from SUMEX-AIM.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Fri 10 Apr 87 17:39:20-PDT Date: Fri, 10 Apr 87 17:41:51 PDT From: Mark Crispin Subject: new MM To: SU-TOPS-20@SCORE.STANFORD.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12293512642.26.CRISPIN@SUMEX-AIM.STANFORD.EDU> There is a new release of MM-20 on SUMEX-AIM's SS: directory (do not use the stuff since that is local to SUMEX!). This new release has some pretty major changes over what most of Stanford is running. It also supports true RFC 822 date formats, if your monitor is running the latest DATIME.MAC (SUMEX is running it, and I pointed Stu at the SUMEX one, so hopefully it will propagate to the rest of Stanford soon). ------- 12-Apr-87 18:37:47-PST,1722;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SCORE.STANFORD.EDU with TCP; Sun 12 Apr 87 19:34:23-PDT Date: Sun, 12 Apr 87 20:36:52 MDT From: Frank J. Wancho Subject: New version of NCRC for TOPS-20 To: INFO-CPM@SIMTEL20.ARPA, INFO-MICRO@BRL.ARPA, INFO-IBMPC@C.ISI.EDU, ADA-SW@SIMTEL20.ARPA, UNIX-SW@SIMTEL20.ARPA cc: TOPS-20@SCORE.STANFORD.EDU, WANCHO@SIMTEL20.ARPA Message-ID: <12294057869.10.WANCHO@SIMTEL20.ARPA> There is a new version of NCRC (10) in PD:. This version has two new switches: /FORCE and /WRITE. The /WRITE switch (which implies /FORCE) causes the computed CRC value to be stored in the .FBUSW of the FDB. Of course, the user must have write access to the file for this switch to have effect. The /FORCE switch will cause NCRC to compute the value for the file. If the value of that word is non-zero, NCRC will skip the computation and display the value found in the .FBUSW word. All publically readable files on our PD: structure now have that word set with the computed CRC value for that file. If you FTP any of these files directly to another TOPS-20 system, and your FTP program provides the option to retain all FDB information, be sure to turn that option on. The primary motivation for adding this feature was to decrease the amount of time the Archive Server spends processing requests for files which include a CRC listing. In the past few hours this feature has been available, the performance improvement has been rather dramatic. It may, once again, be possible to start seeing a much improved response time instead of the 5-7-day turnaround of the past few weeks. --Frank ------- 14-Apr-87 08:50:19-PST,648;000000000000 Return-Path: Received: from TE.CC.CMU.EDU by SCORE.STANFORD.EDU with TCP; Tue 14 Apr 87 09:46:25-PDT Date: Tue 14 Apr 87 12:51:25-EDT From: David W. Mattis Subject: Backup copy of root directory To: tops-20@SCORE.STANFORD.EDU Message-ID: <12294475579.35.DM6Q@TE.CC.CMU.EDU> All, I have a public structure on a system whose "backup-copy-of-root- directory.image" file is mysterously absent. What I would like to know is 1) how bad a situation this is and 2) how it can be corrected, short of completely rebuilding the structure. Thanks in advance, David W. Mattis ------- 14-Apr-87 09:31:02-PST,994;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SCORE.STANFORD.EDU with TCP; Tue 14 Apr 87 10:29:05-PDT Date: Tue 14 Apr 87 13:30:49-EST From: Ken Rossman Subject: Re: Backup copy of root directory To: DM6Q@TE.CC.CMU.EDU, tops-20@SCORE.STANFORD.EDU In-Reply-To: <12294475579.35.DM6Q@TE.CC.CMU.EDU> Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 Message-ID: <12294493673.86.SY.KEN@CU20B.COLUMBIA.EDU> I have a public structure on a system whose "backup-copy-of-root-directory.image" file is mysterously absent. What I would like to know is 1) how bad a situation this is and 2) how it can be corrected, short of completely rebuilding the structure. I have yet to use this command, but I know it exists from a time when I had to do something similar to fix a busted structure. CHECKD has a command called RECONSTRUCT ROOT-DIRECTORY. Maybe that'll do it for you. /Ken ------- 15-Apr-87 08:11:21-PST,910;000000000000 Return-Path: Received: from ohio-state.ARPA by SCORE.STANFORD.EDU with TCP; Wed 15 Apr 87 09:08:45-PDT Return-Path: Received: from OSU-20 (osu-20.ARPA) by ohio-state.ARPA (4.12/6.1.OSU-CIS) id AA05013; Wed, 15 Apr 87 12:11:43 est Message-Id: <8704151711.AA05013@ohio-state.ARPA> Date: Wed 15 Apr 87 12:11:10-EDT From: Bryan Dunlap Subject: Subnetting and PUP To: tops-20%OSU-20@ohio-state.ARPA We recently turned off subnetting (by setting SUBNTF to 0) to get our -20 to talk to a Proteon P4200 connecting our ethernet to the rest of the university. This has the unfortunate side-effect of breaking PUP. Since we have some Dlions around here that can only use PUPCHAT, we'd like to keep PUP working. Does anyone know of a way around this? It's been less than obvious so far. ==BD ------- 16-Apr-87 12:14:15-PST,1179;000000000000 Return-Path: <@SUMEX-AIM.STANFORD.EDU:MRC@PANDA> Received: from SUMEX-AIM.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Thu 16 Apr 87 13:12:07-PDT Received: from PANDA by SUMEX-AIM.STANFORD.EDU with Cafard; Thu, 16 Apr 87 13:12:43 PDT Return-Path: <@SUMEX-AIM,@Score.Stanford.EDU:CISSELL@A.ISI.EDU> Received: from SUMEX-AIM by PANDA with Cafard; Thu, 16 Apr 87 11:52:09 PDT Received: from Score.Stanford.EDU by SUMEX-AIM.STANFORD.EDU with TCP; Thu, 16 Apr 87 11:05:58 PDT Received: from A.ISI.EDU by SCORE.STANFORD.EDU with TCP; Thu 16 Apr 87 11:03:10-PDT Date: 16 Apr 1987 14:04:24 EDT Subject: BASIC-PLUS-2/20 DOUBLE PRECISION From: David Cissell To: CRISPIN@A.ISI.EDU cc: CISSELL@A.ISI.EDU ReSent-Date: Thu, 16 Apr 87 12:00:16 PDT ReSent-From: Mark Crispin ReSent-To: TOPS-20@Score.Stanford.EDU ReSent-Message-ID: <12295023322.8.MRC@PANDA> WE ARE TRYING TO RUN A BASIC PROGRAM ON A TOPS-20 SYSTEM, BUT HAVE NOT BEEN ABLE TO FIND OUT HOW TO OPERATE THE PROGRAM WITH DOUBLE PRECISION. IF YOU OR OTHERS COULD PROVIDE ANY HELP IN THIS AREA, WE WOULD APPRECIATE IT. THANK YOU FOR YOUR TIME. ------- 17-Apr-87 09:23:17-PST,913;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SCORE.STANFORD.EDU with TCP; Fri 17 Apr 87 10:21:32-PDT Date: Fri 17 Apr 87 13:26:44-EST From: Ittai Hershman Subject: Sharing HSC between VAXen and a DEC-20 To: TOPS-20@SCORE.STANFORD.EDU Message-ID: <12295279362.89.NYU.ITTAI@CU20B.COLUMBIA.EDU> We are in the process of ordering an 8700, with an HSC70. I would like to get rid of all (sans one for the FE) our RP06's and RP07's and have the one HSC control disks (RA60's and RA81's) for both the 2060 and the 8700. I remember DEC saying it should work, and that in fact they had run such a configuration. My question is: has anyone done this? (I understand the limitations and configuration issues, I simply want to know if anyone has tried to do this with 6.1 and what their experiences were...). Thanx, -Ittai ------- 17-Apr-87 10:49:21-PST,1897;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SCORE.STANFORD.EDU with TCP; Fri 17 Apr 87 11:48:18-PDT Date: Fri 17 Apr 87 14:53:52-EST From: Ken Rossman Subject: Re: Sharing HSC between VAXen and a DEC-20 To: NYU.ITTAI@CU20B.COLUMBIA.EDU, TOPS-20@SCORE.STANFORD.EDU In-Reply-To: <12295279362.89.NYU.ITTAI@CU20B.COLUMBIA.EDU> Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 Message-ID: <12295295224.12.SY.KEN@CU20B.COLUMBIA.EDU> We are in the process of ordering an 8700, with an HSC70. I would like to get rid of all (sans one for the FE) our RP06's and RP07's and have the one HSC control disks (RA60's and RA81's) for both the 2060 and the 8700. I remember DEC saying it should work, and that in fact they had run such a configuration. My question is: has anyone done this? We were told we couldn't do this (but then, the way things are now in 20-land at DEC, who knows anymore). I thought there was a rule that within a given CFS cluster, all disks had to be formatted the same. This obviously can't be the case here. I'm not real clear on this whole protocol, but I would think that the VAX and 20 would have to be able to exchange CI (e.g. voting) packets for all known disks, and since half would be owned by the VAX and half by the 20, not all disks are known to all systems. I would think there would have to be some kind of broadcast packet on the CI requesting some voting on a certain disk, and if the other system(s) in the cluster have no knowledge of this disk (or really, files on that disk), they wouldn't be able to answer the poll. But, like I said, I'm not real clear yet as to the actual protocols used on the CI bus (and it really is logically a broadcast bus, not a star, as the physical configuration would suggest). /Ken ------- 17-Apr-87 12:12:32-PST,1117;000000000000 Return-Path: Received: from C.CS.CMU.EDU by SCORE.STANFORD.EDU with TCP; Fri 17 Apr 87 13:11:27-PDT Received: ID ; Fri 17 Apr 87 16:15:01-EDT Date: Fri 17 Apr 87 16:15:01-EDT From: Vince.Fuller@C.CS.CMU.EDU Subject: Problems with TCP JFNs... To: tops-20@SCORE.STANFORD.EDU Message-ID: <12295299074.6.VAF@C.CS.CMU.EDU> I am having a problem with a server (FINGER server) which is using TCP JFNs for I/O. Specifically, some of the data sent by the server is not being transmitted to the remote host. The data is sent a byte at a time, using BIN%, and is being truncated at fairly random places. Adding a .TCPSH TCOPR% after all of the data has been written fixes this problem but creates another - the CLOSF% on the TCP JFN hangs for a long time. Adding a .TCSFN TCOPR% to this second scenario causes the CLOSF% to stop hanging but causes the data loss problem to return and, in fact, get worse. Has anyone seen lossage like this before? Any comments or suggestions on how to fix or get around the problem? Thanks in advance, Vince Fuller, CMU-CSD ------- 20-Apr-87 05:01:19-PST,876;000000000000 Return-Path: <@wiscvm.wisc.edu:IMHW400@INDYCMS.BITNET> Received: from wiscvm.wisc.edu by SCORE.STANFORD.EDU with TCP; Mon 20 Apr 87 05:58:51-PDT Received: from INDYCMS.BITNET by wiscvm.wisc.edu on 04/20/87 at 08:02:17 CDT Received: by INDYCMS (Mailer X1.23b) id 8211; Mon, 20 Apr 87 08:01:22 EDT Date: Mon, 20 Apr 1987 07:52 EDT From: Mark H. Wood Subject: No double precision in BASIC-PLUS-2/20 To: , In TOPS-20 BASIC-PLUS-2 Language Manual (AA-H654A-TM, 1979) on page 1-8, it says, "BASIC uses single-precision floating-point format when storing and calculating most numbers. Integers, however, are handled in a slightly different manner." It looks as though there is no way to express in BP2 the desire to use double precision. Sorry. 22-Apr-87 16:11:13-PST,2115;000000000000 Return-Path: Received: from SCIENCE.UTAH.EDU by SCORE.STANFORD.EDU with TCP; Wed 22 Apr 87 17:09:02-PDT Date: Wed 22 Apr 87 18:13:07-MST From: "Nelson H.F. Beebe" Subject: Multi-O/S Unix-like MAKE now available To: tops-20@SCORE.STANFORD.EDU cc: BEEBE@SCIENCE.UTAH.EDU X-US-Mail: "Center for Scientific Computation, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 Message-ID: <12296664061.12.BEEBE@SCIENCE.UTAH.EDU> A public-domain implementation of the Unix MAKE utility is now available for Internet ANONYMOUS FTP from SCIENCE.UTAH.EDU in the directory APS:, plus SYS:MAKE.EXE. Start by getting the file 00README.TXT in the ANONYMOUS login directory; it gives an overview of our system and tells how to find your way around. This version supports 6 operating systems (TOPS-20, VAX VMS, IBM PC DOS, OS9, EON, and UNIX), and is intended to conform to Unix Version 7 MAKE as documented by S.I. Feldman in the Unix Programmer's Manual. Naturally, there are Makefiles for each of these systems too. This MAKE additionally contains support (for VMS only) for library files. It is my intention after a suitable public review period to add features of newer proprietary Unix MAKE's. I view this as an extremely important utility, and will make every effort to respond to comments and provide bug fixes. The file 00REVHST.TXT contains a revision history, as well as a to-do list. The TOPS-20 implementation uses SRI's KCC compiler, with a special version of system() which provides a superset of MIC commands for terminal input control. TOPS-20 sites who wish to do local compilation should additionally take the files monsym.h and jsys.h from PS:. These are COMPLETE monsym and jsys files, and need SYS:KCCX.EXE to compile (a version of KCC loaded with extended addressing to get large symbol tables). Note that KCC is called that here, not CC as it is at many other sites, since I have already made a PCC-20 interface called CC. ------- 23-Apr-87 14:33:13-PST,1085;000000000000 Return-Path: Received: from USC-ECL.ARPA by SCORE.STANFORD.EDU with TCP; Thu 23 Apr 87 15:21:24-PDT Date: Thu 23 Apr 87 15:25:40-PDT From: Bruce Tanner Subject: AMAR-20 To: TOPS-20@SCORE.STANFORD.EDU Message-ID: <12296895723.42.CERRITOS@USC-ECL.ARPA> Has anybody else ordered AMAR-20 (i.e. 20-SP-9) from DECUS? Based on the flier I received in the mail and discussion on the net about a month ago, I ordered it a couple of weeks ago. I got the tapes yesterday, one of which was BLKY:[7,3,AMAR,TOPS10,] and the other was BLKY:[7,3,AMAR,TOPS20,] where was one each of ARCH, DIST, DOC, INDEVL and MANUAL. Both of these tapes were written 20-Jan-86. These sure didn't look like the new distribution to me, so I called DECUS and asked their technical person about it and she said that the last AMAR-20 they got was in Feb 86, and if I got a flier from anybody, it sure wasn't them. Well, I'm really confused. Did I just misunderstand the status of AMAR, or am I being conned? -Bruce ------- 23-Apr-87 15:13:41-PST,1106;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SCORE.STANFORD.EDU with TCP; Thu 23 Apr 87 15:55:58-PDT Date: Thu 23 Apr 87 18:56:50-EDT From: Betsy Ramsey Subject: Re: AMAR-20 To: CERRITOS@USC-ECL.ARPA cc: TOPS-20@SCORE.STANFORD.EDU, EWR@XX.LCS.MIT.EDU In-Reply-To: <12296895723.42.CERRITOS@USC-ECL.ARPA> Organization: American Mathematical Society Message-ID: <12296901396.59.EWR@XX.LCS.MIT.EDU> My guess would be that that is, in fact, *not* the V6.1 version of AMAR V4.3. Systems Concepts modified the Workload AMAR data collection programs WCdddx.EXE to work with the V6.1 monitor (where "ddd" are digits and "x" is "P" or "S") in June, 1986, and those files in the DIST set should be dated such (which would be difficult if the tape was made in January 1986). At any rate, all is not lost. The V6.1 AMAR is available via Anonymous FTP from KL.SRI.COM. You can get the correct Workload AMAR data collection executable from PS: on that system. I'm pretty sure you can use the other files "as-is". ------- 24-Apr-87 07:00:18-PST,1927;000000000000 Return-Path: Received: from CSLI.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 24 Apr 87 08:00:14-PDT Date: Fri 24 Apr 87 08:03:33-PDT From: Henry Chen Subject: ACJ bug To: SU-TOPS-20@Score.Stanford.EDU Also-known-as: Henry@SU-SUSHI, Henry@SU-SCORE, C.Chenry@LOTS-A, Henry@SRI-PRMH Message-ID: <12297077382.18.HENRY@CSLI.Stanford.EDU> I believe there is a bug in the logout routine at GOLGO when one job tries to log out another job. Here's the code in question: golgo: skipge a,.gerlg(pt) ;a/ fetch job number argument to LGOUT% hrrz a,rcvblk+.rcfcj ;-1 means requestor is killing self move b,[xwd -.jibch,getblk] ;b/ put the data here movei c,.jijno ;c/ start with the job number getji% ;get job information erjmp rskp ;some error, give good return The number of the job that is being logged out (fetched from .GERLG(PT) ) is incorrect if a job is not logging itself out. Here's an example of what happens why I try to log out job 14 (octal) from another job: [PHOTO: Recording initiated Fri 24-Apr-87 7:56AM] !get system:acj !ddt DDT golgo$b $g $1B>>GOLGO#/ SKIPGE 1,3(10) $x 1/ .JBBLT+10 RCVBLK#+14/ .JBBLT+10 GOLGO#+2/ MOVE 2,CRASH#+306 1[ 55 $x 2/ -26,,GETBLK# CRASH#+306/ -26,,GETBLK# GOLGO#+3/ MOVEI 3,0 $x 3/ 0 0 GOLGO#+4/ GETJI% $x GOLGO#+5/ ERJMP RSKP RSKP RSKP/ AOS 0(17) ^Z !pop [PHOTO: Recording terminated Fri 24-Apr-87 7:57AM] The GETJI% fails because the job number in AC1 is 55 (octal). For most of us, this just means that last logout information doesn't get updated. (At LOTS, there's a real problem, however, since allocation doesn't get updated either). Does anyone already have a fix for this (or is interested in fixing it?). If not, I guess I'll do it myself. Henry ------- 24-Apr-87 08:40:37-PST,500;000000000001 Return-Path: Received: from Sierra.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 24 Apr 87 09:40:25-PDT Date: Fri 24 Apr 87 09:37:52-PDT From: Stu Grossman Subject: Re: ACJ bug To: Henry@CSLI.Stanford.EDU cc: SU-TOPS-20@Score.Stanford.EDU In-Reply-To: <12297077382.18.HENRY@CSLI.Stanford.EDU> Message-ID: <12297094553.24.GROSSMAN@Sierra.Stanford.EDU> The last logout info seems to get updated correctly on Sierra. ------- 24-Apr-87 09:56:27-PST,2614;000000000001 Return-Path: <@wiscvm.wisc.edu:IMHW400@INDYCMS.BITNET> Received: from wiscvm.wisc.edu by SCORE.STANFORD.EDU with TCP; Fri 24 Apr 87 10:54:10-PDT Received: from INDYCMS.BITNET by wiscvm.wisc.edu ; Fri, 24 Apr 87 12:58:05 CDT Received: by INDYCMS (Mailer X1.23b) id 9132; Fri, 24 Apr 87 08:22:39 EDT Date: Fri, 24 Apr 1987 07:51 EDT From: Mark H. Wood Subject: Re: AMAR-20 To: Bruce Tanner , In-Reply-To: Your message of Thu 23 Apr 87 15:25:40-PDT I'd have to answer your question "yes and no". Yes, you misunderstood the status of DECUS AMAR: the catalog says that 20-SP-9 is "Not updated for release 6.0". No, in a way we are all being conned, because the flyer (I received one too) certainly seems to imply that the program is useful under the current supported Monitor, which is only half true. I don't feel that one should have had to refer back to the catalog in order to keep from getting burned this way; the flyer should have mentioned the restriction. The flyer certainly SEEMS to have "come from them", as it bears the DECUS logo and the mark of a Marlboro postage meter. The mailing label on mine is even misspelled in the usual manner, so it was done with DECUS' mailing list. The thing to do would seem to be, ignore 20-SP-9 and get the up-to-date stuff from KL.SRI.COM. However, those who prefer to get the sources and rebuild everything (standard procedure here) should note that the modules ARMS and WCGEN are corrupted: ARMS.MAC has a piece of its own listing wedged into it, and WCGEN.MAC is zero-length. I've contacted David L. Edwards regarding these problems, and he promised to look into the matter. Source-builders should also note that the COBOL modules are written according to the COBOL-68 standard, requiring the removal of REMARKS paragraphs and the replacement of EXAMINEs with INSPECTs (and minor associated adjust- ments) in order to compile them with the current -74/-8x compiler. Further, the compiler has a bug in the old-style command scanner that makes it barf on COPY-library specifications: use "/C74/L file.LIB file.CBL" instead of "file.LIB/L,file.CBL". Finally, one of the programs is loaded in overlays; this causes numerous LINK errors when linking against the current COBOL library and is not really necessary, so I dispensed with the overlay structure. I haven't had a chance to test all these mods yet, but everything I've got now compiles cleanly under COBOL %13. 24-Apr-87 10:54:47-PST,767;000000000000 Return-Path: Received: from SUMEX-AIM.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Fri 24 Apr 87 11:54:46-PDT Date: Fri, 24 Apr 87 11:57:04 PDT From: Mark Crispin Subject: Re: ACJ bug To: Henry@CSLI.STANFORD.EDU cc: SU-TOPS-20@SCORE.STANFORD.EDU In-Reply-To: <12297077382.18.HENRY@CSLI.Stanford.EDU> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12297119894.15.CRISPIN@SUMEX-AIM.STANFORD.EDU> Foo! This is a monitor bug that I fixed ages and ages ago in release 5 days. Is this yet another of my fixes that Lougheed &Co. failed to put into Stanford 6.1 because they didn't understand what it was for? What cretins. ------- 24-Apr-87 17:50:00-PST,1495;000000000000 Return-Path: Received: from CSLI.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 24 Apr 87 18:49:54-PDT Date: Fri 24 Apr 87 18:53:11-PDT From: Henry Chen Subject: Re: ACJ bug To: GROSSMAN@Sierra.Stanford.EDU cc: SU-TOPS-20@Score.Stanford.EDU In-Reply-To: <12297094553.24.GROSSMAN@Sierra.Stanford.EDU> Also-known-as: Henry@SU-SUSHI, Henry@SU-SCORE, C.Chenry@LOTS-A, Henry@SRI-PRMH Message-ID: <12297195644.11.HENRY@CSLI.Stanford.EDU> The last logout information doesn't seem to get updated on Sierra when I try it: [PHOTO: Recording initiated Fri 24-Apr-87 6:47PM] !f henry/detACHED /no HENRY Henry Chen HENRY not logged in Last logout Fri 24-Apr-87 7:20AM from Internet host Macbeth.Stanford.EDU No new mail, last read on Thu 26-Mar-87 5:19AM !f henry HENRY Henry Chen 9 FINGER 207 Ethernet: CSLI 10 EXEC .125 Internet: Sierra No new mail, last read on Thu 26-Mar-87 5:19AM !kj 10 User HENRY on TTY125, running EXEC [Confirm] !f henry/det/no HENRY Henry Chen HENRY not logged in Last logout Fri 24-Apr-87 7:20AM from Internet host Macbeth.Stanford.EDU No new mail, last read on Thu 26-Mar-87 5:19AM !pop [PHOTO: Recording terminated Fri 24-Apr-87 6:48PM] Notice that it still says I last logged out from Macbeth at 7:20 this morning instead of from Sierra at 6:48 this evening. Henry ------- 24-Apr-87 22:53:04-PST,1365;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SCORE.STANFORD.EDU with TCP; Fri 24 Apr 87 23:51:09-PDT Date: Sat 25 Apr 87 02:57:20-EST From: Ken Rossman Subject: RSX V15-50 strangeness To: TOPS20@SCORE.STANFORD.EDU Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 Message-ID: <12297261935.18.SY.KEN@CU20B.COLUMBIA.EDU> Is anyone out there running a V15-50 RSX-20F front end? We're running it, and we've seen some very interesting behavior when using only the floppies to run the system. When a front end is built from the floppies onto the RP06, and then the RP06 version of the front end is booted, everything seems to run fine. When the system is booted from the floppies (say, when we lose drive 0 and can't boot the front end off of the RP06), we see two interesting failures. First, we can't save the KL configuration on the floppies. RSX complains about record length errors or somesuch. Second, although KLINIT claims to have configured in all caches, but when we come up, it becomes clear that none of the caches are enabled. I don't think the floppies themselves are physically damaged, as we have a couple of copies and they both do the same thing. Has anyone else seen this at all? Anyone have any suggestions? /Ken ------- 25-Apr-87 23:59:15-PST,1481;000000000000 Return-Path: <@wiscvm.wisc.edu:RMF%ADMIN@UNCAEDU.BITnet> Received: from wiscvm.wisc.edu by SCORE.STANFORD.EDU with TCP; Sun 26 Apr 87 00:54:46-PDT Received: from UNCAEDU.BITnet by wiscvm.wisc.edu ; Sun, 26 Apr 87 02:58:37 CDT Received: from ADMIN by UcEdu.UNCA.AdhocNet.CA with DECNET ; Sun, 26 Apr 87 01:14:11 MDT Date: Sun 26 Apr 87 01:12:13-MDT From: RMF%ADMIN%UNCAEDU.BITNET@wiscvm.wisc.edu Subject: MENTOR To: tops20%score.stanford.edu@UNCAEDU.BITnet Phone: (403) 240-6052 Organization: Mount Royal College; Computer Operations Postal-Address: 4825 Richard Rd. S.W.; Calgary, Alberta, T3E 6K6 Message-ID: <12297515868.9.RMF@ADMIN> It seens that our local DEC office seems to think there is a product for the 20 called MENTOR. It apparently allows non WHOPR's to do some WHOPR functions, such as advise users and such. I have never heard of such a thing, but I know it would be trivial to write. I know for a fact that *I* don't want such a thing on *my* system, but due to management pressures I am froced to ask of its existence. The only reason this issue came up is because our user support group is to lazy to walk to the user to help. Its a sad life :-). /Russ ----- Russell M Forster DECnet: RMF @ { Admin | Comus | Stasis | Ins } BITnet: RForster @ UncaEdu.BITnet ARPA: Oc.Russ @ CU20B.Columbia.Edu ------- 27-Apr-87 10:04:03-PDT,1692;000000000000 Return-Path: <@wiscvm.wisc.edu:RMF%ADMIN@UNCAEDU.BITnet> Received: from wiscvm.wisc.edu by SCORE.STANFORD.EDU with TCP; Mon 27 Apr 87 10:01:04-PDT Received: from UNCAEDU.BITnet by wiscvm.wisc.edu ; Mon, 27 Apr 87 12:05:07 CDT Received: from ADMIN by UcEdu.UNCA.AdhocNet.CA with DECNET ; Mon, 27 Apr 87 11:05:27 MDT Date: Mon 27 Apr 87 11:03:20-MDT From: RMF%ADMIN%UNCAEDU.BITNET@wiscvm.wisc.edu Subject: MENTOR To: tops20@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: <12297885620.41.RMF@ADMIN> [REMAILING OF THIS MESSAGE, NOT SURE IT GOT OUT THE FIRST TIME] It seens that our local DEC office seems to think there is a product for the 20 called MENTOR. It apparently allows non WHOPR's to do some WHOPR functions, such as advise users and such. I have never heard of such a thing, but I know it would be trivial to write. I know for a fact that *I* don't want such a thing on *my* system, but due to management pressures I am froced to ask of its existence. The only reason this issue came up is because our user support group is to lazy to walk to the user to help. Its a sad life :-). /Russ ----- Russell M Forster DECnet: RMF @ { Admin | Comus | Stasis | Ins } BITnet: RForster @ UncaEdu.BITnet ARPA: Oc.Russ @ CU20B.Columbia.Edu ------- ----- Russell M Forster DECnet: RMF @ { Admin | Comus | Stasis | Ins } BITnet: RForster @ UncaEdu.BITnet ARPA: Oc.Russ @ CU20B.Columbia.Edu ------- 30-Apr-87 08:16:58-PDT,850;000000000000 Return-Path: Received: from Stripe.SRI.COM by SCORE.STANFORD.EDU with TCP; Thu 30 Apr 87 08:12:43-PDT Date: Thu 30 Apr 87 08:16:43-PDT From: David L. Edwards Subject: Re: AMAR-20 To: IMHW400%INDYCMS.BITNET@WISCVM.WISC.EDU cc: CERRITOS@USC-ECL.ARPA, TOPS-20@SCORE.STANFORD.EDU In-Reply-To: Message from "Mark H. Wood " of Fri 24 Apr 87 17:17:41-PDT Message-ID: <12298652642.14.DLE@Stripe.SRI.COM> Betsy Ramsey, from whom the AMAR version on KL.SRI.COM came from, said she would look into getting me new copies of ARMS.MAC and WCGEN.MAC after DECUS. I would like to mention that there is now an AMAR users mailing list to discuss problems and improvements. If anyone is interested, send a request to AMAR-USERS-REQUEST@KL.SRI.COM. -dle ------- 1-May-87 13:36:57-PDT,1621;000000000000 Return-Path: Received: from bass.nosc.mil by SCORE.STANFORD.EDU with TCP; Fri 1 May 87 13:35:19-PDT Received: by bass.nosc.mil (5.31/4.7) id AA14656; Fri, 1 May 87 13:39:20 PDT Received: by humu.ARPA (5.31/4.7) id AA17444; Fri, 1 May 87 10:39:47-1000 Received: by uhmanoa.ICS.HAWAII.EDU (5.51/UUCP-Project/rel-1.0/11-09-86) id AA11564; Fri, 1 May 87 09:48:27-1000 Message-Id: <8705011948.AA11564@uhmanoa.ICS.HAWAII.EDU> Date: Fri, 1 May 87 09:32:07-1000 From: uhccux!uhmanoa!uhmanoa.ICS.HAWAII.EDU!jeff@nosc.mil (Jeffrey Blomberg) To: tops-20@SCORE.STANFORD.EDU Subject: TCP/IP via NI Cc: jeff%bass.nosc.mil@nosc.mil We recently installed the TCP/IP monitor on our -20 with hopes of making it 'talk' to our UNIX machines on a local ethernet. Needless to say, we connected to the ethernet with the NIA-20. We have no trouble communicating with UNIX machines that are directly accessible, but can't manage to 'teach' TOPS-20 to deal with a machine which is accessible via a host gateway. My guess is that I will have to use an equivalent of the UNIX netmask to get this to work since the hosts on both sides of the gateway are a part of the same class B network. Does anyone know of any documentation which may describe the options available for the SYSTEM:INTERNET.ADDRESS, SYSTEM:INTERNET-ETHERNET-MAPPINGS.TXT, and SYSTEM:HOSTS.TXT files? The documentation which came with the monitor tape describes the utilities (needs updating in some cases), but doesn't get into the descriptions of these files at all. -Jeff 3-May-87 17:28:21-PDT,1687;000000000000 Return-Path: <@SUMEX-AIM.STANFORD.EDU:MRC@PANDA> Received: from SUMEX-AIM.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Sun 3 May 87 17:27:07-PDT Received: from PANDA by SUMEX-AIM.STANFORD.EDU with Cafard; Sun, 3 May 87 17:29:51 PDT Date: Sun, 3 May 87 16:04:03 PDT From: Mark Crispin Subject: 6.1 EXEC bug To: TOPS-20@Score.Stanford.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12299524151.8.MRC@PANDA> Problem: INFORMATION MAIL when unlogged in always returns an error of "Mailbox protected". This error message is a lie. Diagnosis: In support of the POBOX: stuff, a new cell called POBXNO was defined to hold the directory number of the user's POBOX: directory. The code to print a mail notice when logging in was changed to: MOVE B,POBXNO ;GET USER'S POBOX: DIRECTORY CALL MALCHK ;CHECK FOR MAIL JFCL ;IGNORE FAILURE In edit 3048 on 14-OCT-86, EVANS put in what I presume was a fix for bogus error messages caused if POBXNO was 0 (meaning the user doesn't have a valid POBOX: directory). Instead of changing the MOVE B,POBXNO to SKIPE B,POBXNO (which is what most of us would have done) he added the following two instructions at MALCHK: SKIPN POBXNO ;[3048]ANY POBXNO FOR THIS USER? RET ;[3048]NO - SILLY TO DO MAILCHECK, THEN The problem is that this means that INFORMATION MAIL will never work, even if mail is being checked for some perfectly valid directory! Solution: Delete the SKIPN POBXNO and RET at MALCHK in EXECSU. Add JUMPE B,R ;IF NO DIRECTORY THEN JUST RETURN to cover the case this code tried to fix. ------- 4-May-87 13:57:11-PDT,2061;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SCORE.STANFORD.EDU with TCP; Mon 4 May 87 13:55:55-PDT Date: Mon 4 May 87 16:24:53-EDT From: Betsy Ramsey Subject: DECUS Autopatch Survey To: TOPS-20@SCORE.STANFORD.EDU cc: BHamilton%Gidney.DEC@DECWRL.DEC.COM Reply-To: BHamilton%Gidney.DEC@DECWRL.DEC.COM Organization: American Mathematical Society Message-ID: <12299757318.40.EWR@XX.LCS.MIT.EDU> At DECUS, DEC handed out a survey on the Autopatch process. Buzz Hamilton of Digital attended the symposium to talk to people about Autopatch. I am reproducing the survey here so that you can respond to Buzz if you wish. His Arpanet address is BHAMILTON%GIDNEY.DEC@DECWRL.DEC.COM The survey follows. ------- The Large Systems Business Unit ("LCG") is currently evaluating changes to the Autopatch procedures. Please help us by answering the following questions: 1. Are you primarily a TOPS-10 or TOPS-20 site? KS or KL? 2. Do you use the Autopatch tape at your site? If not, why not? 3. Do you modify or "shortcut" the documented Autopatch procedures? If so, in what way? 4. Do you test the Autopatched products before making them available for default general use? If so, for how long? 5. How often would you like to see the updates arrive? What are the shortest and longest acceptable periods? 6. Currently, Autopatch builds from patched sources or REL files. Would you be in favor of eliminating the product build procedures and having it look more like a standard distribution? (EXE, REL and source files would be delivered. Builds would be done by customers.) 7. What new functionality or tools would you like to see? (E.g., MAKE, LBR, VERIFY, SCCS, SLP, REDIT) 8. Would a VMSINSTAL-like update procedure be desirable? 9. Have you ever had to use the RESTORE command in PEP? If you are willing to be contacted for further discussion, please provide your name and phone number. ------- 11-May-87 12:14:34-PDT,1141;000000000000 Return-Path: Received: from RELAY.CS.NET by SCORE.STANFORD.EDU with TCP; Mon 11 May 87 12:06:35-PDT Received: from relay2.cs.net by RELAY.CS.NET id ab14084; 11 May 87 15:02 EDT Received: from bgsu.edu by RELAY.CS.NET id ad24177; 11 May 87 14:56 EDT Received: by andy.bgsu.edu (5.51/3.1) id AA19270 ; Mon, 11 May 87 07:57:03 EDT Date: Mon, 11 May 87 07:57:03 EDT From: Steve Herber To: tops20@SCORE.STANFORD.EDU Subject: Access to DEC's LCG customer machine, MARKET Cc: herber%andy.bgsu.edu@RELAY.CS.NET Has anyone tried to use the bulletin boards set up on the MARKET TOPS-20 system for the LCG customers? I have tried a couple of times in the last few weeks, per the instructions in the "Large Systems Newsletter" and found old, old bulletins, a mail facility that didn't work and no facilities to post new bulletins. Is this system going the way of the rest of the TOPS-20 sites, dying a slow death from neglect? Steve Herber CSNET herber@bgsu.edu Sr. Systems Programmer UUCP ...!osu-eddie!bgsuvax!herber Bowling Green State Univ. 11-May-87 12:20:59-PDT,2814;000000000001 Return-Path: Received: from RELAY.CS.NET by SCORE.STANFORD.EDU with TCP; Mon 11 May 87 12:06:43-PDT Received: from relay2.cs.net by RELAY.CS.NET id ac14084; 11 May 87 15:03 EDT Received: from bgsu.edu by RELAY.CS.NET id ae24177; 11 May 87 14:57 EDT Received: by andy.bgsu.edu (5.51/3.1) id AA19278 ; Mon, 11 May 87 07:58:54 EDT Date: Mon, 11 May 87 07:58:54 EDT From: Steve Herber To: tops20@SCORE.STANFORD.EDU Subject: Reading DUMPER tapes on VMS. Cc: herber%andy.bgsu.edu@RELAY.CS.NET I have been trying to read some TOPS-20 labeled ARCHIVE and MIGRATION tapes on a VMS system using the SI_DUMPER utility from the "Integration Tools Clearinghouse" (not to be confused with that OTHER clearinghouse with Johnny's buddy, Ed:-). I've had some success but I still haven't figured it all out. I can mount the tape with a... $ MOUNT/OVER=(OWNER,ACCESS) MUA0: volid and that allows me to 'see' the savesets on the tape via a DIRECTORY command. I can restore one or more files in a saveset with SI_DUMPER, $ BAKDMP/REWIND/BLOCK=8/FORMAT=DUMPER/LOG MUA0: destination_dir (we write our tape with a blocking factor of 8) But that only works for the first saveset or subsequent savesets by leaving the /REWIND option off. The problems start when I try to skip savesets with the /SKIP=n option. The process eats CPU time like crazy doing direct I/O and the ACP process also loops doing buffered I/O. The tape does nothing. I have no other oter way to skip savesets when VMS is using labeled tapes. The second problem is with the /LIST option that produces a listing of the contents of the tape, simular to DUMPER's PRINT command. The SI_DUMPER program has a fatal error of... %SYSTEM-F-ACCVIO, access violation, reason mask=85, virtual address=03C00000, PC=7FF00000, PSL=50405544 %TRACE-F-TRACEBACK, symbolic dump follows DUMPER_LIST LIST_FAO 610 00000039 00007985 DUMPER_DUMPER_T DUMPER_LIST_RECORD 2977 00000000 00005EFC DRIVER LIST_SAVE_SET 784 00000011 00004853 DRIVER DRIVER_PROCESS_COMMAND 472 000000DC 00004A28 DUMPER DUMPER_MAIN 1244 00000099 00004699 Each of these commands work when using unlabeled DUMPER tapes. I even tried creating unlabeled copies of the TOPS-20 labeled tapes using the EXEC COPY command and a record length of 518 (thanks TSC) with the same results. I have the the VMS tools tape #10 dated 10/30/86 and the version of SI_DUMPER I am using is from the [SI_DUMPER013] directory. This is written in BLISS-32 and I don't have access to one to try and fix this myself. Thanks for listening...... Steve Herber CSNET herber@bgsu.edu Sr. Systems Programmer UUCP ...!osu-eddie!bgsuvax!herber Bowling Green State Univ. 11-May-87 16:28:22-PDT,412;000000000000 Return-Path: Received: from CSLI.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 11 May 87 16:27:13-PDT Date: Mon 11 May 87 16:31:35-PDT From: Rich Cower Subject: diagnostic prices To: tops-20@Score.Stanford.EDU cc: cower@CSLI.Stanford.EDU Message-ID: <12301626316.32.COWER@CSLI.Stanford.EDU> Anyone know what they cost? thanks...Rich ------- 12-May-87 15:18:37-PDT,1773;000000000000 Return-Path: <@wiscvm.wisc.edu:IMHW400@INDYCMS.BITNET> Received: from wiscvm.wisc.edu by SCORE.STANFORD.EDU with TCP; Tue 12 May 87 15:15:18-PDT Received: from INDYCMS.BITNET by wiscvm.wisc.edu ; Tue, 12 May 87 17:19:03 CDT Received: by INDYCMS (Mailer X1.23b) id 0943; Tue, 12 May 87 15:27:07 EDT Date: Tue, 12 May 1987 15:02 EDT From: Mark H. Wood Subject: Re: diagnostic prices To: COWER@CSLI.Stanford.EDU, TOPS-20@SCORE.STANFORD.EDU In-Reply-To: Your message of Mon 11 May 87 16:31:35-PDT Product KL10C KL10D KL10E KL10A KS10 ======= ===== ===== ===== ===== ==== diags on 16MT9 $35k $35k $35k $35k $15k ZH006-CM ZH007-CM ZH008-CM ZH009-CM ZT001-CM annual diag update $ 3k $ 3k $ 3k $ 3k $500 ZH010-HM ZH010-HM ZH010-HM ZH010-HM ZT001-HM Maint. Doc. Svc. Unknown, probably $4k $ 4k MD-KL10-00? MD-KS10-00 MDS annual update $ 1k $ 1k MD-KL10-R MD-KS10-R MDS 2-yr update $1600 $1600 MD-KL10-2R MD-KS10-2R All of the above are from "Self Maintenance Services" catalog HP, part ED-29562-68, 29-Dec-86 through 27-Jun-87. Don't ask me how I came to have this catalog; we don't do hardware self-maintenance here. If you're still interested, the catalog claims that you can order this stuff through DECdirect. 15-May-87 02:28:08-PDT,1264;000000000001 Return-Path: Received: from SRI-NIC.ARPA by SCORE.STANFORD.EDU with TCP; Fri 15 May 87 02:26:47-PDT Date: Fri 15 May 87 02:31:30-PDT From: Ken Harrenstien Subject: Bug in TOPS-20 Daylight Saving Time algorithm To: tops-20@SCORE.STANFORD.EDU cc: klh@SRI-NIC.ARPA Message-ID: <12302521958.43.KLH@SRI-NIC.ARPA> I was working on improving the portability of the KCC C library date/time routines, and wrote my own DST calculation code. To check it out, I compared it against the TOPS-20 ODCNV% code by checking every day from 1970 to 1999 inclusive. I found some discrepancies, which I initially assumed were my fault, but on second glance it looks as if the TOPS-20 algorithm is a little off base. I made no attempt whatsoever to debug the monitor code; it gives me a headache when I try to understand it. Without further ado, here are the problems I found: 1971: DST ends 10/31; TOPS-20 claims 10/24 (1 week too early). 1978: DST begins 4/30; TOPS-20 claims 4/23 (1 week too early). 1982: same error as 1971. 1991: DST begins 4/7; TOPS-20 claims 3/31 (1 week too early). 1993: same error as 1971. 1999: same error as 1971. Good luck to whoever feels like correcting the problem. ------- 15-May-87 12:01:12-PDT,1380;000000000000 Return-Path: Received: from Sierra.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 15 May 87 11:59:18-PDT Date: Fri 15 May 87 12:05:35-PDT From: Stu Grossman Subject: Re: Bug in TOPS-20 Daylight Saving Time algorithm To: KLH@SRI-NIC.ARPA cc: tops-20@Score.Stanford.EDU In-Reply-To: <12302521958.43.KLH@SRI-NIC.ARPA> Message-ID: <12302626466.43.GROSSMAN@Sierra.Stanford.EDU> The bug you are complaining about is probably an artifact of a patch applied to your monitor to correct for the new daylight savings rule this year. This patch merely changes the starting date of DST, but does not attempt to apply the proper correction that would be specific to a particular year. Now that we are out of April, you could probably patch DSTON back to it's previous value for the purposes of testing your code. One other point. As long as the monitor is willing to handle DST, you should take advantage of that. This is so that you can fix the DST rules in a single place without the need to recompile or re-link every application that uses your library. Otherwise, you will end up with what happened on Unix 4.3, where every program that used ctime() had to be re-linked when the DST rules changed. Of course, shared run time libraries make this mostly a moot point. Stu Grossman ------- 15-May-87 14:20:03-PDT,1577;000000000000 Return-Path: Received: from SRI-NIC.ARPA by SCORE.STANFORD.EDU with TCP; Fri 15 May 87 14:18:51-PDT Date: Fri 15 May 87 14:23:27-PDT From: Ken Harrenstien Subject: ["Rocket J. Squirrel" : Re: Bug in TOPS-20 Daylight Saving Time algorithm] To: tops-20@SCORE.STANFORD.EDU Message-ID: <12302651565.43.KLH@SRI-NIC.ARPA> Additional info of interest. --------------- Return-Path: Received: from TOPS20.DEC.COM by SRI-NIC.ARPA with TCP; Fri 15 May 87 05:06:20-PDT Date: 15 May 1987 0806-EDT From: "Rocket J. Squirrel" To: Ken Harrenstien Loc/MS: "MRO1-2/L14 (Pole M13)" Phone: "DTN 297-2346 (617-467-2346)" Quote: "Do you know where I can find a nuclear wessel" Subject: Re: Bug in TOPS-20 Daylight Saving Time algorithm Message-ID: <"MS11(6022)+GLXLIB5(0)" 12302550129.24.140.258849 at TOPS20.DEC.COM> References: Message from Ken Harrenstien of 15-May-87 0539-EDT In-reply-to: <12302521958.43.KLH@SRI-NIC.ARPA> Ken, Your observation was quite correct about ODCNV% being off on certain years. If you'll notice, those years are when Oct 1 or April 1 fall on a Sunday (I think). Brian Lilja has worked out the code for a solution but he has not merged it with our sources yet because we are currently frozen for an autopatch update. This fix should appear in the monitor long before the next occurrence of the problem (1991 I think). Mike -------- ------- 15-May-87 21:28:47-PDT,1076;000000000000 Return-Path: <@SUMEX-AIM.STANFORD.EDU:MRC@PANDA> Received: from SUMEX-AIM.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Fri 15 May 87 21:15:22-PDT Received: from PANDA by SUMEX-AIM.STANFORD.EDU with Cafard; Fri, 15 May 87 21:19:47 PDT Date: Fri, 15 May 87 20:37:07 PDT From: Mark Crispin Subject: KLH's bug To: TOPS-20@Score.Stanford.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12302719589.7.MRC@PANDA> Friends - The bug that KLH reported was caused by the "fix" to SPR 20-16981. The bug exists, albeit with slightly different symptoms, in the DEC, Stanford, and PANDA versions of DATIME. The fix for the problem is to look for two CALL NLEAP instructions in the NLSS routine. You should put a TXNE AA,IC%JUD in front of it, so if the date isn't in Julian format it goes to the SKIPA. That is, you should have something like: TXNE AA,IC%JUD CALL NLEAP SKIPA SUBI ac,1 (ac is E one place and F another) -- Mark -- ------- 21-May-87 16:49:09-PDT,619;000000000000 Return-Path: Received: from SUMEX-AIM.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Thu 21 May 87 16:48:58-PDT Date: Thu, 21 May 87 16:53:20 PDT From: Mark Crispin Subject: new version of DATIME.MAC To: SU-TOPS-20@SCORE.STANFORD.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12304251715.79.CRISPIN@SUMEX-AIM.STANFORD.EDU> <6-1-MONITOR>DATIME.MAC.4 has my latest revision to the daylight savings time rules, fixing a bug that KLH reported. The bug was a bogus DEC "fix". ------- 27-May-87 11:24:14-PDT,3342;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SCORE.STANFORD.EDU with TCP; Wed 27 May 87 11:18:40-PDT Return-Path: <@KL.SRI.Com:info-vax-request@kl.sri.com> Received: from KL.SRI.Com by XX.LCS.MIT.EDU with TCP/SMTP; Sun 24 May 87 12:47:03-EDT Received: from ucbvax.Berkeley.EDU by KL.SRI.COM with TCP; Sun 24 May 87 08:14:13-PDT Received: by ucbvax.Berkeley.EDU (5.57/1.25) id AA26141; Sun, 24 May 87 08:03: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: 24 May 87 14:25:52 GMT From: beta!hwe@NYU.ARPA (Skip Egdorf) Organization: Los Alamos Natl Lab, Los Alamos, N.M. Subject: Re: bsd unix vs. dec's vms Message-Id: <5548@beta.UUCP> References: <5828@shemp.UCLA.EDU>, <34ab0e42.8be4@apollo.uucp>, <19385@sun.uucp> Sender: info-vax-request@kl.sri.com To: info-vax@kl.sri.com ReSent-Date: Wed 27 May 87 14:22:41-EDT ReSent-From: Betsy Ramsey ReSent-To: TOPS-20@SCORE.STANFORD.EDU ReSent-Message-ID: <12305764385.74.EWR@XX.LCS.MIT.EDU> >In article <19385@sun.uucp>, landauer@sun.uucp (Doug Landauer) writes: >> Look at it from DEC's point of view at the time that DCL was designed: >> the PDP-11 was the single most successful computer (in terms of units >> shipped) in the history of computing. [ or damn close -- anyone know >> for sure? ] DEC *had* to continue to support it. >> >> They had gone through an awful fiasco on the PDP-11 where DEC >> themselves sold *five* different operating systems for that machine >> (maybe more -- let's see, DOS, RT-11, RTOS, RSX-11M, and RSX-11D which >> became IAS). And to the great chagrin of their in-house OS >> programmers, there were as many PDP-11s running Unix as were running >> some of their own operating systems. DEC needed some consistency at >> that point. The motivation for designing DCL was to prevent something >> like that from happening on the VAX, without abandoning their enormous >> installed base of PDP-11 users. They wanted a single OS to be dominant >> on the VAX line, and at that they've been almost totally successful. I think that a more important historical perspective involves the DecSystem-10 and DecSystem-20 series. In the late '60s and early '70s, TOPS-10 on the DEC-10 was the sort of "in" operating system that Unix is today. Everyone who was a true computer guru had to use one (the AI labs, etc.). (as a former TOPS-10 user, this reputation was solidly based...). One of the real marketing strengths was the single operating system used by the whole line of machines, TOPS-10. The ARPANET community had been playing with some upstart called TENEX. (Golly, does this story sound familier to VAX folks?) It became clear that DEC would have to support TENEX in some form as well as TOPS-10, and there were internal wars over this drastic step. The multi-OS group won, and DEC introduced the DecSystem-20 with a new operating system called TOPS-20 (TENEX). The single-OS group in DEC saw the 10/20 start to fade, and fought even harder to have only one OS on the new VAX. Would someone with more first-hand knowledge of the internal battles over this within DEC care to comment? Skip Egdorf hwe@lanl.gov 27-May-87 16:31:04-PDT,1056;000000000000 Return-Path: Received: from bu-cs.BU.EDU by SCORE.STANFORD.EDU with TCP; Wed 27 May 87 16:29:48-PDT Return-Path: Received: by bu-cs.BU.EDU (3.2/4.7) id AA17194; Wed, 27 May 87 19:24:38 EDT Date: Wed, 27 May 87 19:24:38 EDT From: budd@bu-cs.bu.edu (Philip Budne) Message-Id: <8705272324.AA17194@bu-cs.BU.EDU> To: beta!hwe@NYU.ARPA, info-vax@kl.sri.com Subject: Re: bsd unix vs. dec's vms Cc: tops-20@score.stanford.edu I worked for DEC/LCG as a software engineer, and as someone who tries to keep an open mind, I was apalled by the amount of TOPS-10 bashing was present among s/w developers. RMS and DBMS development was being dropped, FORTRAN v10 (ANSI full F77) was nearly not released for TOPS-10. Sucessive versions of TOPS-10 were released by customer demands for the new features: 7.00 SMP, 7.02 DECnet, 7.03 Extended Addressing. It shocked me that a group that had many times been on the edge of extinction could indulge in such internal bigotry. Phil Budne Boston University 30-May-87 22:31:56-PDT,679;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SCORE.STANFORD.EDU with TCP; Sat 30 May 87 22:31:43-PDT Date: Sat, 30 May 87 22:40:44 MDT From: Frank J. Wancho Subject: Any MOBIUS users out there? To: TOPS20@SCORE.STANFORD.EDU cc: WANCHO@SIMTEL20.ARPA Message-ID: <12306663330.9.WANCHO@SIMTEL20.ARPA> If there are any TOPS20 MOBIUS users reading this, do you have any utilities you'd be willing to share? We'll provide the disk space for the sources if you do. Mail them directly to me. If there's sufficent interest, I'll be glad to start up another special interest mailing list on this subject. --Frank ------- 1-Jun-87 06:41:01-PDT,1507;000000000000 Return-Path: <@SUMEX-AIM.STANFORD.EDU:MRC@PANDA> Received: from SUMEX-AIM.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Mon 1 Jun 87 06:28:27-PDT Received: from PANDA by SUMEX-AIM.STANFORD.EDU with Cafard; Mon, 1 Jun 87 06:38:00 PDT Date: Mon, 1 Jun 87 01:26:30 PDT From: Mark Crispin Subject: DUP-11 loopback? To: TOPS-20@Score.Stanford.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12306966575.8.MRC@PANDA> I recently put a second DUP-11 into PANDA so I can test my DECnet code on a machine with two DUP's. It all works fine (once I got the board's Unibus address set right) and I'd like to leave that board in, perpetually looped back on the cable (that way, the software doesn't "know" it's looped back in any way, and I can hook it into a modem at any time). The problem is, I'm unable to get this to work unless I have it connected to a *modem* in local loopback. The DUP-11 documentation says I should be able to plug in an H325. Supposedly, the DUP has a 10khz clock on one of the lines and the H325 will feed it to the clocks. I've tried it with both the "cut for sync test" jumper out and in place. No good. But plug it into a LL modem and no problem. Surely somebody on this list has wanted to do a cable loopback on a DUP before and has figured out how to do it without involving a modem! An H325 is a bit cheaper on the electric bill than a modem... ------- 1-Jun-87 08:06:08-PDT,1098;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SCORE.STANFORD.EDU with TCP; Mon 1 Jun 87 08:05:12-PDT Date: Mon 1 Jun 87 11:16:57-EDT From: Ken Rossman Subject: Re: DUP-11 loopback? To: MRC%PANDA@SUMEX-AIM.STANFORD.EDU, TOPS-20@SCORE.STANFORD.EDU In-Reply-To: <12306966575.8.MRC@PANDA> Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 Message-ID: <12307041293.33.SY.KEN@CU20B.COLUMBIA.EDU> I've been the DUP-loop route before. Problem is, the H325 connector wants to loop pin 24 to 15 and 17 for clocking, which would be fine, except the DUP doesn't seem to want to supply clocking on pin 24. Ether there's some setting on the board I missed that enables "internal clock out" on that pin, or else the DUP just doesn't do it. I've just always plugged it into a sync modem and let the modem do th looping... (or every once in awhile, for a different kind of test, I'd use a breakout box and a modem, and loop with the breakout box, and borrow the clock only from the modem). /Ken ------- 4-Jun-87 12:05:32-PDT,1122;000000000000 Return-Path: <@wiscvm.wisc.edu:RMF%ADMIN@UNCAEDU.BITnet> Received: from wiscvm.wisc.edu by SU-SCORE.ARPA with TCP; Wed 3 Jun 87 12:35:53-PDT Received: from UNCAEDU.BITnet by wiscvm.wisc.edu ; Wed, 03 Jun 87 14:36:42 CDT Received: from ADMIN by UcEdu.UNCA.AdhocNet.CA with DECNET ; Wed, 3 Jun 87 13:33:36 MDT Date: Wed 3 Jun 87 13:31:49-MDT From: RMF%ADMIN%UNCAEDU.BITNET@wiscvm.wisc.edu Subject: CFCTNF BugHLT 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: <12307611980.11.RMF@ADMIN> My system just died with a CFCTNF BugHLT, problem is I don't know that this is and can't find it. Can someone tell me what this is or at least where I can find the documentation on it. Thanks in advance. /Russ ----- Russell M Forster DECnet: RMF @ { Admin | Comus | Stasis | Ins } BITnet: RForster @ UncaEdu.BITnet ARPA: Oc.Russ @ CU20B.Columbia.Edu USEnet: siesmo!calgary!vaxa!forster ------- 4-Jun-87 12:05:57-PDT,1637;000000000000 Return-Path: Received: from C.CS.CMU.EDU by SU-SCORE.ARPA with TCP; Wed 3 Jun 87 12:36:21-PDT Received: ID ; Wed 3 Jun 87 15:38:20-EDT Date: Wed 3 Jun 87 15:38:20-EDT From: Vince.Fuller@C.CS.CMU.EDU Subject: Another problem with TCP JFNs... To: TOPS-20@SCORE.STANFORD.EDU Message-ID: <12307613164.6.VAF@C.CS.CMU.EDU> Once again, I am running into problems with an application that is using TCP JFNs for I/O. The program in question is TCPSPL (the TCP/LPD printer spooler for printing on Unix printers) and the failing scenario is: - TCPSPL sends a bunch of data comprising a data file over the network using SOUTR%s of buffers up to 2000 bytes each. - The Unix reads all of this data correctly, and stores it into a file. - TCPSPL sends a 1 byte buffer, containing a 0, via SOUTR% (this indicates an "EOF" in the crufty LPD protocol). - The Unix never sees this final byte of data, and therefore does not send back a protocol acknowlege, causing the spooler to hang. Does anyone know of any bug in the TCP SOUTR% or elsewhere deeper in the TCP code that might explain this? I have verified via the packet tracing facility in the TOPS-20 TCP/IP that the final 0 byte is indeed not being sent in this failing case (and it is sent, as a separate TCP segment, when this code works right). Since there are a number of places where the TCP data changes hands (in TCPJFN/TCPSQO, in TCPBBN/.SEND jsys, in TCPTCP/packetizer+others), some suggestions from someone who has delved into this code would be welcome. Vince Fuller, CMU-CSD ------- 4-Jun-87 18:20:19-PDT,2170;000000000000 Return-Path: Received: from C.CS.CMU.EDU by SU-SCORE.ARPA with TCP; Thu 4 Jun 87 08:55:17-PDT Received: ID ; Thu 4 Jun 87 11:53:08-EDT Date: Thu 4 Jun 87 11:53:05-EDT From: Vince.Fuller@C.CS.CMU.EDU Subject: Another problem with TCP JFNs... To: TOPS-20@SCORE.STANFORD.EDU cc: VAF@C.CS.CMU.EDU Message-ID: <12307834305.6.VAF@C.CS.CMU.EDU> It appears my original attempt to send this mail was lost (maybe due to SCORE's disk failure?). Anyway, here it is again... Once again, I am having problems with a program using TCP JFNs for network I/O. The program is TCPSPL, the TOPS-20 print spooler for printing on Unix printers via the crufty "LPD" protocol. The losing scenario is as follows: - TCPSPL sends a file over the network using SOUTR%'s of up-to-2000 byte chunks of the file. - Unix receives the entire file, as verified by examination of the queue on the remote machine. - TCPSPL sends a single 0 byte (LPD protocol EOF indication), using a one byte SOUTR%. - Unix never sees this 0 byte and thus hangs waiting for it. TCPSPL hangs waiting for the Unix reply, which never occurs. This only happens occaisionally, can't be reproduced at will (except by queuing a lot of print requests and waiting for the occaisional failure), and seems to occur most often when sending large amounts of data. Using the TOPS-20 TCP/IP packet trace facility reveals that, in the failing cases, the final 1 byte long 0 byte is never transmitted by TCP. A packet trace of a successful transaction shows this 0 byte transmitted as a separate 1-byte TCP segment, with PUSH set (as expected). The problem seems to be timing dependant, since the addition of logging code to TCPSPL to log each SOUTR% seemed to cause the problem to cease. The $64,000 question is: does anyone know of any bugs in TOPS-20 TCP that might account for this data loss behavior? Failing that, suggestions on the most likely failure points in the code would be appreciated - a brief look at the (rather vile) TCPJFN/TCPSQO code doesn't reveal anything obvious. Vince Fuller, CMU-CSD ------- 4-Jun-87 18:47:24-PDT,789;000000000000 Return-Path: Received: from MCC.COM by SU-SCORE.ARPA with TCP; Thu 4 Jun 87 17:49:17-PDT Date: Thu 4 Jun 87 18:31:47-CDT From: Clive Dawson Subject: TCP question To: tops20@SCORE.STANFORD.EDU Message-ID: <12307917808.18.AI.CLIVE@MCC.COM> We are noticing an interesting, consistent phenomenon which I'm guessing somebody out there can explain. When we do a remote finger from a Symbolics LispM to our DEC-20, and then use the (PRINT-RECENT-TCP-HEADERS) function on the Symbolics, we are able to observe that the 20 always sends a FIN BEFORE sending the last (partially full) packet of data. Does anybody know the reason for this? We're running Stanford's NETSRV & FINGER if that makes any difference. Thanks, CLive ------- 8-Jun-87 09:58:26-PDT,1837;000000000000 Return-Path: Received: from MARLBORO.DEC.COM by SU-SCORE.ARPA with TCP; Mon 8 Jun 87 09:55:55-PDT Date: 8 Jun 1987 1257-EDT From: Reed B. Powell To: tops-20@score.stanford.edu High-Performance-Systems-Marketing: LCG-DEC10-20 Location: "297-4261 MRO2-2/3C (Pole 5A)" REPLY: "MARKET:: or MRVAX::" Subject: "The times they are a-changin': DEC-MARLBORO Message-ID: <"MS11(5206)+GLXLIB5(0)" 12308894673.17.146.14382 at MARLBORO.DEC.COM> As part of LCG Marketing's plans for being out of business on 30-June-1988, we are working on plans to dismantle system 2244, aka MARKET:: & DEC-MARLBORO, in the very near future. After looking at the usage of the system, which is very low, it does not seem to make sense for DEC to have 2 systems on the ARPAnet, one of which spends most of its time transferring PC utilities via KERMIT. As I said, the life-span of MARKET/DEC-MARLBORO is now quite short: we expect to remove it from active service on 30-June-1987. We are quite anxious to make this as painless as possible, and therefore are soliciting input from anyone who feels this will adversely impact them, so that we can try and make the appropriate arrangements. We are planning on retaining the MARKET and DEC-MARLBORO synonyms for the existing DEC20 within engineering currently on the ARPAnet. We do not expect the KERMIT library to survive this move. We do expect all current internal DEC users to continue to have ARPAnet access. We do not expect to retain external (to DEC) users on the system picking up this load. The Integration Tools Clearinghouse will remain in operation, but without the LCG.CUSTOMER account, whose usage has been minimal. Please send comments, etc., to myself as POWELL@DEC-MARLBORO. thanks,-reed -------- 12-Jun-87 09:48:12-PDT,1326;000000000000 Return-Path: <@wiscvm.wisc.edu:RMF%ADMIN@UNCAEDU.BITnet> Received: from wiscvm.wisc.edu by SU-SCORE.ARPA with TCP; Fri 12 Jun 87 09:45:57-PDT Received: from UNCAEDU.BITnet by wiscvm.wisc.edu ; Fri, 12 Jun 87 11:47:03 CDT Received: from ADMIN by UcEdu.UNCA.AdhocNet.CA with DECNET ; Fri, 12 Jun 87 10:44:11 MDT Date: Wed 3 Jun 87 13:31:49-MDT From: RMF%ADMIN%UNCAEDU.BITNET@wiscvm.wisc.edu Subject: CFCTNF BugHLT To: tops-20%Score.Stanford.Edu.Internet%ADMIN@UNCAEDU.BITnet Phone: (403) 240-6052 Organization: Mount Royal College; Computer Operations Postal-Address: 4825 Richard Rd. S.W.; Calgary, Alberta, T3E 6K6 Message-ID: <12307611980.11.RMF@ADMIN> ReSent-Date: Fri 12 Jun 87 10:42:15-MDT ReSent-From: Russ Forster ReSent-To: Tops-20@Score.Stanford.Edu ReSent-Message-ID: <12309940405.58.RMF@ADMIN> My system just died with a CFCTNF BugHLT, problem is I don't know that this is and can't find it. Can someone tell me what this is or at least where I can find the documentation on it. Thanks in advance. /Russ ----- Russell M Forster DECnet: RMF @ { Admin | Comus | Stasis | Ins } BITnet: RForster @ UncaEdu.BITnet ARPA: Oc.Russ @ CU20B.Columbia.Edu USEnet: siesmo!calgary!vaxa!forster ------- 12-Jun-87 12:28:46-PDT,831;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SU-SCORE.ARPA with TCP; Fri 12 Jun 87 12:28:40-PDT Date: Fri, 12 Jun 1987 15:07 EDT Message-ID: From: Rob Austein To: SU-TOPS-20@SCORE.STANFORD.EDU cc: sra@XX.LCS.MIT.EDU Subject: MIDAS sources? Where do you people keep local MIDAS sources? I noticed that your EXEC has support for MIDAS in the COMPILE command, which seemed like a good idea, so I installed it here, but it didn't do any good because the MIDAS we have here doesn't grok the hairy PRARG% crock that the EXEC and PA1050 use to emulate short TMPCOR blocks. Before going out and writing that code, I thought I'd check if you people had already done so, but I couldn't find your sources. Hence the question. --Rob 12-Jun-87 15:17:54-PDT,1070;000000000000 Return-Path: <@SUMEX-AIM.STANFORD.EDU:Crispin@SUMEX-AIM.Stanford.EDU> Received: from SUMEX-AIM.STANFORD.EDU by SU-SCORE.ARPA with TCP; Fri 12 Jun 87 15:17:50-PDT Received: from KSL-1186-4.Stanford.EDU by SUMEX-AIM.STANFORD.EDU with TCP; Fri, 12 Jun 87 14:38:13 PDT Date: Fri, 12 Jun 87 14:33:21 PDT From: Mark Crispin Subject: re: MIDAS sources? To: Rob Austein cc: SU-TOPS-20@SCORE.STANFORD.EDU Message-ID: <580501153.A0617.KSL-1186-4.Crispin@SUMEX-AIM.Stanford.EDU> Rob - The MIDAS sources used at Stanford are of an old old version. The support for MIDAS in the COMPILE command predates TOPS-20 native mode MIDAS. When KLH nativized MIDAS, I asked about making it use PRARG%, but the response I got back was something to the effect that the problem had been solved in some other way at MIT and if we wanted it we'd have to do it ourselves. Since I was the only use of MIDAS, and I stopped using it in favor of MACRO (sigh), the issue became dead at that point. -- Mark -- 12-Jun-87 15:50:21-PDT,2226;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Fri 12 Jun 87 15:49:39-PDT Return-Path: Received: from Jpl-VLSI.ARPA by SIMTEL20.ARPA with TCP; Fri, 12 Jun 87 13:15:03 MDT Date: Fri, 12 Jun 87 12:13:27 PDT From: swartzbaugh@Jpl-VLSI.ARPA Message-Id: <870612121331.04f@Jpl-VLSI.ARPA> Subject: TOPS-20 AMAR help needed ASAP! To: mrc@simtel20.arpa X-ST-Vmsmail-To: ST%"MRC@SIMTEL20.ARPA" ReSent-Date: Fri, 12 Jun 87 16:51:40 MDT ReSent-From: Mark Crispin ReSent-To: TOPS-20@SCORE.STANFORD.EDU ReSent-Message-ID: <12310007656.19.MRC@SIMTEL20.ARPA> Mark: I am forwarding this help request for my wife(a tops-20 system programmer/man- ager) who does not have access to the ARPA net from her site with the hopes you can forward it to the TOPS-20 distribution list. I am not on the TOPS-20 distribution list so please answer directly to me. ________________________ Message follows ______________________________________ We are running V6.1 edit level 16230 on a TOPS-20 machine in a two machine cluster. I have been trying to use AMAR to get daily CPU utilization statistics for a report that is due first thing tommorrow morning (6/12). We have attempted to use AMAR V4.3 (SYstems Concepts enhanced) and V4.1. The following problems have surfaced with AMAR V4.3: ^ AMAR starts up normally but sometime around one hour later a SYSTAT shows AMAR's state at the EXEC. Advising the job and typing a ^T shows: PUSH DOWN OVERFLOW AT 7536. ^ AMAR will give CPU utilization statistics for the time it runs but a daily report is needed. ^ Systems Concepts no longer has any of the people who wrote the enhancements and they have just now gotten around to trying to reproduce the problem. Of course I am already late and can pro- duce only partial results. With V4.1: ^ This version continues to run and gather data (the files increment in size) but the only report we can extract are tape stats not the daily CPU usage the reports are dependant upon. Any information or clues the reader could provide would be appreciated. 15-Jun-87 00:48:57-PDT,1139;000000000000 Return-Path: <@SUMEX-AIM.STANFORD.EDU:MRC@PANDA.COM> Received: from SUMEX-AIM.STANFORD.EDU by SU-SCORE.ARPA with TCP; Mon 15 Jun 87 00:43:19-PDT Received: from PANDA.COM by SUMEX-AIM.STANFORD.EDU with Cafard; Mon, 15 Jun 87 00:43:42 PDT Date: Mon, 15 Jun 87 00:15:25 PDT From: Mark Crispin Subject: DEC answer to SPR 20-21237 To: TOPS-20@Score.Stanford.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12310623649.8.MRC@PANDA> This is one of the June '87 CTCO's, 6.1 monitor edit 7451. I don't believe this answer. First, if UFPGS% on a closed file is so evil why did it work before 6.1? I don't like suddenly breaking user programs that worked before for no good reason. Second, and what is of greater concern to me -- I looked at the code and it seems quite clear that the FILOFN word in the JFN block is *not* generally cleared after a RELOFN is done on the OFN. Now, it makes sense that it should be cleared, but I don't like zapping things for no good reason. Is anyone else suspicious of this edit? ------- 15-Jun-87 12:02:26-PDT,1201;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Mon 15 Jun 87 11:57:31-PDT Date: Mon, 15 Jun 1987 12:58 MDT Message-ID: From: "Frank J. Wancho" To: TOPS-20@SCORE.STANFORD.EDU cc: WANCHO@SIMTEL20.ARPA Subject: TOPS-20 machines still in the Internet Top 10 Although the Internet is comprised of more Unix machines than all the others combined, it is nonetheless interesting to note that TOPS-20 machines still comprise a significant number of the machines. The following data was extracted from HOSTS.TXT.639. Note that there are several operating systems listed under other names which should have been listed under the Unix catagory. One of the reasons for extracting the data was to see how many operating systems are represented (141), and which ones now need to be added to FTP and possibly the monitor as aliases for Unix... Here are the first ten: 1. 2411 UNIX 2. 387 VMS 3. 157 TAC 4. 139 LISPM 5. 97 EDX 6. 87 ULTRIX 7. 85 MSDOS 8. 62 TOPS20 9. 43 V 10. 33 INTERLISP --Frank 15-Jun-87 12:59:51-PDT,1853;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SU-SCORE.ARPA with TCP; Mon 15 Jun 87 12:59:03-PDT Return-Path: <@KL.SRI.Com,@wiscvm.wisc.edu:BRENT@uwovax.UWO.CDN> Received: from KL.SRI.Com by XX.LCS.MIT.EDU with TCP/SMTP; Sat 13 Jun 87 03:54:28-EDT Received: from wiscvm.wisc.edu by KL.SRI.COM with TCP; Wed 10 Jun 87 14:20:36-PDT Received: from UWOCC1.BITNET by wiscvm.wisc.edu ; Wed, 10 Jun 87 16:19:05 CDT Received: from UWOVAX(MLNET) by UWOCC1 (Mailer X1.23b) id 3541; Wed, 10 Jun 87 16:50:40 EDT From: Brent Sterner To: info-vax@sri-KL.ARPA Date: Wed, 10 Jun 87 16:50:53 EST Subject: CLINK anyone? Message-id: <0550342253@uwovax.UWO.CDN> Cc: 71_105@uwovax.UWO.CDN ReSent-Date: Mon 15 Jun 87 16:01:28-EDT ReSent-From: Betsy Ramsey ReSent-To: TOPS-20@SCORE.STANFORD.EDU ReSent-Message-ID: <12310763104.13.EWR@XX.LCS.MIT.EDU> Anyone have a pointer to a CLINK product for VMS? Apparently we have a user running on our TOPS-10 system who uses CLINK from his PDP-11 to ship files around, and would like to continue using CLINK to the VAX. I suspect this is not of much interest to the net, so reply to me directly. Thanks. Brent. -- Brent Sterner *********************** Lord Protector, d i g i t a l Systems * * Computing & Communications Services * ...this space * Natural Sciences Building * for rent... * The University of Western Ontario * Apply within. * London, Ontario, Canada N6A 5B7 * * Telephone (519)661-2151 x6036 *********************** Network ! VAX 8600 ! IBM 4341 15-Jun-87 17:48:24-PDT,734;000000000000 Return-Path: Received: from MACBETH.STANFORD.EDU by SU-SCORE.ARPA with TCP; Mon 15 Jun 87 17:48:20-PDT Date: Mon 15 Jun 87 17:28:40-PDT From: Rich Alderson Subject: DSKOP To: su-tops-20@SCORE.STANFORD.EDU Message-ID: <12310811747.299.A.ALDERSON@MACBETH.STANFORD.EDU> There is a version of DSKOP available at LOTS, in SSX:DSKOP.MAC, which adds a disk-to-disk copy functionality to the rest of this gem's capabilities. This is handier than the RALPH program because it will work for RA81's as well as older disk types. In addition, the other functions have been updated to allow them to work on RA81's as well. Rich ------- 15-Jun-87 18:06:30-PDT,712;000000000000 Return-Path: Received: from KL.SRI.Com by SU-SCORE.ARPA with TCP; Mon 15 Jun 87 18:04:12-PDT Date: Mon 15 Jun 87 16:19:46-PDT From: Haruka Takano Subject: log function for MAISER? To: MRC%PANDA.COM@SUMEX-AIM.STANFORD.EDU, TOPS-20@SCORE.STANFORD.EDU cc: TAKANO%THOR.HPL.HP.COM@hplabs.hp.com In-Reply-To: <12310623649.8.MRC@PANDA> Message-ID: <12310799205.20.HARUKA@KL.SRI.Com> Does anyone know of a convenient way to see what's being sent to a SMTP port (sort of a log function for MAISER)? Actually, a log of the conversation would be preferable. This is to see if what the foreign site thinks it's sending is actually getting there. --Haruka ------- 16-Jun-87 00:56:15-PDT,703;000000000000 Return-Path: <@SUMEX-AIM.STANFORD.EDU:MRC@PANDA.COM> Received: from SUMEX-AIM.STANFORD.EDU by SU-SCORE.ARPA with TCP; Tue 16 Jun 87 00:54:04-PDT Received: from PANDA.COM by SUMEX-AIM.STANFORD.EDU with Cafard; Tue, 16 Jun 87 00:55:56 PDT Date: Mon, 15 Jun 87 23:48:52 PDT From: Mark Crispin Subject: re: log function for MAISER? To: Haruka@KL.SRI.COM cc: TOPS-20@Score.Stanford.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12310880961.6.MRC@PANDA> It would not be too difficult to modify SMTJFN to make such logs. That is a better place to put that sort of thing in than MAISER. ------- 17-Jun-87 05:44:39-PDT,2126;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SU-SCORE.ARPA with TCP; Wed 17 Jun 87 05:43:45-PDT Date: Wed 17 Jun 87 08:47:06-EDT From: Betsy Ramsey Subject: CFCTNF Bughlt To: TOPS-20@SCORE.STANFORD.EDU Organization: American Mathematical Society Message-ID: <12311208317.18.EWR@XX.LCS.MIT.EDU> I just received a diagnostic patch from DEC that was designed to help find the problem causing CFCTNF bughlts (SPR #:20- 21533, Monitor PCO 860). There was a recent message on this list asking what a CFCTNF bughlt was. Here is how DEC described it in the SPR: "The CFCTNF BUGHLT indicates that a dangerous condition exists on the system. Every cached OFN on the system must have a matching File Access Token which accompanies it. It is through this token that incoming vote requests for a cached token are noticed and by which a cached OFN becomes invalidated. The CFCTNF BUGHLT is issued, during OFN removal, when it is found that a cached OFN does not have a matching File Access Token. This is not a condition which can be tolerated because OFN invalidation may be missed for that particular OFN. But, the very nature of the problem makes the dump almost useless. There may be some traces of the old File Access Token still evident in the free CFS memory. But, there is no way from the dump to reconstruct the events which lead up to the problem. Note that this is not a cluster specific problem as this BUGHLT occurs on non-cluster systems as well." DEC goes on to provide a patch (valid for V6.1 AP13 and above) that, whenever an OFN is cached, checks every OFN on the system to make sure there is a matching File Access Token. If there isn't, the patch will generate a CFCHLT bughlt. DEC says this patch will cause noticable performance degradation, but they don't expect the degradation to be severe. They say they may have to supply other diagnostic patches before they can locate the cause of the problem. They apologize for the inconvenience and are appreciative of our assistance. ------- 17-Jun-87 21:21:26-PDT,735;000000000000 Return-Path: Received: from SCIENCE.UTAH.EDU by SU-SCORE.ARPA with TCP; Wed 17 Jun 87 21:20:27-PDT Date: Wed 17 Jun 87 22:21:59-MDT From: "Douglas J.Hendry" Subject: Multiple NI20s To: Tops-20@SCORE.STANFORD.EDU cc: Hendry@SCIENCE.UTAH.EDU, Hendry@SCIENCE.UTAH.EDU Reply-To: Hendry@Science.Utah.Edu Us-Mail:"Center for Scientific Computing,Univeristy of Utah Us-Mail:"Physics South #210, Salt Lake City, Ut 84112" Telephone: "(801)581-5257" Message-ID: <12311378510.26.OP.HENDRY@SCIENCE.UTAH.EDU> Does anyone know whether two NI-20s can be supported on a single system and be used as a IP router to isolate one of the ethers? Thanks, Doug Hendry ------- 19-Jun-87 21:42:00-PDT,390;000000000000 Return-Path: Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Fri 19 Jun 87 21:40:52-PDT Date: Fri 19 Jun 87 21:44:19-PDT From: Mark Lottor Subject: mmailr/mx records To: tops-20@SCORE.STANFORD.EDU Message-ID: <12311906861.18.MKL@SRI-NIC.ARPA> Has anyone (running a resolver) done any hacking to MMAILR to support MX records? ------- 19-Jun-87 21:46:28-PDT,781;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SU-SCORE.ARPA with TCP; Fri 19 Jun 87 21:46:16-PDT Date: Sat, 20 Jun 1987 00:49 EDT Message-ID: From: Rob Austein To: Mark Lottor Cc: TOPS-20@SCORE.STANFORD.EDU Subject: MMAILR/MX records In-reply-to: Msg of 20 Jun 1987 00:44-EDT from Mark Lottor Date: Saturday, 20 June 1987 00:44-EDT From: Mark Lottor Has anyone (running a resolver) done any hacking to MMAILR to support MX records? I'd be real surprised. The format for getting MX RRs from JEEVES is really gross. MRC and I worked out a better interface, but I'm still debugging the code (sigh). 19-Jun-87 23:44:42-PDT,1599;000000000000 Return-Path: <@SUMEX-AIM.STANFORD.EDU:MRC@PANDA.COM> Received: from SUMEX-AIM.STANFORD.EDU by SU-SCORE.ARPA with TCP; Fri 19 Jun 87 23:44:07-PDT Received: from PANDA.COM by SUMEX-AIM.STANFORD.EDU with Cafard; Fri, 19 Jun 87 23:43:51 PDT Date: Fri, 19 Jun 87 22:54:03 PDT From: Mark Crispin Subject: Re: MMAILR/MX records To: SRA@XX.LCS.MIT.EDU cc: MKL@SRI-NIC.ARPA, TOPS-20@Score.Stanford.EDU In-Reply-To: Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12311919556.8.MRC@PANDA> It will be really trivial to get MX record support into MMailr once Rob Austein's new code is available. I'd also be able to clean up a lot of other bogons that exist in current domain-MMailrs. Please, everyone, wait just a little bit longer...or better yet, offer to help Rob out! Rob, I remembered one rather important thing. MX poop should not be passed to the host is the MX forwarder. For example, SUMEX-AIM is the MX forwarder for PANDA.COM -- SUMEX-AIM should not be told that PANDA.COM can be reached by MX-forwarding to SUMEX-AIM... Of course, I can arrange that the mailer understands about this case and does the right thing (in fact, in the PANDA.COM case SUMEX-AIM won't even consider an Internet name lookup since the Special net takes priority), but it would be nice to have this work for lower-priority nets such as Chaos and Pup (in particular, with working MX you can address Pup-only hosts such as IMSSS and Tiny). ------- 23-Jun-87 09:13:37-PDT,2207;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SU-SCORE.ARPA with TCP; Tue 23 Jun 87 09:09:21-PDT Return-Path: <@KL.SRI.Com:info-vax-request@kl.sri.com> Received: from KL.SRI.Com by XX.LCS.MIT.EDU with TCP/SMTP; Sat 20 Jun 87 00:00:07-EDT Received: from ucbvax.Berkeley.EDU by KL.SRI.COM with TCP; Fri 19 Jun 87 15:55:18-PDT Received: by ucbvax.Berkeley.EDU (5.57/1.26) id AA02432; Fri, 19 Jun 87 15:47:21 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: 19 Jun 87 16:36:04 GMT From: ctp@sally.utexas.edu (Clyde T. Poole) Organization: U. Texas CS Dept., Austin, Texas Subject: DECUS White Paper on Future Large Systems Message-Id: <8302@ut-sally.UUCP> Sender: info-vax-request@kl.sri.com To: info-vax@kl.sri.com ReSent-Date: Tue 23 Jun 87 11:38:28-EDT ReSent-From: Betsy Ramsey ReSent-To: TOPS-20@SCORE.STANFORD.EDU ReSent-Message-ID: <12312812380.25.EWR@XX.LCS.MIT.EDU> Once again I am in the DECUS White Paper business. This time, under the auspices of the U.S. Chapter, Large Systems SIG, I will be writing a paper on the following: "What Should Future Digital Large Systems Look Like?" This is an EXTREMELY broad topic. It is broad on purpose. For the next several weeks (read, until people stop sending things in), I will be accepting suggestions along the following lines: 1) how to break the topic down into smaller topics, 2) actual suggestions on what Digital large systems should be in the future, 3) references that you think are relevant. Please note that you are NOT bound by any existing architecture, network or operating system. ----- Clyde T. Poole, Technical Coordinator, Facilities And Equipment (In Real Life) Decus U. S. Chapter, Large Systems Sig, Newsletter Editor (In My Spare Time) Arpa/Csnet: Ctp@sally.Utexas.Edu Voice: (512) 471-9551 Uucp: {Harvard,Ihnp4,Seismo}!Ut-Sally!Ctp Cis: 75226,3135 Overland: Ut At Austin, Department Of Computer Sciences Taylor Hall 2.124, Austin, Tx 78712-1188 "Life Is A Bitch ... And Then You Die" 25-Jun-87 12:07:56-PDT,1181;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Thu 25 Jun 87 12:05:36-PDT Date: Thu 25 Jun 87 15:09:44-EDT From: Ken Rossman Subject: New CCMD info distribution list available To: TOPS-20@SCORE.STANFORD.EDU, Info-VAX@KL.SRI.COM, Info-Unix@BRL.ARPA Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 Message-ID: <12313375126.207.SY.KEN@CU20B.COLUMBIA.EDU> There is now a new mailing list available, Info-CCMD@CU20B.COLUMBIA.EDU, dealing with the CCMD package (TOPS-20 COMND% Jsys emulation written in C). If you wish to be added to this list, please send mail to: Info-CCMD-Request@CU20B.COLUMBIA.EDU Currently, CCMD runs under Berkeley 4.x Unix, System V, and MS-DOS. We'd like to see some other ports come along too. If there is anyone currently working on porting CCMD to something not mentioned above, or would like to work on porting CCMD to another OS, we'd like to hear about it (VMS comes to mind). CCMD source code is available via ANONYMOUS FTP from CU20B.COLUMBIA.EDU. Files are in directory CCMD: (WS:). ------- 29-Jun-87 06:02:46-PDT,550;000000000000 Return-Path: Received: from DREA-XX.ARPA by SU-SCORE.ARPA with TCP; Mon 29 Jun 87 06:01:36-PDT Date: Sun 28 Jun 87 17:46:38-ADT From: Mark Crispin Subject: bug in 6.1 SYSDPY To: TOPS-20@SCORE.STANFORD.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 USA Phone: +1 (415) 968-1052 Message-ID: <12314179199.11.G.MRC@DREA-XX.ARPA> Bug: SYSDPY can jump to the AC's a lot Cause: ERJMP R's in the code, even though R is an AC Fix: Replace all ERJMP R with ERJMP CPOPJ ------- 4-Jul-87 10:14:19-PDT,2175;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SU-SCORE.ARPA with TCP; Sat 4 Jul 87 10:10:57-PDT Return-Path: <@KL.SRI.Com:info-vax-request@kl.sri.com> Received: from KL.SRI.Com by XX.LCS.MIT.EDU with TCP/SMTP; Sat 4 Jul 87 02:37:45-EDT Received: from ucbvax.Berkeley.EDU by KL.SRI.COM with TCP; Thu 2 Jul 87 20:58:59-PDT Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA10193; Thu, 2 Jul 87 20:39:02 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: 30 Jun 87 18:20:03 GMT From: bgsuvax!denbeste@ohio-state.arpa (William C. DenBesten) Organization: Bowling Green State University B.G., Oh. Subject: DEC 20 manuals available free - you pay shipping Message-Id: <1201@bgsuvax.UUCP> Sender: info-vax-request@kl.sri.com To: info-vax@kl.sri.com ReSent-Date: Sat 4 Jul 87 13:15:56-EDT ReSent-From: Betsy Ramsey ReSent-To: TOPS-20@SCORE.STANFORD.EDU ReSent-Message-ID: <12315713706.55.EWR@XX.LCS.MIT.EDU> I have aproxamately 6 feet of DEC 20 Manuals that we no longer need because we traded the computer in. It looks like it is a complete manual set. We were going to throw them away, but I figured that someone may want them. If you have a DEC 20, the price is right. They occupy four 8x11x17 printout boxes. If you want them, send a note and I will find out the shipping charges to send them to you. I am unwilling to send individual manuals, as I want to get rid of all of them with a minimum of work. --- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- William C. DenBesten |CSNET denbeste@research1.bgsu.edu Dept of Computer Science |ARPA denbeste%research1.bgsu.edu@csnet-relay Bowling Green State University|UUCP ...!cbosgd!osu-eddie!bgsuvax!denbeste Bowling Green, OH 43403-0214 | ------------------------------+---------------------------------------------- There is no difference between theory and practice in theory, but there is often a great deal of difference between theory and practice in practice. 14-Jul-87 01:39:19-PDT,5531;000000000000 Return-Path: Received: from BIONET-20.ARPA by SCORE.STANFORD.EDU with TCP; Tue 14 Jul 87 01:38:21-PDT Date: Tue 14 Jul 87 01:43:10-PDT From: David Roode Subject: For the rest of you who haven't bought your VAX yet To: tops-20@SCORE.STANFORD.EDU Phone: (415) 962-7322 Message-ID: <12318241800.14.ROODE@BIONET-20.ARPA> SUN INTRODUCES 10-MIPS SUPERCOMPUTING WORKSTATION NEW YORK, NY -- July 8, 1987 -- Sun Microsystems, Inc., introduced today the Sun-4 family of 10-MIPS supercomputing workstations and servers that give users the performance of a VAX 8800 system at one-tenth the price. "We expect this product family to redefine workstation computing and create a new price/performance point in the industry," said Bernard Lacroute, Sun's executive vice president. "Sun built its reputation delivering workstations with industry-leading performance at unmatched price/performance levels. The Sun-4/200 Series continues that tradition." "This is not a hardware-only announcement," said Sun President Scott McNealy. "Sun has accomplished something rarely seen in the computing industry by delivering the first supercomputing workstation with a full complement of system and applications software available today." Several original equipment manufacturers, including Valid Logic and LSI Logic, have ported software applications to the new Sun platform, and over 90 third-party software developers have either ported their product or demonstrated intent to port to the new system. The Sun-4/200 Series is ideally suited for all compute-intensive, floating-point or graphics-intensive applications. The primary markets targeted are high-end mechanical-CAD (MCAD) applications, such as solids modeling and finite element analysis, electrical-CAD (ECAD) applications including IC and PC layout and routing; artificial intelligence (AI) development, earth resources, and molecular modelling. The Sun-4 family is source-code compatible with the Sun-3 and Sun-2 families of 680X0 microprocessor-based products, allowing all three product-families to use the same software and be combined in network installations. Sun is also supplying software tools to ease the porting process, allowing migration to the newer, high-performance family of workstations at the user's discretion. Key to the supercomputing workstation series is its new scalable architecture based on RISC (Reduced Instruction Set Computer) technology. Called SPARC for Scalable Processor ARChitecture, it is readily scalable to deliver dramatic performance increases in the future. Sun also announced a new server series based on the SPARC technology that offers the highest performance of any UNIX-based system on the market at dramatically lower costs than conventional superminicomputers. Used as fileservers, compute servers, communication gateways or as cost-effective timesharing systems, these servers are ideal for building highly optimized networks. A Sun-4/260 high-resolution, monochrome deskside workstation with 8 Mbytes of main memory is priced at $39,900. A Sun-4/260 color deskside workstation with 32 Mbytes of main memory, a 560-Mbyte disk subsystem and a 60-Mbyte 1/4-inch cartridge tape system is $85,500. Sample server configurations range from $36,900 for the Sun-4/260S pedestal model with 8 megabytes of main memory to $104,900 for a Sun-4/280S server with 32 megabytes of main memory and 1.2 gigabytes of disk and tape storage. The Sun-4 systems are available 60 to 90 days after receipt of order depending on configuration. Upgrades for Sun-3/260 and Sun-3/160 workstations to the 10-MIPS Sun-4 performance are also available. The upgrades are priced at $13,900 for the Sun-3/260 and at $23,900 for the Sun-3/160. Sun to License RISC Architecture Sun also announced that it will license the new SPARC architecture, operating system and related development tools and compilers to semiconductor and systems manufacturers. This is the first time a major computer systems manufacturer is making its own advanced CPU architecture available to the open market. The licensees will in turn supply chips, boards, and/or complete SPARC-based systems to the open market. SPARC licensees announced today are Fujitsu Microelectronics, Cypress Semiconductor, and Bipolar Integrated Technology. Sun Reduces Base Price of Current 4-MIPS Systems In conjunction with today's announcement of the 10-MIPS Sun-4 family, Sun Microsystems has reduced the base price of its high-end Sun-3/200 Series of 4-MIPS systems by 15-19 percent. With this price reduction, Sun now offers a fully expandable, high-end workstation at a mid-range price. New Software Targets AI Development Sun also introduced the Symbolic Programming Environment (SPE), a set of sophisticated software tools for the development of artificial intelligence applications on Sun's general-purpose workstations. The new tools, which improve productivity and ease program development in the Lisp programming language, offer the first true symbolic programming environment for general-purpose workstations. The Symbolic Programming Environment lists for $3,500 and will be available in the first quarter of 1988 for the Sun-4 and Sun-3 families of workstations. Sun Microsystems, Inc., of Mountain View, California, is the leading supplier of distributed computing systems based on industry standards. ------- 17-Jul-87 09:27:43-PDT,1563;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SCORE.STANFORD.EDU with TCP; Fri 17 Jul 87 09:27:32-PDT Date: Fri, 17 Jul 1987 12:15 EDT Message-ID: From: Rob Austein To: VAF@C.CS.CMU.EDU, SU-TOPS-20@SCORE.STANFORD.EDU cc: SRA@XX.LCS.MIT.EDU Subject: Updates to TFTP.MAC and TFTPSR.MAC I just installed these programs on XX (we finally got rid of our dovers and thus could get rid of the crufty old TFTP server upon which the crufty old dover spooler depended). I made a few changes that might be of interest. A help command in TFTP.MAC (types out HLP:TFTP.HLP, of course). Support for MIT EXEC style PRARG% fork control in TFTP.MAC (fork can execute KEEP {self}, RESET {self}, CONTINUE {self} /STAY). Not interesting unless you install our EXEC patches but very nice if you do. Removed Stanford dependencies in TFTPSR.MAC. Bugfixes I just merged in, the default filespec for local files is now controled by a systemwide logical name (TFTPSR-DEFAULT:) rather than being hardwired in, and I expanded the fix for broadcast TFTP requests to understand all three kinds of nets (classes A, B, & C) as well as subnets. The subnet stuff runs off a table of net numbers and masks, which has to be updated to know about any nets for which subnetting is relevant; right now it knows about MIT (nets 18 and 128.52) and has an entry for Stanford (net 36) present but commented out. Sources are in XX:SRC:TFTP.MAC and TFTPSR.MAC. --Rob 17-Jul-87 15:01:15-PDT,944;000000000001 Return-Path: Received: from SIMTEL20.ARPA by SCORE.STANFORD.EDU with TCP; Fri 17 Jul 87 14:58:09-PDT Date: Fri, 17 Jul 1987 16:02 MDT Message-ID: From: "Frank J. Wancho" To: TOPS20@SCORE.STANFORD.EDU cc: WANCHO@SIMTEL20.ARPA Subject: Other versions of DUMPER? Are there programs available in source form which implement the TOPS20 DUMPER RESTORE capability other than those on the Integration Tools Tapes? I'm specifically looking for versions suitable for IBM mainframes which can properly read and store a mixture of ASCII (7) and Binary (8) filetypes on the same saveset(s) and spanning tapes. Does a complete detailed description of the DUMPER tape format exist other than what can be gleaned from the DUMPER source? The description in the source appears incomplete. Any pointers gratefully accepted. --Frank 21-Jul-87 22:10:05-PDT,1224;000000000000 Return-Path: Received: from humu.nosc.mil by SCORE.STANFORD.EDU with TCP; Tue 21 Jul 87 22:09:14-PDT Received: by humu.nosc.mil (5.54/1.14) id AA01648; Tue, 21 Jul 87 17:48:42 HST Received: by uhmanoa.ICS.HAWAII.EDU (5.51/UUCP-Project/rel-1.0/11-09-86) id AA15854; Tue, 21 Jul 87 15:48:35-1000 Message-Id: <8707220148.AA15854@uhmanoa.ICS.HAWAII.EDU> Date: Tue, 21 Jul 87 15:43:24-1000 From: uhccux!uhmanoa!uhmanoa.ICS.HAWAII.EDU!jeff@humu.nosc.mil (Jeffrey Blomberg) To: tops-20@score.stanford.edu Subject: SNOBOL/SPITBOL for TOPS-20 I am looking for a version of SNOBOL, hopefully native to TOPS-20, to use in place of the old DECUS SNOBOL. We upgraded our KL microcode to the latest revision - yes, the one that makes BLT work right, and SNOBOL fails with the new microcode. I would like to move to the new microcode and have a SNOBOL compiler/interpreter as well; some people still use it... My software referral guide refers to a version from the Stevens Institute of Technology and University of Leeds. Since the guide is dated 1984, I suspect there may be some new information. Any leads would be appreciated...Thanks. Aloha. 22-Jul-87 16:44:15-PDT,691;000000000000 Return-Path: Received: from SRI-NIC.ARPA by SCORE.STANFORD.EDU with TCP; Wed 22 Jul 87 16:43:35-PDT Date: Wed 22 Jul 87 16:48:40-PDT From: Ian Macky Subject: Modernized, snazified IDDT... To: TOPS-20@SCORE.STANFORD.EDU Message-ID: <12320503794.23.IAN@SRI-NIC.ARPA> I have a version of IDDT here that might interest some people. It's extended addressing with internal documentation, new commands, and other good stuff. [SRI-NIC.ARPA]SRC:IDDT.MAC When first run after being compiled it needs to load monitor symbols (which are kept resident) and redump itself. Send bug report to BUG-IDDT@SRI-NIC.ARPA --ian ------- 24-Jul-87 09:08:15-PDT,777;000000000000 Return-Path: Received: from R20.UTEXAS.EDU by SCORE.STANFORD.EDU with TCP; Fri 24 Jul 87 09:06:54-PDT Date: Fri 24 Jul 87 11:12:18-CDT From: Clifford A. Wilkes Subject: MONSYM spelling error To: tops20@SCORE.STANFORD.EDU Department: Computation Center - A20/R20 staff Message-ID: <12320945002.11.CC.WILKES@R20.UTEXAS.EDU> We keep getting complaints from a user that when TELNET fails the error message "RETRANMISSION TIMEOUT" is incorrectly spelled. The error resides in MONSYM. I didn't want to go to the trouble of submitting a bug report to DEC so I'm simply sending this message along in hopes they'll eventually get it and so those who want can make the change to their versions. <@> ------- 26-Jul-87 07:54:23-PDT,2684;000000000000 Return-Path: Received: from MARLBORO.DEC.COM by SCORE.STANFORD.EDU with TCP; Sun 26 Jul 87 07:49:37-PDT Date: 26 Jul 1987 1041-EDT From: "Joe Dempster, DTN: 336.2252 AT&T: 609.665.8711" To: tops20@score.stanford.edu, ailist@sri-stripe.arpa, info-vax@sri-kl.arpa, les@sail.stanford.edu, operator@MARLBORO.DEC.COM, dempster@MARLBORO.DEC.COM Subject: MARKET and PROJECT-10262 news... Message-ID: <"MS11(5206)+GLXLIB5(0)" 12321452832.14.48.4465 at MARLBORO.DEC.COM> RE: MARLBORO.DEC.COM (A.K.A. MARKET, A.K.A. KL2244) and the DEC-10 and PDP-6 History Project (PROJECT-10262). MARKET, as some are already are aware, will cease timesharing for good (after a few past deadlines over the last month) sometime tomorrow or the next day. Only PS: is spinning today, the ARPAnet connection is up and DECnet is turned off. PROJECT-10262 support will shift from MARLBORO.DEC.COM to TOPS20.DEC.COM (A.K.A. GIDNEY), MAIL only: DEMPSTER@TOPS20.DEC.COM No inbound TELNET transfers will be permitted. Les Earnest's WAITS system at Stanford will still accept transfers, MAIL and contributions to the project: FTP CONNECT SAIL.STANFORD.EDU SEND AFN.EXT (6 character file names and 3 for extensions) DSK:AFN.EXT[PUB,LES] and MAIL: LES@SAIL.STANFORD.EDU YIPYIP, PROJECT-10262's standalone 2020, is still available for remote logins: 201-874-8612 201-874-6771 201-874-7122 LOG DEMPSTER.PROJECT-10262 LCGLCG YIPYIP was not very "stable" until recently. If you have had problems accessing it in the past, the system is up almost all the time now--we have been having sever thunder storms here in New Jersey recently though, and power has been flakey, but keep trying. Over the last couple of days I've tried to determine just how long MARKET has been up. It seems that it has been so long that no one remembers exactly when it was first installed. Without "stretching" things too far, MARKET seems to have been up for over 9 years, and maybe even longer. She, excuse the gender identification, ran long well and a few of us will miss her more than others. I'd like to close by thanking Ammie and Butch, 2 fellows in the Marlboro Benchmark Center, who over the last couple of years have kept a friendly old dinosaur running among a bunch of newer and faster machines. And particularly Butch, for turning on the dial-in lines again this weekend. These guys were always ready to help, and getting PROJECT-10262 off the ground would have been much more difficult without their cooperation. logoUT /joe -------- 31-Jul-87 12:50:48-PDT,2174;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SCORE.STANFORD.EDU with TCP; Fri 31 Jul 87 12:50:40-PDT Date: Fri, 31 Jul 1987 15:51 EDT Message-ID: From: Rob Austein To: "J. Noel Chiappa" Cc: sra@XX.LCS.MIT.EDU, vaf@C.CS.CMU.EDU, su-tops-20@SCORE.STANFORD.EDU Subject: TFTP server In-reply-to: Msg of 31 Jul 1987 11:41-EDT from "J. Noel Chiappa" Date: Friday, 31 July 1987 11:41-EDT From: "J. Noel Chiappa" I used to be able to TFTP things into from outside. Now, any attempt to do so seems to get a 'protection error', even though I changed every protection I could find for to 777777. What happened? Background: The change was that we installed VAF's TFTPSR instead of the old CLU monstrosity. TFTPSR uses CHKAC% to make sure that the only file operations allowed are ones that ANONYMOUS could do. Noel's case turns up an obscure point. Diagnosis: XX: has directory protection 777777 and default file protection 777752. This does permit ANONYMOUS to write new files into the directory, but doesn't permit ANONYMOUS to change existing files. TFTPSR first does a GTJFN% on the requested filespec, which (halfway) creates an FDB with the default file protection, then does CHKAC% on that JFN for .CKAWR (write existing file) access, which fails. Cure: Look at bit FB%NXF in the .FBCTL word associated with the JFN we are checking; if this bit is on, the file doesn't yet exist and we want .CKACF (create file) access instead of .CKAWR. XX is now running a TFTPSR with this fix, seems to work fine. I'm not including a SRCCOM because they'd be longer than necessary. I made a number of minor changes to the OPNFIL routine while I was installing this fix, mostly reorganizing the error handling code. Source code is available in [XX]SRC:TFTPSR.MAC. There are some other changes I made when I first put up TFTPSR, generalizations of some Stanford-specific patches and the like. --Rob 3-Aug-87 08:53:38-PDT,712;000000000000 Return-Path: Received: from SRI.Com by SCORE.STANFORD.EDU with TCP; Mon 3 Aug 87 08:43:52-PDT Date: Mon 3 Aug 87 08:43:01-PDT From: David L. Edwards Subject: STRIPE.SRI.COM Obituary To: tops-20@SCORE.STANFORD.EDU cc: 019-staff@SRI.Com Message-ID: <12323561112.14.DLE@SRI.Com> Our beloved Stripe (STRIPE.SRI.COM) passed away on Saturday, August 2. It died from high hospital costs and low usage. It is survived by its father KL (SRI.COM). Its mother (SRI-AI.ARPA) died in May 1986 from similar causes. Stripe was surrounded by its closest friends as life support was removed. All activities being performed by Stripe have been moved to SRI.COM. -dle ------- 7-Aug-87 12:32:18-PDT,534;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SCORE.STANFORD.EDU with TCP; Fri 7 Aug 87 12:32:12-PDT Date: Fri 7 Aug 87 15:29:31-EDT From: "J. Noel Chiappa" Subject: Re: TFTP server To: SRA@XX.LCS.MIT.EDU cc: vaf@C.CS.CMU.EDU, su-tops-20@SCORE.STANFORD.EDU, JNC@XX.LCS.MIT.EDU In-Reply-To: Message-ID: <12324650921.47.JNC@XX.LCS.MIT.EDU> Trying to send a small file to XX provoked a 'unuexpected block number: 256' error message. ------- 14-Aug-87 10:05:23-PDT,602;000000000000 Return-Path: Received: from TOPS20.DEC.COM by SCORE.STANFORD.EDU with TCP; Fri 14 Aug 87 09:59:55-PDT Date: Fri 14 Aug 87 13:01:07-EDT From: Rocket J. Squirrel Subject: HAUNT for DECSYSTEM-20 To: tops20@SU-SCORE.ARPA Message-ID: <12326458914.340.RASPUZZI@TOPS20.DEC.COM> Does anyone out there have sources to a game called HAUNT? A friend of mine is trying to locate sources. He said the original implementor was Professor John Laird from U. of Michigan. Any info or leads is appreciated. Mike R RASPUZZI@TOPS20.DEC.COM ------- 20-Aug-87 15:27:36-PDT,2290;000000000000 Return-Path: Received: from SRI-NIC.ARPA by SCORE.STANFORD.EDU with TCP; Thu 20 Aug 87 15:24:12-PDT Date: Thu 20 Aug 87 15:27:09-PDT From: Mark Lottor Subject: TCP output modes To: tops-20@SCORE.STANFORD.EDU Message-ID: <12328091129.14.MKL@SRI-NIC.ARPA> When opening a TCP connection, you basically get a choice of two modes, interactive and high-throughput. The documents explain them like this (forget about the blocking vs. non-blocking types): .TCMWI (1) Interactive mode. Send all bytes as soon as possible (ie. Send data after each SOUT% or BOUT). This mode attempts to give the most "interactive" response possible by sending many small messages. .TCMWH (2) High throughput mode. Hold data in local buffers until accumulated bytes are sufficient for efficient transmission, or until transmission is requested with the TCOPR% or SOUTR% JSYS. The mode attempts to give high throughput at low overhead by sending large messages. Now it appears that interactive mode doesn't really work (at least not in our monitor (6.1 Stanford)). From the description it seems that it should basically be doing a PUSH after any SOUT or BOUT. It doesn't. Is this broken or was it just never implemented or am I misinterpreting the documentation? For one thing, I noticed that our SMTJFN/MAISER combination sets interactive mode, and then proceeds to do about 5 PSOUT%s followed by a SOUTR%. If I go and fix interactive mode, then one packet will turn into five or six. Should SMTJFN really be using high-throughput mode or is there some reason for all of this? Also TELNET uses high-throughput (buffered) mode and does a SOUTR% for each character typed, when in fact it could use interactive mode and BOUT%. Can anyone explain all the inconsistencies? My feelings on this is that interactive mode should have never existed. Everything should be buffered until an explicit PUSH via SOUTR% or TCOPR%, and in fact this is the way everything currently works since the interactive mode isn't really there. Any comments, please? ------- 20-Aug-87 21:01:41-PDT,1068;000000000000 Return-Path: <@SUMEX-AIM.STANFORD.EDU:MRC@PANDA.COM> Received: from SUMEX-AIM.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Thu 20 Aug 87 20:57:46-PDT Received: from PANDA.COM by SUMEX-AIM.STANFORD.EDU with Cafard; Thu, 20 Aug 87 21:00:11 PDT Date: Thu, 20 Aug 87 19:49:04 PDT From: Mark Crispin Subject: Re: TCP output modes To: MKL%SRI-NIC.ARPA@SUMEX-AIM.Stanford.EDU cc: tops-20@Score.Stanford.EDU.Internet In-Reply-To: <12328091129.14.MKL@SRI-NIC.ARPA> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12328138809.7.MRC@PANDA> Mark - The existance of interactive mode is a crock from NCP days. If I were you I'd ignore it. Once upon a time "high throughput" mode didn't work; there was some path the code took that was wrong and caused crashes in vanilla software. That's why a lot of code still sets "interactive mode". But the two are functionally equivalent and I see no reason at all to implement the difference. -- Mark -- ------- 21-Aug-87 09:52:22-PDT,1117;000000000000 Return-Path: Received: from MATHOM.CISCO.COM by SCORE.STANFORD.EDU with TCP; Fri 21 Aug 87 09:51:51-PDT Date: Fri 21 Aug 87 09:55:11-PDT From: William Westfield Subject: Re: TCP output modes To: MKL@SRI-NIC.ARPA cc: tops-20@SCORE.STANFORD.EDU In-Reply-To: <12328091129.14.MKL@SRI-NIC.ARPA> Message-ID: <12328292839.14.BILLW@MATHOM.CISCO.COM> the intention of Interactive mode is to send packets for every bout or sout. This is NOT the same as settnig the PUSH bit in every packet, though. As you notice, Interactive mode doesn't work (well, it might sort of work for output - I haven't checked). It mainly serves to cause tops20 to use more cycles than necessary to do the same thing as high-throuput mode. I recomend that "interactive mode" NEVER be used. I suspect that it is a holdover from NCP days, when the push bit didn't exist. I think it can be argued that the monitor should never set the push bit for the user - push is largely a user interface feature, and applications should know when it needs to be set. BillW ------- 21-Aug-87 11:58:44-PDT,479;000000000001 Return-Path: Received: from CSLI.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 21 Aug 87 11:58:19-PDT Date: Fri 21 Aug 87 11:39:56-PDT From: Rich Cower Subject: Hack wanted To: tops-20@Score.Stanford.EDU cc: cower@CSLI.Stanford.EDU Message-ID: <12328311911.25.COWER@CSLI.Stanford.EDU> We want to read DUMPER tapes on a Unix (4.2 or Sun 3.x) machine. Anyone have a hack to do it neatly? thanks...Rich ------- 23-Aug-87 22:29:09-PDT,806;000000000000 Return-Path: Received: from SUMEX-AIM.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Sun 23 Aug 87 22:29:07-PDT Date: Sun, 23 Aug 87 22:32:12 PDT From: Mark Crispin Subject: ancient bug lives To: SU-TOPS-20@SCORE.STANFORD.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12328954939.13.CRISPIN@SUMEX-AIM.STANFORD.EDU> Well, at SUMEX anyway. I was in a talk link with Bill Yeager; I was on a dialup (TTY24) and Bill was on a Pup NVT (TTY257). Everything I typed was double echoed. Things looked normal at Bill's end. I remember that this bug from many years ago, but I thought it was fixed a long while ago. Then again, I don't use talk links very much... ------- 23-Aug-87 22:33:35-PDT,1594;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SCORE.STANFORD.EDU with TCP; Sun 23 Aug 87 22:29:41-PDT Date: Sun, 23 Aug 1987 23:32 MDT Message-ID: From: "Frank J. Wancho" To: TOPS-20@SCORE.STANFORD.EDU Subject: Contract or "HPR"? Last year I wrote about the trials and tribulations in connecting a set MICOM 600 lines as "dialups" through a stat mux to our front end. The problem remains. We must use XON/XOFF for flow control - no choice, no binary file transfers possible (unless we use KERMIT), and ^S/^Q is not available. Well, there is a choice, and the one we are using now - no flow control and just tolerate the trash (on an "out-dial" line). Enter the new series of 9600bps asynchronous dialup modems. Some would prefer to be connected at 19.2Kbps (not possible unless you go to Brand X and junk your investment in your present setup). Even at 9600 bps, the error correction protocol, MNP, requires control of the flow. How? By the non-standard RTS/CTS method... DEC faithfully adheres to RS-232C, and this use of RTS/CTS for flow control purposes is not defined. Well, I want it anyway. How do I get it? Do I contract DEC to make RTS/CTS work, even if it against the RS-232C standard? Has anyone done this? Or, is there an "HPR" mechanism I can use (or just use the SPR form)? We have less than a year left for such "development" work, or has that already been forgotten? Anyone want to "co-sign" an SPR requesting RTS/CTS flow control? --Frank 28-Aug-87 07:43:14-PDT,1116;000000000000 Return-Path: Received: from A20.CC.UTEXAS.EDU by SCORE.STANFORD.EDU with TCP; Fri 28 Aug 87 07:40:43-PDT Date: Fri 28 Aug 87 09:47:41-CDT From: Mic Kaczmarczik Subject: Talaris (QMS) driver for TeX under TOPS-20 To: texhax@SCORE.STANFORD.EDU, tops-20@SCORE.STANFORD.EDU Message-ID: <12330104637.12.CC.KACZMARCZIK@A20.CC.UTEXAS.EDU> Does anyone know of a TeX DVI driver for a Talaris 2400 laser printer (QMS engine, Talaris ROM fonts) that runs under TOPS-20? We would like to install TeX on the Academic DEC-20 here, and the only high-quality output device we have is a Talaris 2400. It was rumored that Talaris had one in the past, but our local Talaris rep was not able to find any information. I also know that the DVI family from Utah does not have a QMS driver, although if we had enough time and resources we could modify DVIALW to do the job. Thanks in advance, Mic Kaczmarczik User Services Digital Support Group UT Austin Computation Center cc.kaczmarczik@a20.cc.utexas.edu CCEP001@UTADNX.BITNET ------- 31-Aug-87 18:36:37-PDT,834;000000000000 Return-Path: Received: from uunet.UU.NET by SCORE.STANFORD.EDU with TCP; Mon 31 Aug 87 18:30:29-PDT Received: from munnari.UUCP by uunet.UU.NET (5.54/1.14) with UUCP id AA11682; Mon, 31 Aug 87 21:38:08 EDT Received: from charlie (via mulga) by munnari.oz with SunIII (5.5) id AA03718; Tue, 1 Sep 87 11:18:02 EST Received: by charlie .Deakin (5.52) id AA14703; Tue, 1 Sep 87 08:22:45 EST Date: 01 Sep 87 08:22:43 +1000 (Tue) Message-Id: <104.557446963@charlie> To: Tops20 People Subject: Source to DIRTST From: Craig Warren We have been using a program caled DIRTST for a number of years. It has a bug that I would like to fix at source level. Does anyone know where I might get a copy of the source? 1-Sep-87 13:49:27-PDT,1723;000000000000 Return-Path: <@SUMEX-AIM.STANFORD.EDU:MRC@PANDA.COM> Received: from SUMEX-AIM.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Tue 1 Sep 87 13:48:38-PDT Received: from PANDA.COM by SUMEX-AIM.STANFORD.EDU with Cafard; Tue, 1 Sep 87 13:55:56 PDT Date: Tue, 1 Sep 87 13:46:36 PDT From: Mark Crispin Subject: IMPORTANT patch to MMAILR.MAC.512 To: TOPS-20@Score.Stanford.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12331218552.8.MRC@PANDA> A serious bug was introduced into MMAILR.MAC.512 (the current version). If you are running this version, and ONLY this version, please install the following REDIT: REDIT 1(104) COMPARE by user MRC, 1-Sep-87 13:44:22 File 1: MRC:MMAILR.MAC.512 File 2: MRC:MMAILR.MAC.513 ***** 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==^D512 ;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==^D513 ;MMAILR's edit version  ***** CHANGE #2; PAGE 56, LINE 63; PAGE 56, LINE 63 STCMP% JUMPE A,R ;If the same, then no transmogrification ENDIF. SETZM DOMPTR ;See if there is a real domain DO.  --------------------------------- STCMP% JUMPE A,R ;If the same, then no transmogrification ENDIF. SETZM DOMPTR ;See if there is a real domain MOVE A,BUFPTR DO.  ------- 4-Sep-87 07:42:13-PDT,1049;000000000000 Return-Path: Received: from TOPS20.DEC.COM by SCORE.STANFORD.EDU with TCP; Fri 4 Sep 87 07:38:34-PDT Date: 4 Sep 1987 1037-EDT From: "Greg Scott" To: TOPS-20@SCORE.STANFORD.EDU DTN: 297-2222 Subject: Autopatch tape 16 T20AN.REL Message-ID: <"MS11(6025)+GLXLIB5(0)" 12331937696.275.120.41524 at TOPS20.DEC.COM> It was just discovered that the T20AN.REL that just came out on autopatch tape 16 is missing a couple of last minute patches to MEXEC. The MEXEC in LN2061.REL and the source MEXEC.MAC are correct. To correct the problem, you can use MAKLIB to extract the MEXEC module from LN2061.REL and replace it into T20AN.REL (or just use the source MEXEC.MAC). The missing patches cause random data to be put into the account string in USAGE records and cause connect and run time printed by MEXEC when you LOGOUT to be up to twice what it should be. We apologize for any inconvienence that this error may cause you. Greg Scott Marlboro Software Engineering -------- 4-Sep-87 15:13:36-PDT,949;000000000000 Return-Path: Received: from columbia.edu by SCORE.STANFORD.EDU with TCP; Fri 4 Sep 87 15:08:05-PDT Received: from cunixc.columbia.edu by columbia.edu (5.54/1.14) id AA24979; Fri, 4 Sep 87 18:08:03 EDT Message-Id: <8709042208.AA24979@columbia.edu> Received: by cunixc.columbia.edu (5.54/5.10) id AA12035; Fri, 4 Sep 87 18:08:06 EDT Date: Fri, 4 Sep 87 18:08:06 EDT From: Thomas De Bellis To: munnari!charlie.oz.au!ccw@uunet.uu.net Cc: TOPS20@score.stanford.edu In-Reply-To: Craig Warren's message of 01 Sep 87 08:22:43 +1000 (Tue) <104.557446963@charlie> Subject: Re: Source to DIRTST I have a copy of DIRTST that I've fixed some bugs in. Notably, it makes sure that a directory file is, in fact, a directory file by looking at the FDB bits before trying to verify the file contents. If enough people are interested, I'll make this FTP'able from CU20B. -- Tom 5-Sep-87 14:35:41-PDT,2482;000000000000 Return-Path: Received: from CU20B.COLUMBIA.EDU by SCORE.STANFORD.EDU with TCP; Sat 5 Sep 87 14:26:31-PDT Date: Sat 5 Sep 87 17:23:36-EDT From: Ken Rossman Subject: TOPS20/Unix things To: info-topsux@CU20B.COLUMBIA.EDU, info-ccmd@CU20B.COLUMBIA.EDU, tops20@SCORE.STANFORD.EDU, info-vax@KL.SRI.COM, info-unix@BRL.ARPA, Bboard@CU20B.COLUMBIA.EDU Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 Message-ID: <12332273865.136.SY.KEN@CU20B.COLUMBIA.EDU> PK: was recently created on CU20B.COLUMBIA.EDU for the purpose of storing source code useful for TOPS-to-Unix conversion, and/or intercommunication. For example, I am working on a version of a DUMPER tape reader written in C which will be placed in this directory when done. I believe there are also some TAR tape reader/writer programs around which, if I can find them, I will place in PK: also. Hopefully, we'll be able to build up a Tops/Unix library here. The CU20B system-wide logical name TOPSUX: now points to PK: to make file transfers simpler. The archive file for the Info-TOPSUX mailing list was moved recently to PK:MAIL.TXT, from its previous location in WS: (which no longer exists). At this point, I'd like like to make a request to those who might be willing to contribute any software that fits the category mentioned above (i.e. software that is either TOPS-20 to Unix integration, migration, or intercommunication). If anyone is willing to contribute software, I'd like to collect it here on CU20B in the TOPSUX: directory for general redistribution to any and all interested parties. I'd also be interested in hearing about any work on such software that might currently be in progress. And as usual, in case there are new folks to any of the lists this mail is being posted to, there are two mailing lists here on CU20B that may be of interest to those running TOPS-20 and Unix systems. They are Info-TOPSUX (TOPS-to-Unix conversion issues), and Info-CCMD (a list pertaining to the C language COMND Jsys emulation package being developed here). If you wish to be added to either of these lists, send mail to Info-TOPSUX-Request or Info-CCMD-Request here at CU20B.COLUMBIA.EDU. As always, CCMD source code is available from CU20B.COLUMBIA.EDU via ANONYMOUS FTP in directory "CCMD:". /Ken ------- 10-Sep-87 13:43:31-PDT,715;000000000000 Return-Path: <@uhmanoa.ics.hawaii.edu:jeff@uhccux.uhcc.hawaii.edu> Received: from uhmanoa.ics.hawaii.edu ([128.171.1.1].#Internet) by SCORE.STANFORD.EDU with TCP; Thu 10 Sep 87 13:39:22-PDT Received: from uhccux.uhcc.hawaii.edu (uhccux.hawaii.edu) by uhmanoa.ics.hawaii.edu; Thu, 10 Sep 87 10:41:20-1000 Date: Thu, 10 Sep 87 10:39:22-1000 From: jeff@uhccux.uhcc.hawaii.edu (Jeffrey Blomberg) Message-Id: <8709102039.AA21196@uhccux.uhcc.hawaii.edu> To: tops-20@score.stanford.edu Subject: FTP We are running FTP verison 5.24(14). Just curious if there are any other versions of FTP floating around which have a user interface similar to the ftp implementation on BSD4.x/Ultrix systems. -Jeff 11-Sep-87 11:08:27-PDT,874;000000000001 Return-Path: Received: from june.cs.washington.edu by SCORE.STANFORD.EDU with TCP; Fri 11 Sep 87 11:07:42-PDT Received: by june.cs.washington.edu (5.52.1/6.6) id AA06335; Fri, 11 Sep 87 11:07:25 PDT Date: Fri, 11 Sep 87 11:07:25 PDT From: bob@june.cs.washington.edu (Bob Albrightson) Return-Path: Message-Id: <8709111807.AA06335@june.cs.washington.edu> To: tops-20@score.stanford.edu Subject: Dumper format I have a bunch of dumper savesets that I would like to read but find it difficult because I have no 2060 anymore. I can read the tapes now with this brain-damaged unix utility that is for reading dumper tapes. But what I need to do is find where offline files exist from the savesets. Does anybody have any info about the format of the FDB in the dumper file header? -thanks. -bob 13-Sep-87 23:36:06-PDT,1322;000000000000 Return-Path: Received: from GSB-WHY.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Sun 13 Sep 87 23:36:03-PDT Date: Sun 13 Sep 87 23:35:58-PDT From: Eric M. Berg Subject: SWOFCT buginf; CHECKD To: su-tops-20@Score.Stanford.EDU Reply-To: : a.eric@gsb-why.stanford.edu,a.jiml@gsb-why.stanford.edu Phone-#s: 415/723-1576 (GSB), 415/329-9940 (home) Message-ID: <12334471573.10.A.ERIC@GSB-WHY.Stanford.EDU> Since we started running a new monitor on our -20s in mid-August, we've been seeing a lot of the following message on the CTYs: BUGINF - SWOFCT - OFN share count zero but OFN not cached Has anyone else experienced this? Does anyone know what the cause might be? Also, we recently discovered that it's impossible to run CHECKD simultaneously on two systems which are part of a Common File System. Since CHECKD mounts the structure it's working on as "CHECKD", when you try to start up the program on the second system, it complains about a "drive serial number error or structure naming conflict in cluster" (not an exact rendition of the error message). Is there a version which avoids this problem? (It occurs even when all the CFS disks are dismounted on both systems.) Is this something we should pass on to DEC? ------- 14-Sep-87 10:36:50-PDT,567;000000000000 Return-Path: Received: from R20.UTEXAS.EDU by SCORE.STANFORD.EDU with TCP; Mon 14 Sep 87 10:29:49-PDT Date: Mon 14 Sep 87 12:32:49-CDT From: Kay Nettle Subject: remote line printing To: tops20@SCORE.STANFORD.EDU Message-ID: <12334591146.6.CC.NETTLE@R20.UTEXAS.EDU> We are finally implementing remote line printing over tcp. I have some information that is about two years old and was wondering if anyone had any information on remote print spooling from TOPS-20 to UNIX. Thanks. Kay ------- 15-Sep-87 08:41:02-PDT,1642;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SCORE.STANFORD.EDU with TCP; Tue 15 Sep 87 08:20:42-PDT Date: Tue 15 Sep 87 11:19:33-EDT From: Betsy Ramsey Subject: No .D16 Files on AP16 Tape To: TOPS-20@SCORE.STANFORD.EDU cc: EWR@XX.LCS.MIT.EDU Organization: American Mathematical Society Message-ID: <12334829032.51.EWR@XX.LCS.MIT.EDU> The most recent autopatch tape (16) was sent without the usual .D16 files for the products. These files contained a brief description of the edits. We use these files to determine the potential impact on our users of installing the updated products. Without these files, we are very reluctant to install the autopatch release. The Telephone Support Center has received several calls from users about this problem. The only response they've been able to give is that we should look up each edit in the Dispatch. (There are usually over 30 edits per autopatch release just for the monitor. Then there's the EXEC, Galaxy, DECnet, and all our other layered products. This will take a *great* deal of time.) LCG Software Engineering has consistently stressed that they want the customers to keep up with the latest releases of the software. To that I say, please don't make it any harder! Anything DEC can do to make the .D16 files available to the customer base immediately would be greatly appreciated. We will also be SPR'ing this problem. Betsy Ramsey American Mathematical Society Providence, RI Internet: EWR@XX.LCS.MIT.EDU 401-272-9500 x295 (soon to be EWR@SEED.AMS.COM) ------- 15-Sep-87 11:46:00-PDT,1375;000000000000 Return-Path: <@SUMEX-AIM.STANFORD.EDU:MRC@PANDA.COM> Received: from SUMEX-AIM.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Tue 15 Sep 87 11:41:27-PDT Received: from PANDA.COM by SUMEX-AIM.STANFORD.EDU with Cafard; Tue, 15 Sep 87 11:43:37 PDT Date: Tue, 15 Sep 87 10:49:59 PDT From: Mark Crispin Subject: Benchmark: SC-30M vs. DEC-2065 To: TOPS-20@Score.Stanford.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12334856416.6.MRC@PANDA.COM> I received the following message a few days ago. I felt it was interesting enough to be sent to the rest of the list. For obvious reasons, I've edited out the name of the sender, the application, and the 2065 system used. I will say that the application is a very large text-processing program, and the 2065 is "maximally configured" (memory was not a problem). I have no commercial interest in Systems Concepts. ---------------------------------------------------------------------- I ran ****** on 4 different files and measured CPU time spent by ******. DEC-2065 SC-30 --------------------------------------------- file1 17.2sec 6.3sec file2 23.9sec 9.5sec file3 36.2sec 13.8sec file4 3min36.2sec 1min15.0sec So SC-30 is two to three times faster than DEC-2065! ------- 15-Sep-87 12:40:51-PDT,1003;000000000000 Return-Path: <@wiscvm.wisc.edu:IMHW400@INDYCMS.BITNET> Received: from wiscvm.wisc.edu by SCORE.STANFORD.EDU with TCP; Tue 15 Sep 87 12:37:58-PDT Received: from INDYCMS.BITNET by wiscvm.wisc.edu ; Tue, 15 Sep 87 14:41:19 CDT Received: by INDYCMS (Mailer X1.23b) id 0368; Tue, 15 Sep 87 11:17:19 EST Date: Tue, 15 Sep 1987 11:11 EST From: Mark H. Wood Subject: Re: No .D16 Files on AP16 tape To: We have good reason to be reluctant to install Autopatch 16 without knowing what we are changing: a last-minute patch to the TTY service broke our ACJ (CLOSF%ing a non-controlling TTY JFN now drops the modem signals), and a patch to USAGE% broke LPTSPL's accounting. Any site that bills for printing should certainly NOT install Autopatch 16. I left a nasty note on DSIN when the incomplete tape first came in, and we will also be SPRing the afore- mentioned problems. Caveat installer! 15-Sep-87 18:06:59-PDT,614;000000000000 Return-Path: Received: from bu-cs.BU.EDU by SCORE.STANFORD.EDU with TCP; Tue 15 Sep 87 18:05:58-PDT Return-Path: Received: by bu-cs.BU.EDU (3.2/4.7) id AA01853; Tue, 15 Sep 87 21:08:35 EDT Date: Tue, 15 Sep 87 21:08:35 EDT From: bzs@bu-cs.bu.edu (Barry Shein) Message-Id: <8709160108.AA01853@bu-cs.BU.EDU> To: MRC@PANDA.COM Cc: TOPS-20@Score.Stanford.EDU In-Reply-To: Mark Crispin's message of Tue, 15 Sep 87 10:49:59 PDT <12334856416.6.MRC@PANDA.COM> Subject: Benchmark: SC-30M vs. DEC-2065 Is the SC-40 still a "thing"? -Barry Shein, Boston University 16-Sep-87 07:15:58-PDT,1763;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SCORE.STANFORD.EDU with TCP; Wed 16 Sep 87 07:15:07-PDT Date: Wed 16 Sep 87 10:14:01-EDT From: Betsy Ramsey Subject: [BHamilton: Re: Autopatch 16 .D16 Files] To: TOPS-20@SCORE.STANFORD.EDU cc: EWR@XX.LCS.MIT.EDU Organization: American Mathematical Society Message-ID: <12335079244.32.EWR@XX.LCS.MIT.EDU> I received an indirect response from Buzz Hamilton, who is in charge of 10/20 Autopatch, on the question of the AP16 .Dnn files. I've talked to Buzz and received permission to post his response. Should you wish to reply to him, Buzz can be addressed on the Internet at BHAMILTON%GIDNEY.DEC@DECWRL.DEC.COM. ------- Date: 16 Sep 1987 0907-EDT From: "Buzz Hamilton" Subject: Re: [Betsy Ramsey : No .D16 Files on AP16 Tape] From: VINO::BHAMILTON "Buzz Hamilton" 15-SEP-1987 09:32 Subj: RE: autopatch 16 d16 files Paul is correct .. the omission of edit doc files on tape 16 was intentional. When the edit doc files were first included it was believed that the printed Software Dispatch would be going away. Now it seems that we will be going away before the Dispatch does. The process to support the edit doc files required the maintainers to double their efforts on edit documentation. Rather then redo the process, we feel that the Dispatch provides adequate information on distributed edits. In fact the process to support the dispatch is more established and reliable. We will still provide the APEDIT.RPT file which gives a brief description of the edits on the Autopatch tape and references the Dispatch article. I welcome any feedback that you might provide. -------- ------- 16-Sep-87 07:51:32-PDT,1714;000000000000 Return-Path: Received: from lindy.stanford.edu by SCORE.STANFORD.EDU with TCP; Wed 16 Sep 87 07:51:16-PDT Received: by lindy.stanford.edu; Wed, 16 Sep 87 07:54:39 PDT Received: by Forsythe.Stanford.EDU; Wed, 16 Sep 87 07:53:10 PDT Received: from RL.IB by UKACRL.BITNET (Mailer X1.24) with BSMTP id 9317; Wed, 16 Sep 87 15:22:09 BST Via: UK.AC.RL.EARN; Wed, 16 Sep 87 15:22:08 BST Received: from RL.IB by UK.AC.RL.IB (Mailer X1.24) with BSMTP id 9316; Wed, 16 Sep 87 15:22:08 BS Via: UK.AC.OU.ACSVAX; 16 SEP 87 15:22:04 BST Date: 16-SEP-1987 15:23:16 From: I_MCDONALD%VAX.ACS.OPEN.AC.UK@forsythe.stanford.edu To: TOPS20@score.stanford.edu Subject: Tops-20 V6.1 build Sent by:Ian McDonald, ACS, Open university, Milton Keynes MK7 6AA, U K I_McDonald@uk.ac.ou.acsvax (JANET) I_McDonald@acsvax.ou.ac.uk (rest of the world) I_McDonald@acsvax.ou.ac.uk (ARPA) I_McDonald%ou.acsvax@ac.uk (EARN/BITNET/NETNORTH) PSI%23429080010330::I_McDonald (Vax PSIMAIL) Telephone: (UK)+ 908 653684 LN2060.CTL ========== Just when we thought we were sticking with V5.1 as a final stable system we now find that we have to move to V6.1 and build a monitor (sigh)... The control file used to build the Tops-20 V6.1 monitor (LN2060.CTL)contains the following sequence of DDT instructions... *DDTIBPN[10B *N[10B+2/2 Well DDTIBP is NOT defined anywhere in the standard V6.1 release. The location DDTIBP is mentioned briefly on page B-7 in the V6.1(7030) "Tops-20 Doc File". Does anyone have any ideas on what it is and what is its significance? Regards, Ian McD 16-Sep-87 08:32:12-PDT,1815;000000000000 Return-Path: <@wiscvm.wisc.edu:IMHW400@INDYCMS.BITNET> Received: from wiscvm.wisc.edu by SCORE.STANFORD.EDU with TCP; Wed 16 Sep 87 08:31:40-PDT Received: from INDYCMS.BITNET by wiscvm.wisc.edu ; Wed, 16 Sep 87 10:34:57 CDT Received: by INDYCMS (Mailer X1.23b) id 4049; Wed, 16 Sep 87 07:54:23 EST Date: Wed, 16 Sep 1987 07:47 EST From: Mark H. Wood Subject: Patch for LPTSPL USAGE% problem To: GSCOTT at DEC replied to my note about problems with the Autopatch 16 Monitor, and I thought I should share his note with the group, in case others are having the USAGE% problem that we experienced. I haven't tried the patch myself yet, but plan to soon. Many thanks to GSCOTT for a prompt reply. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The patch to drop DTR on a non-controlling TTY JFN was published in the dispatch. The accounting problem you refer to causes USAGE% JSYSes to fail for spooler and other USAGE% records written by detached jobs such as job 0. (It is not reccomended to run LPTSPL under job 0.) Here is a patch to fix that: $GET SYSTEM:MONITR $ST 140 DDT FFF/ 0 MINUS2: -2 FFF+1/ 0 FFF: UFNI01+40/ MOVE T2,CTRLTT JRST FFF FFF/ 0 SKIPGE T2,CTRLTT FFF+1/ 0 MOVE T2,MINUS2 FFF+2/ 0 JRST UFNI01+41 UFNI01#+41/ CALL UFWFEI# UFNI01#+42/ JRST UFNINX# UFNI01#+43/ HRRM T2,P1(Q1) JRST FFF+3 FFF+3/ 0 CAMN T2,MINUS2 FFF+4/ 0 MOVE T2,CTRLTT FFF+5/ 0 HRRM T2,P1(Q1) FFF+6/ 0 JRST UFNI01+44 FFF+7/ 0 FFF: ^Z $SAVE (on file) MONITR.EXE.1 MONITR.EXE.1 Saved $ $PO Sorry about the missing .D16 files. The autopatch person has been notified. 16-Sep-87 14:48:41-PDT,1225;000000000000 Return-Path: Received: from SUMEX-AIM.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Wed 16 Sep 87 14:48:36-PDT Date: Wed, 16 Sep 87 14:51:50 PDT From: Mark Crispin Subject: STCMP% bug To: SU-TOPS-20@SCORE.STANFORD.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12335162589.95.CRISPIN@SUMEX-AIM.STANFORD.EDU> Stanford TOPS-20's (except for SUMEX) still have this old cretinous bug that I first fixed years ago. Please, can't it get fixed. It breaks the IMAP server. The problem is that STCMP% doesn't work with a OWGBP, and the problem is caused by an ADD T2,[7B5] as a cheap way to decrement a byte pointer. The fix is embarassingly simple: In COMND.MAC, at STRC2:, replace JUMPE T3,[MOVX T1,SC%SUB ;TEST STRING ENDED, IS A SUBSET ADD T2,[7B5] ;DECREMENT BASE POINTER ONE BYTE RET] with IFE. T3 ;TEST STRING ENDED? MOVE T1,T2 ;YES, PREPARE TO DECREMENT BASE POINTER SETO T2, ; BY ONE BYTE ADJBP T2,T1 ;DO IT SO IT WORKS FOR NON-7BIT AND OWBGP'S MOVX T1,SC%SUB ;FLAG TEST STRING IS A SUBSET RET ENDIF. Doumo arigatou gozaimasu. ------- 18-Sep-87 12:45:37-PDT,1396;000000000000 Return-Path: Received: from cs.utah.edu by SCORE.STANFORD.EDU with TCP; Fri 18 Sep 87 12:41:17-PDT Received: by cs.utah.edu (5.54/utah-1.0) id AA01332; Fri, 18 Sep 87 13:43:58 MDT Date: Fri, 18 Sep 87 13:43:58 MDT From: lepreau@cs.utah.edu (Jay Lepreau) Message-Id: <8709181943.AA01332@cs.utah.edu> To: Ken Rossman , info-topsux@cu20b.columbia.edu, tops20@score.stanford.edu Cc: bob@june.cs.washington.edu Subject: Re: TOPS20/Unix things Awhile ago, just before our 20 was turned off (surprise), I did a lot of enhancing of Jim Guyton's old program which reads DUMPER tapes. It's not perfect, but it's the best version I've seen so far. It's avail for anonymous ftp from cs.utah.edu in dist/read20.tar and dist/read20.shar. I'll mail it to people who don't have Internet access. The one important thing I didn't figure out was how to get the archive tape info off the damn tape. We ran a program over the disks before we turned it off, and saved the archive info that way. Chuck Hedrick has a version which does a couple of things in my "todo" file, as it states. I never got around to merging them. Tar: we used to send one out with the old "pcc-20" distribution of years past. It was written by John Romine at Irvine (I think), and is in MACRO. I could dig it up and make it avail if you want it. 18-Sep-87 13:39:37-PDT,1183;000000000000 Return-Path: Received: from larry.cs.washington.edu by SCORE.STANFORD.EDU with TCP; Fri 18 Sep 87 13:35:43-PDT Received: by larry.cs.washington.edu (5.52.1/6.4) id AA12879; Fri, 18 Sep 87 13:34:59 PDT From: bob@larry.cs.washington.edu (Bob Albrightson) Return-Path: Message-Id: <8709182034.AA12879@larry.cs.washington.edu> To: lepreau@cs.utah.edu (Jay Lepreau) Cc: Ken Rossman , info-topsux@cu20b.COLUMBIA.edu, tops20@score.stanford.edu, bob@june.cs.washington.edu Subject: Re: TOPS20/Unix things In-Reply-To: Your message of Fri, 18 Sep 87 13:43:58 -0600. <8709181943.AA01332@cs.utah.edu> Date: Fri, 18 Sep 87 13:34:58 -0700 Jay. As you probably know, I ran into the same problem, but not for the lack of trying. For some reason the tape info for offline files doesn't seem to be filled in properly in the FDB area of the file headers on a dumper tape. If anybody knows where this info can be found it would be greatly appreciated. Surely it must be on the tape someplace, otherwise disk disaster recovery would truly be a disaster. -bob 29-Sep-87 12:59:04-PDT,1402;000000000000 Return-Path: <@SUMEX-AIM.STANFORD.EDU:Crispin@SUMEX-AIM.Stanford.EDU> Received: from SUMEX-AIM.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Tue 29 Sep 87 12:54:32-PDT Received: from KSL-1186-4.Stanford.EDU by SUMEX-AIM.STANFORD.EDU with TCP; Tue, 29 Sep 87 12:53:14 PDT Date: Tue, 29 Sep 87 12:48:46 PDT From: Mark Crispin Subject: 10/20 article in the September '87 "Hardcopy" magazine To: TOPS-20@Score.Stanford.EDU Message-ID: <589912478.A0316.KSL-1186-4.Crispin@SUMEX-AIM.Stanford.EDU> You may want to read an interesting article entitled "Don't Trade In That DECSYSTEM ... Yet!" in the September '87 issue of "Hardcopy". It doesn't really say anything that we don't already know, but it's nice to see one of the VAX rags acknowledge that we exist. I'm quoted in there, and for once was not misquoted to the point of unrecognizably (just in case, I requested that they call me a "consultant" and not mention the Stanford affiliation). All they really got wrong was the status of MM (they called it "a proprietary DECsystem-20 mail system"). I'm also the source (although not attributed) for the $500 price figure for KS-10's (I know of two that sold for that price) and the quote "This machine will see the tick of the new century." [I'm already anticipating all the bugs in Unix, OS, VMS, etc. that will appear then...!] -- Mark -- 29-Sep-87 13:12:53-PDT,1044;000000000000 Return-Path: Received: from MCC.COM by SCORE.STANFORD.EDU with TCP; Tue 29 Sep 87 13:09:21-PDT Date: Tue 29 Sep 87 15:09:32-CDT From: Clive Dawson Subject: DECSystem 10/20 Article To: tops20@SCORE.STANFORD.EDU cc: ls-sig@R20.UTEXAS.EDU Message-ID: <12338551837.43.AI.CLIVE@MCC.COM> Folks on this list should make a special effort to obtain the September 1987 issue of HARDCOPY, which contains an article by Evan Birkhead entitled, "Don't Trade in that DECsystem...YET!" I found it to be a good, balanced account of the state of 10's and 20's today. It contains some good ammo for those of us who might be trying to fend off the inevitable for a little while longer. You'll find references to the Systems Concepts machine, an impressive description of Compuserve's installation (43 DECsystems and 1 SC-30), and a couple of quotes from somebody who "...for the past 18 mths. has had [a DECsystem] installed in his home." (Gee, I wonder who that is?! ;-) Enjoy, Clive ------- 29-Sep-87 15:54:41-PDT,737;000000000001 Return-Path: Received: from gsbacd.uchicago.edu by SCORE.STANFORD.EDU with TCP; Tue 29 Sep 87 15:49:59-PDT Date: 29 Sep 87 17:45:00 CDT From: "FORD,PAUL" Subject: MM,MMAILR,SMTPSV To: "tops-20" Reply-To: "FORD,PAUL" I'd like to know where to FTP recent sources for MM, MMAILR, SMTPSV etc and FTP if available. Our current versions are old and a little flaky (SMTPSV and FTP in particular). We're running a generic 6.1 system with an NIA20. Thanks, Paul Ford Graduate School of Business Computing Services University of Chicago staff_paul@gsbacd.uchicago.edu ------ 29-Sep-87 16:49:23-PDT,825;000000000001 Return-Path: Received: from C.CS.CMU.EDU by SCORE.STANFORD.EDU with TCP; Tue 29 Sep 87 16:45:35-PDT Received: ID ; Tue 29 Sep 87 19:45:03-EDT Date: Tue 29 Sep 87 19:45:02-EDT From: Vince.Fuller@C.CS.CMU.EDU Subject: Re: MM,MMAILR,SMTPSV To: staff_paul@GSBACD.UCHICAGO.EDU cc: tops-20@SCORE.STANFORD.EDU In-Reply-To: Message from ""FORD,PAUL" " of Tue 29 Sep 87 17:45:00-EDT Message-ID: <12338591068.23.VAF@C.CS.CMU.EDU> Versions of FTP and FTPSRT, in common use on TOPS-20's around the net, are the CMU versions. These may be obtained via ANONYMOUS FTP from C.CS.CMU.EDU in the directory PS:. There is also an FTP version maintained by people at Stanford, which you can probably obtain by contacting them. --Vince ------- 29-Sep-87 20:44:17-PDT,833;000000000000 Return-Path: <@SUMEX-AIM.STANFORD.EDU:MRC@PANDA.COM> Received: from SUMEX-AIM.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Tue 29 Sep 87 20:42:58-PDT Received: from PANDA.COM by SUMEX-AIM.STANFORD.EDU with Cafard; Tue, 29 Sep 87 20:41:07 PDT Date: Tue, 29 Sep 87 19:32:01 PDT From: Mark Crispin Subject: Re: MM,MMAILR,SMTPSV To: staff_paul@GSBACD.UCHICAGO.EDU cc: tops-20@Score.Stanford.EDU In-Reply-To: Message from ""FORD,PAUL" " of Tue, 29 Sep 87 17:45:00 PDT Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12338621466.6.MRC@PANDA.COM> SIMTEL20.ARPA's directory has the current supported directory. SUMEX-AIM.STANFORD.EDU's SS: and PANDA.COM's MRC: directories have development sources. ------- 8-Oct-87 20:56:48-PDT,1838;000000000000 Return-Path: Received: from tut.cis.ohio-state.edu (OHIO-STATE.ARPA.#Internet) by SCORE.STANFORD.EDU with TCP; Thu 8 Oct 87 20:53:56-PDT Return-Path: JORGENSEN@OSU-20 Received: from osu-20 by tut.cis.ohio-state.edu (5.52/0.2) id AA16237; Thu, 8 Oct 87 18:12:10 EDT Message-Id: <8710082212.AA16237@tut.cis.ohio-state.edu> Date: Thu 8 Oct 87 18:11:53-EDT From: Confuse A Cat Inc. Subject: Mysterious EOT Markers To: TOPS-20%osu-20@ohio-state.arpa Cc: JORGENSEN%osu-20@ohio-state.arpa I need some help, and was wondering if someone else has had problems similar to ours. It seems that we keep finding logical EOT markers at various places within some of our archival and migration tapes. The trick with these is that when writing to the tape, DUMPER never seems to see the markers-a number of save sets were written past a logical EOT on one archival tape-but when we go to do a retrieval, DUMPER stops dead at the EOT. We have found a way to restore files written past the LEOT, but the question remains as to why the markers are there to begain with. One of the tapes in question was still being written to successfully when we found an EOT about half way through it, causing at least a dozen save sets to be stranded after the logical EOT. The tapes were all written to with either a TU77 or a TU78 at 1600 BPI, under TOPS-20 V6.1 and the version of DUMPER that came with that release. If anyone has had similar problems or has any idea as to the cause, please send me mail. Thanks much. >>Gary Gary Jorgensen JORGENSEN%OSU-20@OHIO-STATE.ARPA The Ohio State University and hopefully real soon now IRCC/CIS Computing Lab JORGENSEN@OSU-20.CIS.OHIO-STATE.EDU ------- 9-Oct-87 15:28:24-PDT,1875;000000000000 Return-Path: Received: from C.CS.CMU.EDU by SCORE.STANFORD.EDU with TCP; Fri 9 Oct 87 15:23:56-PDT Received: ID ; Fri 9 Oct 87 18:24:52-EDT Date: Fri 9 Oct 87 18:23:03-EDT From: Vince.Fuller@C.CS.CMU.EDU Subject: TOPS-20 Address space questions (version 5.4) To: tops-20@SCORE.STANFORD.EDU Message-ID: <12341197584.6.VAF@C.CS.CMU.EDU> While scrounging around in STG looking for some place to reclaim some monitor address space (with TCP+DECNET+local changes, we are pretty much full), I came accross a couple of items that I had questions about... First, the entry in STG: RS (BLKTRN,PGSIZ) ;LCS MEMORY DRIVER BLOCK TRANSFER PAGE BLKTRP==:BLKTRN/PGSIZ ;DEFINE THE PAGE NUMBER Anyone know what purpose this serves? I can't find any reference to either BLKTRN or BLKTRP anywhere in the sources. Also in STG, I found the following which I have questions about: IFN NETN, ;Domain page for scheduler access There is code in PAGEM.MAC that evidentally sets up these resident pages to be page maps for MNTSEC and DOMSEC. Can someone explain how this works and under what circumstance it is necessary? A year ago or so, I added a section like the above for housing the overgrown NIC host table and I am now wondering if it is really necessary to have a page map (which I have set up the same as MNTIX) for this section - it would be nice to reclaim the page of address space if the page is not necessary... If someone can answer these questions (or can suggest what else I might flush to reclaim some address space), I'd be very grateful... --Vince P.S. I know the "right" solution to this problem would be to upgrade to 6.1, but that is not an option given the limited future of TOPS-20 here at CMU. ------- 12-Oct-87 22:55:30-PDT,1184;000000000000 Return-Path: Received: from uunet.UU.NET by SCORE.STANFORD.EDU with TCP; Mon 12 Oct 87 22:53:24-PDT Received: from munnari.UUCP by uunet.UU.NET (5.54/1.14) with UUCP id AA20369; Mon, 12 Oct 87 23:40:02 EDT Received: from charlie (via mulga) by munnari.oz with SunIII (5.5) id AA10487; Tue, 13 Oct 87 12:56:26 EST Received: by charlie .Deakin (5.52) id AA16910; Tue, 13 Oct 87 11:15:43 EST Date: 13 Oct 87 11:15:39 +1000 (Tue) Message-Id: <104.561086139@charlie> To: Tops20 People Subject: Can I run an NIA-20 on Tops20 Version 5.1 From: Craig Warren We are currently running Tops20 V5.1 and look like "acquiring" a NIA-20. I would like to use this device to attch the 20 to our Ethernet. It would be nice to talk TCP/IP on the 20 so that we can communicate with Unix machines around the place. Does anyone know whether I need to run 6.1 to support the NIA-20? Can I get TCP/IP to run with V5.1? And an aside: Has anyone done a SLIP for the 20? Craig Warren ARPA: ccw%charlie.oz.au@uunet.uu.net UUCP: ...!uunet!munnari!charlie.oz!ccw 13-Oct-87 07:04:28-PDT,1006;000000000000 Return-Path: Received: from G.BBN.COM by SCORE.STANFORD.EDU with TCP; Tue 13 Oct 87 07:02:49-PDT Date: 13 Oct 1987 10:00-EDT Sender: CLYNN@G.BBN.COM Subject: Re: TOPS-20 Address space questions (version 5.4) From: CLYNN@G.BBN.COM To: Vince.Fuller@C.CS.CMU.EDU Cc: tops-20@SCORE.STANFORD.EDU Message-ID: <[G.BBN.COM]13-Oct-87 10:00:39.CLYNN> In-Reply-To: <12341197584.6.VAF@C.CS.CMU.EDU> Vince, The DOMSEC page is the monitor's map for section 20 - the mapped FILP.DD (or FLOP.DD) domain database; it is required if the system uses a domain database instead of just a HOSTS.TXT file. The MNTSEC page is the monitor map for the TCP/IP/et. al. locked packet buffers, TCP control blocks & "buffer headers", and the in-core hashed version of the HOSTS.TXT table; it is needed when running TCP/IP/et. al. (it may be possible to combine it with another section if there is enough unused space in it (HOSTS.TXT is unused or very small & not much network traffic)). Charlie 13-Oct-87 07:15:52-PDT,664;000000000000 Return-Path: Received: from C.CS.CMU.EDU by SCORE.STANFORD.EDU with TCP; Tue 13 Oct 87 07:15:42-PDT Received: ID ; Tue 13 Oct 87 10:16:48-EDT Date: Tue 13 Oct 87 10:16:47-EDT From: Vince.Fuller@C.CS.CMU.EDU Subject: Re: Can I run an NIA-20 on Tops20 Version 5.1 To: munnari!charlie.oz.au!ccw@UUNET.UU.NET cc: TOPS20@SCORE.STANFORD.EDU In-Reply-To: <104.561086139@charlie> Message-ID: <12342157638.15.VAF@C.CS.CMU.EDU> A long time ago, I implemented a serial line driver for TOPS-20 TCP/IP. You (and any others interested) are welcome to it. Let me know if you want it, so I can dig it up... --Vince ------- 13-Oct-87 07:30:40-PDT,1516;000000000000 Return-Path: Received: from C.CS.CMU.EDU by SCORE.STANFORD.EDU with TCP; Tue 13 Oct 87 07:30:31-PDT Received: ID ; Tue 13 Oct 87 10:27:21-EDT Return-Path: Received: from XX.LCS.MIT.EDU by C.CS.CMU.EDU with TCP; Tue 13 Oct 87 10:23:29-EDT Date: Tue 13 Oct 87 10:16:39-EDT From: The Mailer Daemon To: VAF@C.CS.CMU.EDU Subject: Message of 13-Oct-87 10:16:22 ReSent-Date: Tue 13 Oct 87 10:27:17-EDT ReSent-From: Vince.Fuller@C.CS.CMU.EDU ReSent-To: TOPS-20@SCORE.STANFORD.EDU, BUG-TOPS20@XX.LCS.MIT.EDU ReSent-Message-ID: <12342159549.15.VAF@C.CS.CMU.EDU> Message failed for the following: EWR@XX.LCS.MIT.EDU.#Internet: Can't forward - unknown host "SEED.AMS.COM" ------------ Received: from Score.Stanford.EDU by XX.LCS.MIT.EDU with TCP/SMTP; Tue 13 Oct 87 10:16:33-EDT Received: from C.CS.CMU.EDU by SCORE.STANFORD.EDU with TCP; Tue 13 Oct 87 07:15:42-PDT Received: ID ; Tue 13 Oct 87 10:16:48-EDT Date: Tue 13 Oct 87 10:16:47-EDT From: Vince.Fuller@C.CS.CMU.EDU Subject: Re: Can I run an NIA-20 on Tops20 Version 5.1 To: munnari!charlie.oz.au!ccw@UUNET.UU.NET cc: TOPS20@SCORE.STANFORD.EDU In-Reply-To: <104.561086139@charlie> Message-ID: <12342157638.15.VAF@C.CS.CMU.EDU> A long time ago, I implemented a serial line driver for TOPS-20 TCP/IP. You (and any others interested) are welcome to it. Let me know if you want it, so I can dig it up... --Vince ------- ------- 13-Oct-87 12:14:48-PDT,871;000000000000 Return-Path: <@SUMEX-AIM.STANFORD.EDU:MRC@PANDA.COM> Received: from SUMEX-AIM.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Tue 13 Oct 87 12:10:45-PDT Received: from PANDA.COM by SUMEX-AIM.STANFORD.EDU with Cafard; Tue, 13 Oct 87 11:59:00 PDT Date: Tue, 13 Oct 87 11:20:53 PDT From: Mark Crispin Subject: Re: Can I run an NIA-20 on Tops20 Version 5.1 To: TOPS-20@Score.Stanford.EDU In-Reply-To: <104.561086139@charlie> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12342202073.6.MRC@PANDA.COM> TOPS-20 5.4 (a varient of 5.1) supports the NIA-20 for TCP/IP only (not DECnet). A PANDA version of 5.4, called 5.5, has several bugfixes. I believe Vince Fuller has done some form of SLIP for the 20. I suspect it would be rather slow and CPU-expensive though. -- Mark -- ------- 15-Oct-87 08:36:53-PDT,538;000000000000 Return-Path: Received: from MCC.COM by SCORE.STANFORD.EDU with TCP; Thu 15 Oct 87 08:33:52-PDT Date: Thu 15 Oct 87 10:28:11-CDT From: Clive Dawson Subject: IMPINC BUGINF's To: tops20@SCORE.STANFORD.EDU Message-ID: <12342694923.45.AI.CLIVE@MCC.COM> Has anybody noticed a significant increase in IMPINC BUGINF's lately? Over the last week or so we've gone from an average of 5 or so per day to about 50 per day. I wonder if this is related to the PSN software upgrade? Clive ------- 15-Oct-87 10:39:32-PDT,1396;000000000000 Return-Path: Received: from lindy.stanford.edu by SCORE.STANFORD.EDU with TCP; Thu 15 Oct 87 10:37:49-PDT Received: by lindy.stanford.edu; Thu, 15 Oct 87 10:38:14 PDT Received: by Forsythe.Stanford.EDU; Thu, 15 Oct 87 10:37:49 PDT Received: from RL.IB by UKACRL.BITNET (Mailer X1.25) with BSMTP id 0377; Thu, 15 Oct 87 15:34:09 BST Via: UK.AC.RL.EARN; Thu, 15 Oct 87 15:34:08 BST Received: from RL.IB by UK.AC.RL.IB (Mailer X1.25) with BSMTP id 0376; Thu, 15 Oct 87 15:34:08 BS Via: UK.AC.OU.ACSVAX; 15 OCT 87 15:34:04 BST Date: 15-OCT-1987 15:05:22 From: I_MCDONALD%VAX.ACS.OPEN.AC.UK@forsythe.stanford.edu To: TOPS20@score.stanford.edu Subject: Bugchk NOCHKR Sent by:Ian McDonald, ACS, Open university, Milton Keynes MK7 6AA, U K I_McDonald@uk.ac.ou.acsvax (JANET) I_McDonald@acsvax.ou.ac.uk (rest of the world) I_McDonald@acsvax.ou.ac.uk (ARPA) I_McDonald@acsvax.ou.ac.uk (EARN/BITNET/NETNORTH) PSI%23429080010330::I_McDonald (Vax PSIMAIL) Telephone: (UK)+ 908 653684 Tops-20 V6.1 and CHKR ===================== We have just moved to V6.1 and during the boot sequence we get a BUGCHK NOCHKR. The BUGS.MAC doesn't help a lot. Can anyone tell me what it is and why we get it. The system runs ok after this event. Regards, Ian McD 16-Oct-87 07:53:13-PDT,1243;000000000000 Return-Path: Received: from ORNL-MSR.ARPA by SCORE.STANFORD.EDU with TCP; Fri 16 Oct 87 07:50:04-PDT Received: by ORNL-MSR.ARPA (5.51/4.9) id AA14349; Fri, 16 Oct 87 10:51:22 EDT Date: Fri, 16 Oct 87 10:51:22 EDT From: jzj@ORNL-MSR.ARPA (Jeff Jones) Message-Id: <8710161451.AA14349@ORNL-MSR.ARPA> To: tops-20@score.stanford.edu Subject: Directory Tree Prog. (Request) Folks, I am in need of a directory tree program which has the ability to move directories from one structure to another. The optimum program would be able to create the directories on the new structure, move the files to the new structure, and optionally delete the directory tree on the old structure. Seems like I remember a DECUS program which did something like this. Unfortunately, I don't have the DECUS tapes and I need to move the directories next week. If a program like this exists, could someone mail the sources or let me retrieve them via anonymous ftp? If a program like this doesn't exist, could I have some thoughts on what you have done (with any shortcuts). Thanks in advance, Jeff Jones Martin Marietta Energy Systems, Inc. Oak Ridge, Tn. (615)576-2335 16-Oct-87 09:19:30-PDT,751;000000000000 Return-Path: Received: from gaskell.csl.sri.com by SCORE.STANFORD.EDU with TCP; Fri 16 Oct 87 09:14:36-PDT Received: by gaskell.csl.sri.com (3.2/4.16) id AA19719 for tops20@SCORE.STANFORD.EDU; Fri, 16 Oct 87 09:15:51 PDT Date: Fri 16 Oct 87 09:15:46-PDT From: David L. Edwards Subject: Re: IMPINC BUGINF's To: AI.CLIVE@MCC.COM Cc: tops20@SCORE.STANFORD.EDU Message-Id: <561399346.0.DLE@csl.sri.com> In-Reply-To: <12342694923.45.AI.CLIVE@MCC.COM> Mail-System-Version: Don't feel too bad... the other day we received over 700 IMPINC's on KL.SRI.COM! I have heard that they should go away in a few weeks when the IMP upgrades are completed. -dle ------- 17-Oct-87 04:39:49-PDT,771;000000000000 Return-Path: Received: from ORNL-MSR.ARPA by SCORE.STANFORD.EDU with TCP; Sat 17 Oct 87 04:38:58-PDT Received: by ORNL-MSR.ARPA (5.51/4.9) id AA20005; Sat, 17 Oct 87 07:40:25 EDT Date: Sat, 17 Oct 87 07:40:25 EDT From: jzj@ORNL-MSR.ARPA (Jeff Jones) Message-Id: <8710171140.AA20005@ORNL-MSR.ARPA> To: tops-20@score.stanford.edu Subject: Directory Tree Prog. (Thanks) Thanks to all who responded to my request for a directory tree program. MERLIN and ARTHUR seem to be the programs of choice. My apologies for the extra blank lines at the end of my original message. I didn't realize they were there until after I had sent the message. Thanks again, Jeff Jones Martin Marietta Energy Systems, Inc. Oak Ridge, Tn (615)576-2335 19-Oct-87 14:14:22-PDT,1852;000000000000 Return-Path: Received: from MACBETH.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Mon 19 Oct 87 14:08:24-PDT Date: Mon 19 Oct 87 13:57:15-PDT From: Rich Alderson Subject: NIs, ARPs, and GHTs To: tops-20@SCORE.STANFORD.EDU Message-ID: <12343803404.12.A.ALDERSON@MACBETH.STANFORD.EDU> We have 4 Tops-20 systems, 3 KLs and a Systems Concepts SC30-M. The KLs have MEISes connecting them to our ethernet; this configuration has been running for years. The SC has an EI, their NI20 work-alike, and since we haven't had to work with such a beast before, we are seeing problems that are new to us. Every 36 hours or so, the ARP tables on the SC overflow. This doesn't surprise me because Stanford has several thousand hosts on the local network, along with any Internet traffic coming in, and the tables are only ^D128 entries long. It looks as if the entries are never aging; I'm also told that making the NI code aware of subnets might help. I have several questions. First, is there some way to set up a SYSTEM:INTERNET-ETHERNET-MAPPINGS.BIN so that it will prevent this from happening? (More basically, how do I set up such a beast at all?) Second, DOES the ARP table age? If so, and the mappings file is not the answer, would increasing the number of entries allow the aging algorithm time to work? Third, if none of the above will work, does anyone out there have NI20s in a strongly subnetted environment? Did you see these problems? How did you solve them? I will summarize all responses for the mailing list, unless asked to exclude any particular response. Rich Alderson P. S. If your mailer won't reach as far as Macbeth.Stanford.EDU, mail to Alderson@Score.Stanford.EDU is automagically forwarded here. rma ------- 19-Oct-87 14:22:45-PDT,912;000000000000 Return-Path: Received: from GSB-HOW.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 19 Oct 87 14:17:50-PDT Date: Mon 19 Oct 87 14:17:13-PDT From: Eric M. Berg Subject: It's that time of the year again... To: tops-20@Score.Stanford.EDU Phone-#s: 415/723-1576 (GSB-CF), 415/329-9940 (home) Message-ID: <12343807038.136.A.ERIC@GSB-HOW.Stanford.EDU> Daylight savings ends this coming Sunday, according to my calendar, so it might be worth checking if your system is ready to handle it. Our system has DSTOFF of 460 (radix 8) = 304 (radix 10) = Sat., Oct. 31 Since DST ends on the previous Sunday, that looks correct. Anyone who picked up Mark Crispin's patch to DATIME.MAC should be in good shape. Of course, with our new VMS system, we don't "suffer" from this problem... we just get to reboot and reset the system clock! ------- 19-Oct-87 14:59:04-PDT,376;000000000000 Return-Path: Received: from SEED.AMS.COM by SCORE.STANFORD.EDU with TCP; Mon 19 Oct 87 14:57:54-PDT Date: Mon 19 Oct 87 17:59:03-EDT From: Betsy Ramsey Subject: NHOSTS in V6.1 AN Monitor To: TOPS-20@SCORE.STANFORD.EDU Message-ID: <12343814653.21.EWR@SEED.AMS.COM> What value are people using for STG parameter NHOSTS? ------- 20-Oct-87 10:40:28-PDT,1823;000000000000 Return-Path: Received: from SEED.AMS.COM by SCORE.STANFORD.EDU with TCP; Tue 20 Oct 87 10:38:55-PDT Date: Tue 20 Oct 87 13:39:56-EDT From: Betsy Ramsey Subject: Values for NHOSTS -- Summary To: TOPS-20@SCORE.STANFORD.EDU cc: EWR@SEED.AMS.COM Message-ID: <12344029628.49.EWR@SEED.AMS.COM> Many thanks to those who responded to my question about what value sites are using for STG parameter NHOSTS. A summary of the responses follows: Ken Rossman sy.Ken@CU20B.COLUMBIA.EDU ^D7001 Clive Dawson AI.CLIVE@MCC.COM ^D10303 Rob Austein SRA@XX.LCS.MIT.EDU N/A Thx-1138 (Marc) WILLIAMS@EDWARDS-2060.ARPA ^D7001 Rich Alderson A.ALDERSON@MACBETH.STANFORD.EDU ^D7001 Jeffrey Blomberg jeff@UHCCUX.UHCC.HAWAII.EDU ^D4001 Jim Lewinson a.Jiml@GSB-WHY.STANFORD.EDU ^D8009 Andrew Sweer SWEER@SUMEX-AIM.STANFORD.EDU ^D8009 Ken Rossman also pointed out problems with the DEC IPHOST program: >P.S. -- If you're having trouble with IPHOST loading your host tables, >could be IPHOST itself, not the monitor. We got "Table is full" errors >here, which it turns out IPHOST was spewing. We use, instead, a program >called IP (which Chris Maio wrote here) to load our tables, and it seems >to work just fine. /Ken Rob Austein said the long-term solution is to use a domain resolver: >I think we separated NHOSTS into several different constants >controlling the various different tables involved; my monitor pack is >offline at the moment due to hardware problems, so I can't check >exactly what we did. And we still overflow the tables all the time. >And half the hosts aren't in the tables anyway. What you need is a >domain resolver. I've just build a monitor with NHOSTS==:^D7001. Thanks for the help! ------- 20-Oct-87 11:28:13-PDT,1297;000000000000 Return-Path: Received: from MCC.COM by SCORE.STANFORD.EDU with TCP; Tue 20 Oct 87 11:27:49-PDT Date: Tue 20 Oct 87 13:28:50-CDT From: Clive Dawson Subject: Re: Values for NHOSTS -- Summary To: tops20@SCORE.STANFORD.EDU In-Reply-To: <12344029628.49.EWR@SEED.AMS.COM> Message-ID: <12344038529.23.AI.CLIVE@MCC.COM> While we're on the subject, I'll mention that we ran into trouble recently when trying to expand our host tables beyond a certain limit. We're still running 5.4, but I suspect this applies to 6.1 as well. The problem was that the tables grew big enough so that the starting address of the HSTSTS table was greater than 377777. (In section INTSEC, of course.) When this happened, all of the immediate instructions (e.g. MOVEI T1,HSTSTS(T2) ) failed, because suddenly HSTSTS started being treated as a negative offset. We made the following change to STG.MAC to warn about this: EMNTLK==:..OFST ;LAST LOCATION TO LOCK DOWN IFN MCCSW,< ;[MCC-30] IFL <377777-HSTSTS>, >;IFN MCCSW ;[MCC-30] It's possible to get around this problem to some extent by changing the order of the various tables so that the biggest one (usually HSTNAM) is last. Clive ------- 23-Oct-87 12:30:02-PDT,595;000000000000 Return-Path: Received: from ECLC.USC.EDU by SCORE.STANFORD.EDU with TCP; Fri 23 Oct 87 12:28:02-PDT Date: Fri 23 Oct 87 12:34:23-PDT From: Maurice J. Wuts Subject: Unix daemons To: tops-20@SCORE.STANFORD.EDU Message-ID: <12344836894.37.WUTS@ECLC.USC.EDU> Back in Jun 85, Walt Haas@utah-20 announced a set of unix daemons written for Tops20. This included RCP support. Since utah-20 is no longer a 20, his sources are no longer readily available. Does anyone else have them or their own RCP? Thanks in advance. Maurice Wuts ------- 26-Oct-87 06:48:09-PST,1069;000000000000 Return-Path: Received: from ORNL-MSR.ARPA by SCORE.STANFORD.EDU with TCP; Mon 26 Oct 87 06:44:06-PST Received: by ORNL-MSR.ARPA (5.51/4.9) id AA22997; Mon, 26 Oct 87 09:47:29 EST Date: Mon, 26 Oct 87 09:47:29 EST From: jzj@ORNL-MSR.ARPA (Jeff Jones) Message-Id: <8710261447.AA22997@ORNL-MSR.ARPA> To: tops-20@score.stanford.edu Subject: Tape copy program (REQUEST) Is there a TOPS-20 program which can make copies of magtapes? We are in the process of transferring data from old tapes onto new ones. The tapes not only include TOPS-20 DUMPER tapes, but also IBM standard labeled tapes (sigh...). The ultimate program would make the copy the tape-to-tape and not care about the label, data, or format of the tape. If a program like this exists, could someone mail me the sources or give me ANONYMOUS FTP access to them? If it doesn't exist, could I have any pointers on how you have handled this in the past. Thanks in advance, Jeff Jones Martin Marietta Energy Systems, Inc. Oak Ridge, Tn (615)576-2335 29-Oct-87 10:36:56-PST,654;000000000000 Return-Path: Received: from ECLA.USC.EDU by SCORE.STANFORD.EDU with TCP; Thu 29 Oct 87 10:32:20-PST Date: Thu 29 Oct 87 10:33:22-PST From: Bruce Tanner Subject: SWOFCT BUGCHK To: TOPS-20@SCORE.STANFORD.EDU Message-ID: <12346398650.60.CERRITOS@ECLA.USC.EDU> Up until a few days ago, we've been getting a couple of SWOFCT (OFN share count zero but OFN not cached) BUGCHKs a month. We've now started getting 500-1000 a day with no known changes in hardware or software. Does anybody know what this really is (it's not in my BUGS.MAC) and what could be causing it? Thanks, -Bruce ------- 29-Oct-87 15:02:08-PST,938;000000000000 Return-Path: Received: from GSB-WHY.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 29 Oct 87 14:58:21-PST Date: Thu 29 Oct 87 15:01:05-PST From: John Wright Subject: Re: SWOFCT BUGCHK To: CERRITOS@ECLA.USC.EDU cc: TOPS-20@Score.Stanford.EDU In-Reply-To: <12346398650.60.CERRITOS@ECLA.USC.EDU> Message-ID: <12346447388.48.A.JOHN@GSB-WHY.Stanford.EDU> We've been getting them also. Chase Manhattan Bank has reported this to DEC. They also claim it has corrupted System 1022 datasets. Are you running 1022, a DBMS from Compuserve Data Tech (previously, Software House), or just using large files? We also run System 1022. Current guess is some fixes DEC released with a recent autopatch may solve this...I am checking into this. What MONITOR and autopatch level are you running? John Wright Stanford University Graduate School of Business ------- 30-Oct-87 05:13:52-PST,2753;000000000000 Return-Path: Received: from TOPS20.DEC.COM by SCORE.STANFORD.EDU with TCP; Fri 30 Oct 87 05:09:15-PST Date: 30 Oct 1987 0811-EST From: "David Lomartire" To: John Wright cc: TOPS-20@SCORE.STANFORD.EDU DTN: 297-5508 Mailstop: MRO1-2/L10 Subject: Re: SWOFCT BUGCHK Message-ID: <"MS11(6027)+GLXLIB5(0)" 12346602256.282.209.39775 at TOPS20.DEC.COM> References: Message from John Wright of 29-Oct-87 1811-EST In-reply-to: <12346447388.48.A.JOHN@GSB-WHY.Stanford.EDU> The SWOFCT BUGCHK was introduced in Autopatch tape 13 with the OFN caching changes. With OFN caching, all OFNs that have a zero share count should be cached. This BUGCHK indicates the an OFN has been selected for swapout, it has a zero share count, and is not cached. This occurs when GCCOR is looking through memory and finds what it believes is a valid OFN to swap out and deallocate. This behavior of GCCOR reflects the old mechanism used by the system to remove non-shared, second level index-blocks from the system. This BUGCHK signifies that these is still some area in the monitor that is using the old mechanisms for deallocating OFNs. This problem has been reported to us and the cause has been found. It has to do with extended section mapping. The SECMAP routine is PAGEM is simply decrementing the share count for the OFN and deleting the section pointer in the map. So, when the section is unmapped, the OFN share count will go to zero. Under the old scheme (pre-OFN caching), GCCOR would be responsible for noticing this OFN and calling DASOFN to deassign it. Now, GCCOR finds this OFN, issues the SWOFCT BUGCHK, and dessigns it. Note that we do not believe that this problem caused the 1022 database corruption reported by Chase Manhattan Bank. They have since upgraded to Autopatch tape 16 (from tape 14) and, at last check, have not experienced any more file problems. Also, the state of the OFN should not cause file damage. The OFN still has a valid File Access Token assigned to it so all cluster-wide arbitration should work as expected. We are currently working on a fix for this problem. We apologize for any inconvenience that this is causing you. It certainly is a mystery why these have increased in number lately. Has Compuserve released a new 1022 with extended addressing capability? This problem has existed since Autopatch tape 13 so the sudden increase is probably due to a change in the application environment as opposed to a change in the monitor. David Lomartire LSBU Software Engineering TOPS-20 Monitor Group -------- 31-Oct-87 17:02:00-PST,783;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SCORE.STANFORD.EDU with TCP; Sat 31 Oct 87 16:57:20-PST Date: Sat, 31 Oct 1987 18:00 MST Message-ID: From: "Frank J. Wancho" To: TOPS20@SCORE.STANFORD.EDU cc: WANCHO@SIMTEL20.ARPA Subject: Dual-porting RP07s A local large TOPS-10 facility claims disk I/O performance improvements by having their RP07s dual-ported. I have heard that TOPS-20 does not take advantage of dual-porting to make the effort worthwhile. Now, with the answer to SPR 20-94 in the 1 October 87 Software Dispatch, I see that at least one site is using the feature. Does anyone else have experience with dual-porting RP07s on a TOPS-20 system? --Frank 1-Nov-87 21:13:04-PST,628;000000000000 Return-Path: Received: from GSB-HOW.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Sun 1 Nov 87 21:13:02-PST Date: Sun 1 Nov 87 21:16:35-PST From: Eric M. Berg Subject: Software Dispatch To: su-tops-20@Score.Stanford.EDU Phone-#s: 415/723-1576 (GSB-CF), 415/329-9940 (home) Message-ID: <12347302175.164.A.ERIC@GSB-HOW.Stanford.EDU> Can someone let me know who at Stanford receives the (TOPS-20) Software Dispatch from DEC, and how it's distributed on campus? We don't ever see it over here at the GSB, and we'd like to arrange to get it. Thanks. ------- 2-Nov-87 18:16:23-PST,674;000000000000 Return-Path: Received: from ECLA.USC.EDU by SCORE.STANFORD.EDU with TCP; Mon 2 Nov 87 18:10:18-PST Date: Mon 2 Nov 87 18:12:19-PST From: Bruce Tanner Subject: Re: SWOFCT BUGCHK To: LOMARTIRE@TOPS20.DEC.COM cc: a.John@GSB-WHY.STANFORD.EDU, TOPS-20@SCORE.STANFORD.EDU In-Reply-To: <"MS11(6027)+GLXLIB5(0)" 12346602256.282.209.39775 at TOPS20.DEC.COM> Message-ID: <12347530774.24.CERRITOS@ECLA.USC.EDU> It turns out that 1022 version 120A was put on SYS: just before the BUGCHKs started. It looks like I found the culprit. We're running AP 15 (AP 16 is lost in the black hole of SDC). Thanks, -Bruce ------- 5-Nov-87 14:30:34-PST,1299;000000000000 Return-Path: Received: from tut.cis.ohio-state.edu (OHIO-STATE.ARPA.#Internet) by SCORE.STANFORD.EDU with TCP; Thu 5 Nov 87 14:19:21-PST Return-Path: DUNLAP@OSU-20 Received: from osu-20 by tut.cis.ohio-state.edu (5.52/0.2) id AA16818; Wed, 4 Nov 87 14:06:47 EST Message-Id: <8711041906.AA16818@tut.cis.ohio-state.edu> Date: Wed 4 Nov 87 14:04:58-EST From: Bryan Dunlap Subject: defining gateways To: tops-20%osu-20@ohio-state.arpa We are running 6.1, and are on an ethernet connected to a fibre backbone by a Proteon P4200. Different lans at OSU are subnets of 128.146.. When we first connected to the backbone, I found the easiest thing to do was turn off subnetting on our -20 and just let the miracle of promiscuous ARP take care of the rest. However, our CS department has set up Sun subnets behind Sun servers that don't do promiscuous ARP, so I need to do subnetting for real. The problem is that I have had a 0% success rate defining our P4200 as a real gateway and routing things through it. I realize I'm probably missing some really simple, obvious point, but what sort of entries should I make in HOSTS.TXT, INTERNET.GATEWAYS, and the like? Thanks in advance for any help. ==BD ------- 9-Nov-87 16:13:15-PST,585;000000000000 Return-Path: Received: from GSB-WHY.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 9 Nov 87 16:13:11-PST Date: Mon 9 Nov 87 16:16:48-PST From: John Wright Subject: Power Supply 'upgrade' for DECsystems To: su-tops-20@Score.Stanford.EDU Message-ID: <12349344755.55.A.JOHN@GSB-WHY.Stanford.EDU> I have some info from CompuServe regarding their replacement power supply as mention in a recent 'Hardcopy' magazine issue. If you would like a copy let me know your ID (or US Postal) mail address. -John- ------- 9-Nov-87 17:22:48-PST,1527;000000000000 Return-Path: Received: from MATHOM.CISCO.COM by SCORE.STANFORD.EDU with TCP; Mon 9 Nov 87 17:20:29-PST Date: Mon 9 Nov 87 17:26:09-PST From: William Westfield Subject: upgrading your power supplies... To: tops-20@SCORE.STANFORD.EDU Message-ID: <12349357379.14.BILLW@MATHOM.CISCO.COM> A while ago I think I mentioned that it might be possible to replace the boat anchor power supply in a decsystem-20 with a more modern switching power supply, and thereby save a lot in power consumption and air-conditioning requirements. Well, it turns out that Compuserve (probably the worlds largest KL user) has already done this, and is probably willing to do it for you, too. I have on my desk a quote from their corporate headquarters that says that for $4000 plus travel, lodging, and so on, they will come out and install 75+% efficient switchers with an expected MTBF of over 100K hours. The upgrade involves new power supplies, a power supply sequencer, and wiring harness. A spares kit (contents unspecified) is $2200. They have a nice chart showing how much money you can expect to save, based on the cost of electricity and your air conditioning efficiency. This ranges from $1204/year (EER=11, $0.03/KWH) to $4120/yr (EER=5, $0.08/KWH). This sounds like a pretty neat deal, especially if you have several KLs lying around... The contact at compuserve is Michael Leskowyak, and he can be reached at (614) 457-8600. Enjoy BillW ------- 9-Nov-87 17:49:51-PST,1120;000000000000 Return-Path: Received: from uunet.UU.NET by SCORE.STANFORD.EDU with TCP; Mon 9 Nov 87 17:49:10-PST Received: from munnari.UUCP by uunet.UU.NET (5.54/1.14) with UUCP id AA04719; Mon, 9 Nov 87 20:53:31 EST Message-Id: <8711100153.AA04719@uunet.UU.NET> Received: from neumann by munnari.oz with SunIII (5.5) id AA28776; Tue, 10 Nov 87 10:53:10 EST Received: by neumann.une.oz (5.52/4.7) id AA21280; Tue, 10 Nov 87 10:49:42 EDT From: munnari!neumann.une.oz.au!gordon@uunet.UU.NET (Gordon J.C. Smith) To: tops20@score.stanford.edu Date: Tue, 10 Nov 87 10:49:39 EDT Subject: Using DEC's TCP/IP-20 product with Bridge CS/200 terminal servers X-Mailer: Elm [version 1.5b] We want to be able to access TOPS-20 over the NIA-20 from Bridge CS/200 servers (and UNIX boxes too). I've just noticed that the TCP/IP-20 SPD states that TCP/IP-20 has not been extensively tested using the ethernet. Can anybody confirm that the above configuration will be OK before I order TCP/IP-20? Thanks, Gordon Computer Centre, Uni. of New England, Armidale, Australia. 10-Nov-87 14:04:32-PST,411;000000000000 Return-Path: Received: from russell.stanford.edu by SCORE.STANFORD.EDU with TCP; Tue 10 Nov 87 14:04:30-PST Received: by russell.stanford.edu (3.2/4.7); Tue, 10 Nov 87 14:05:48 PST Date: Tue, 10 Nov 87 14:05:48 PST From: croft@russell.stanford.edu (Bill Croft) To: su-tops-20@score Subject: please delete Rich Cower from your mailing list, he's taken a new job in Zurich. 11-Nov-87 00:54:54-PST,1288;000000000000 Return-Path: <@SUMEX-AIM.STANFORD.EDU:MRC@PANDA.COM> Received: from SUMEX-AIM.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Wed 11 Nov 87 00:53:32-PST Received: from PANDA.COM by SUMEX-AIM.STANFORD.EDU with Cafard; Wed, 11 Nov 87 00:56:06 PST Return-Path: Received: from XERXES.STACKEN.KTH.SE by PANDA with Cafard; Tue, 10 Nov 87 15:40:11 PST Date: Sun, 8 Nov 87 19:29:36 A From: Peter Lothberg Subject: 15 years, happy birthday party Message-ID: <12349019406.7.ROLL@XERXES> ReSent-Date: Tue, 10 Nov 87 23:46:06 PST ReSent-From: Mark Crispin ReSent-To: TOPS-20@Score.Stanford.EDU ReSent-Message-ID: <12349688692.6.MRC@PANDA.COM> On Friday, 27 November 1987, 1500 local time (that's GMT+1), I will have a small party to celebrate our KI10's (serial number 522) birthday -- 15 years old and still running. It is running SMP TOPS-10 7.02, Phase IV DECnet. Birthday gifts, such as old PDP-10 hardware, manuals and software are welcome. Also, everyone that wants to join the party is hereby invited. (SMP will be released for VAXen by the end of 1988...) Peter Lothberg, Stacken, c/o NADA, Royal Institute of Technology S-100 44 Stockholm, SWEDEN, roll@xerxes.stacken.kth.se ------- 17-Nov-87 10:13:26-PST,1826;000000000000 Return-Path: <@SUMEX-AIM.STANFORD.EDU:MRC@PANDA.COM> Received: from SUMEX-AIM.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Tue 17 Nov 87 10:11:18-PST Received: from PANDA.COM by SUMEX-AIM.STANFORD.EDU with Cafard; Tue, 17 Nov 87 10:12:33 PST Date: Tue, 17 Nov 87 09:49:30 PST From: Mark Crispin Subject: [Stephen M. King : Dec-2020] To: KS-owners@PANDA.COM, TOPS-20@Score.Stanford.EDU, Boken@Topaz.Rutgers.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12351371401.6.MRC@PANDA.COM> Friends, I just got this rather urgent message. Please, someone, help rescue a KS from death and destruction! --------------- Return-Path: <@SUMEX-AIM.Stanford.EDU,@Score.Stanford.EDU:KING@AFSC-HQ.ARPA> Received: from SUMEX-AIM.Stanford.EDU by PANDA.COM with Cafard; Tue, 17 Nov 87 07:38:22 PST Received: from Score.Stanford.EDU by SUMEX-AIM.STANFORD.EDU with TCP; Tue, 17 Nov 87 07:06:22 PST Received: from AFSC-HQ.ARPA by SCORE.STANFORD.EDU with TCP; Tue 17 Nov 87 07:01:47-PST Date: Tue 17 Nov 87 10:04:22-EST From: Stephen M. King Subject: Dec-2020 To: mrc@SU-SCORE.ARPA Postal-address: HQ AFSC/SCRZ, Andrews AFB, DC 20334 Phone: (301) 981-5134; AUTOVON: 858-5134 Mark, Remember that Dec-2020 that I told you that was going to be excessed??? Well, after the 18th of December, it's going to be tossed out in the Brandywine junkyard. It's really a shame. Do you know of anyone that might be interested in it? It cannot be an 'individual' but it's to the point of ANY organization (school, etc) and not just government. If so, contact a Sgt Jodie Adams on 301-981-3322 or 6830. She'll help fill out the forms... but time's closing in. Steve ------- ------- 17-Nov-87 11:17:51-PST,681;000000000000 Return-Path: Received: from MCC.COM by SCORE.STANFORD.EDU with TCP; Tue 17 Nov 87 11:16:52-PST Date: Tue 17 Nov 87 13:21:11-CST From: Clive Dawson Subject: DEC 2020 To: tops20@SCORE.STANFORD.EDU Message-ID: <12351388091.47.AI.CLIVE@MCC.COM> I just called Andrews AFB and inquired about the KS. I thought that our Scout Explorer Post could use it for the kids to play around with. Even though the system is FREE for the taking, transportation charges to Texas from Andrews AFB in Maryland would be prohibitive. Sigh. If a white night is going to ride to the rescue, he/she had better live close to Maryland! Clive ------- 18-Nov-87 23:44:50-PST,2902;000000000000 Return-Path: Received: from Sierra.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 18 Nov 87 23:44:47-PST Date: Wed 18 Nov 87 23:49:50-PST From: Eric M. Berg Subject: [Stephen Hansen : Sierra DECSYSTEM-20 to be replaced.] To: su-tops-20@Score.Stanford.EDU Reply-to: A.ERIC@GSB-HOW.STANFORD.EDU Phone-#s: 723-1576 (GSB-CF), 329-9940 (home) Message-ID: <12351786524.11.BERG@Sierra.Stanford.EDU> In light of the following announcement, perhaps there needs to be some discussion of how we will replace the services that Sierra now provides to the TOPS-20 community at Stanford (i.e. repository for the system sources, the master TTYINI data base for TOPS-20 *and* Unix hosts, etc.)..... --------------- Date: Tue 17 Nov 87 15:16:47-PST From: Stephen Hansen Subject: Sierra DECSYSTEM-20 to be replaced. To: System@Sierra.Stanford.EDU Message-ID: <12351430981.33.HANSEN@Sierra.Stanford.EDU> Dear Sierra User, Sometime in mid-January of next year a replacement system for the current Sierra machine will come on-line. This new system will consist of two identical Sun-3/280 computers from Sun Microsystems. Current plans call for a changeover period of approximately three months during which both the old and the new systems will be available. There are many reasons for replacing the existing Sierra hardware, not the least of which are reliability and cost of maintenance. The age of the Sierra DEC-20 has contributed to a slow but noticeable increase in hardware related downtime, while at the same time the yearly maintenance cost has risen dramatically. Experience with several Sun-3 systems leads us to expect a downtime of less than two percent while hardware maintenance costs will drop by at least 60 percent. Current Sierra users will need to adapt to a new operating system as TOPS-20 is only available on DEC-20 machines. The new system will run SUN-OS, Sun's version of the UNIX operating system. The EE-CF staff has been working for several months to ensure that the necessary software will be available on the new system. Over the next several months we will be posting additional information regarding the changeover itself along with what software will and will not be available on the new system. Documentation, user's guides, and tutorials on UNIX and the UNIX utilities will also be made available. While some initial inconvenience is unavoidable we will be working hard to minimize it and we feel confident that the end result will be a modern, powerful, and flexible system that is more compatible with today's computing environment. Stephen Hansen ------- ------- 19-Nov-87 04:07:52-PST,1376;000000000000 Return-Path: Received: from SRI-NIC.ARPA by SCORE.STANFORD.EDU with TCP; Thu 19 Nov 87 04:04:58-PST Date: Thu, 19 Nov 87 04:08:33 PST From: Mark Lottor Subject: Internet fork loops To: tops-20@SCORE.STANFORD.EDU Message-ID: <12351833620.26.MKL@SRI-NIC.ARPA> Problem: Load goes up to 50; have to crash system. Why: Host PS1.CS.CMU.EDU sends you a bogus TCP packet where the IP header length field plus the TCP header length field is larger than the length of the whole IP packet. This causes the TCP options processing code to loop forever (in some cases). Fix: In TCPTCP, add the following code to make sure the packet is big enough for the headers. Note: I haven't had a chance to test this out yet, but its pretty straight forward and should help if you're having the same problem. --------------- INPRO2: IFN NICSW,< LOAD T1,PIPL,(PKT) ; Get total IP length in bytes LOAD T2,PIDO,(PKT) ; Get IP header length in words LOAD T3,PTDO,(TPKT) ; Get TCP header length in words ADD T2,T3 ; Add header lengths LSH T2,2 ; Convert to bytes CAML T1,T2 ; Is packet big enough for headers? JRST INPRO3 ; Yes, continue then ;flush bogus packet AOS BADPCT ; Count bad packets CALL RETPKT ; Return the packet JRST INPRO0 ; And do next packet INPRO3: >;IFN NICSW ------- 19-Nov-87 16:08:31-PST,514;000000000000 Return-Path: Received: from KL.SRI.COM by SCORE.STANFORD.EDU with TCP; Thu 19 Nov 87 16:07:47-PST Date: Thu 19 Nov 87 16:07:50-PST From: Alan Larson Subject: MACSYMA To: tops-20@SCORE.STANFORD.EDU Message-ID: <12351964561.12.LARSON@KL.SRI.COM> I seem to remember MACSYMA existing in some form of "public domain" version on TOPS-20. Does such exist? What is the version with the Symbolic's license claims in the startup headers? Thanks, Alan ------- 19-Nov-87 21:19:32-PST,1125;000000000000 Return-Path: <@SUMEX-AIM.STANFORD.EDU:MRC@PANDA.COM> Received: from SUMEX-AIM.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Thu 19 Nov 87 21:18:08-PST Received: from PANDA.COM by SUMEX-AIM.STANFORD.EDU with Cafard; Thu, 19 Nov 87 20:51:38 PST Date: Thu, 19 Nov 87 18:08:38 PST From: Mark Crispin Subject: MACSYMA To: TOPS-20@Score.Stanford.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12351986554.10.MRC@PANDA.COM> I poked Symbolics about it, and got a note to the effect that I should write a letter to their attorneys and MIT's attorneys. At that point I punted. I am quite unwilling to argue about the ownership status of MACSYMA with Symbolics and MIT. It may be necessary to try to re-port DOE MACSYMA using CLISP (has anyone done this? MACLISP is *so* primitive!). Since Symbolics is not even willing to sell you a copy of their old DEC-20 MACSYMA any more, one can argue that that version is "abandoned property" and thus has fallen into the public domain. See your lawyer before making any assumptions! ------- 24-Nov-87 04:42:03-PST,2513;000000000000 Return-Path: <114RONAN%SPOOL.LIVPOL.AC.UK@forsythe.stanford.edu> Received: from lindy.stanford.edu by SCORE.STANFORD.EDU with TCP; Tue 24 Nov 87 04:39:13-PST Received: by lindy.stanford.edu; Tue, 24 Nov 87 04:42:14 PST Received: by Forsythe.Stanford.EDU; Tue, 24 Nov 87 04:42:32 PST Received: from RL.IB by UKACRL.BITNET (Mailer X1.25) with BSMTP id 1023; Tue, 24 Nov 87 12:42:01 GMT Via: UK.AC.RL.EARN; Tue, 24 Nov 87 12:42:00 GMT Received: from RL.IB by UK.AC.RL.IB (Mailer X1.25) with BSMTP id 1021; Tue, 24 Nov 87 12:42:00 GM Via: UK.AC.LIVPOL.SPOOL; 24 NOV 87 12:41:52 GMT Date: 24-NOV-1987 12:39:29 From: 114RONAN%SPOOL.LIVPOL.AC.UK@forsythe.stanford.edu To: TOPS-20@score.stanford.edu Subject: Identifying LAT terminals by DECserver name and port name. We have recently installed TOPS20 6.1(7030) in order to use the NIA-20 Ethernet interface. We are using DECserver 100 and 200 to connect LAT terminals to our 2065 over Ethernet. We now wish to be able to identify which physical terminal a user is logged-in from. This is relatively easy with ordinary direct-connect terminals, as you just have a fixed relationship between the terminal number and where you know that terminal is physically located. This is not true with LAT terminals. What we need is to get hold of the DECserver name/number, and the port name/number on that server that is associated with a particular TTY. The NTINF% jsys will return the DECserver name associated with a TTY, and this can be used with the LATOP% jsys to return the server number. But where can we get hold of some sort of port identifier? This information is available on our VAX/VMS systems in the terminal UCB, (VMS equivalent of the TTY DDB). I have asked our local TSC and they are looking into it, but I thought it worth asking the gurus too... There IS something called the "source slot name" in the slot block pointed to by word 4 of the TTY DDB which I thought looked promising, but this always seems to be blank. Any and all ideas gratefully received. Ronan Flood, Liverpool Polytechnic Computer Services, Liverpool, England. ARPA: 114RONAN%VAX.LIVPOL.AC.UK@NSS.CS.UCL.AC.UK or 114RONAN%VAX.LIVPOL.AC.UK@NSS.CS.UCL.EDU BITNET/EARN: 114RONAN@VAX.LIVPOL.AC.UK or 114RONAN%UK.AC.LIVPOL.VAX@AC.UK or 114RONAN%UK.AC.LIVPOL.VAX@UKACRL 29-Nov-87 15:58:24-PST,851;000000000000 Return-Path: Received: from SUMEX-AIM.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Sun 29 Nov 87 15:58:15-PST Date: Sun, 29 Nov 87 16:03:11 PST From: Mark Crispin Subject: TTYINI change request To: SU-TOPS-20@SCORE.STANFORD.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12354585157.16.CRISPIN@SUMEX-AIM.STANFORD.EDU> Would some nice person please change the terminal type for my Ethertip port in {Sierra}FINGER:TTYINI.NET-BASE from VT125 to GIGI? Also, when the plug is pulled on Sierra I hope that the TTYINI stuff is moved to some system where I could make this piddly sort of change myself, ideally via some tool that allows any user on a private Ethertip port to update his own port's entry. ------- 2-Dec-87 09:14:52-PST,695;000000000000 Return-Path: Received: from KL.SRI.COM by SCORE.STANFORD.EDU with TCP; Wed 2 Dec 87 09:13:29-PST Date: Wed 2 Dec 87 09:18:44-PST From: Haruka Takano Subject: domain software for 5.3 To: TOPS-20@SCORE.STANFORD.EDU Message-ID: <12355297961.24.HARUKA@KL.SRI.COM> We're running a 5.3 system (MEIS+Stanford monitor mods) and would like to find/procure the most up-to-date domain software that will run on a 20. We're more interested in user side of this (i.e. the stuff that queries a server) rather than the server side. Something that can talk with a BIND server would be ideal. Thanks in advance for any info/pointers. --Haruka ------- 2-Dec-87 10:53:44-PST,757;000000000000 Return-Path: Received: from A20.CC.UTEXAS.EDU by SCORE.STANFORD.EDU with TCP; Wed 2 Dec 87 10:53:21-PST Date: Wed 2 Dec 87 12:57:13-CST From: Donald A Kassebaum Subject: Tex driver for Talaris/QMS Laser Printer To: tops-20@SCORE.STANFORD.EDU Message-ID: <12355315887.7.CC.KASSEBAUM@A20.CC.UTEXAS.EDU> We will be installing Tex on the one of our 2060s which has two Talaris 2400 Laser printers. We are using them mostly with Scribe now, but have been getting request for Tex. The Talaris is similar to a QMS laser printer which talk QUIC code. I am looking for a DVI-to-QUIC code converter. Pointer to sources of any DVI converter would be helpful. Dak ------- 3-Dec-87 10:30:51-PST,1186;000000000000 Return-Path: <@SUMEX-AIM.Stanford.EDU:MRC@PANDA.COM> Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 3 Dec 87 10:13:46-PST Received: from PANDA.COM by SUMEX-AIM.Stanford.EDU with Cafard; Thu, 3 Dec 87 10:18:36 PST Date: Thu, 3 Dec 87 10:10:43 PST From: Mark Crispin Subject: supported domain mailer for TOPS-20 To: TOPS-20@Score.Stanford.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12355569568.6.MRC@PANDA.COM> Friends - As of yesterday, 12/2/87, SUMEX has been beta-testing a major new release of the TOPS-20 mailsystem that supports domains including MX record support. There have been a few rough edges, but everything seems to be coming together nicely. Sometime in the next few days I will release a beta test version for other sites. This version of the mailsystem uses Chives, the MIT domain resolver, and will not work under the old ISI domain resolver. I recommend that sites installing domain software for the first time go with Chives, and that current ISI resolver sites plan a migration to Chives. -- Mark -- ------- 4-Dec-87 12:44:44-PST,1764;000000000000 Return-Path: Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 4 Dec 87 12:41:15-PST Date: Fri, 4 Dec 87 12:46:29 PST From: Mark Crispin Subject: MACRO lossage To: TOPS-20@Score.Stanford.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12355860068.60.CRISPIN@SUMEX-AIM.Stanford.EDU> I just encountered a misfeature in MACRO where it assembled bad code. Specifically, I have a large output buffer in memory (half a section) called OUTBUF. I needed to determine its length for a SOUTR%, since it may contain nulls. To do this, I was doing something like: LDB C,[POINT 30,A,35] ; get terminating address of string SUB C,[OUTBUF] ; compute number of full words used LDB A,[POINT 6,A,5] ; get position of final byte ADDI A,-61(A) ; add residual byte count The reason OUTBUF is in a literal is that it's a section 3 address (its actual value is 3,,400000) and this code is running in section 1. Unfortunately, MACRO assembled in the TOPS-10 OUTBUF UUO. I had long forgotten about it (it's been almost 10 years since I actually used an OUTBUF UUO). This program is totally native TOPS-20; it's assembled into non-zero sections and doesn't even have a page 0 or JOBDAT (it uses PDV's). So, I never thought I'd see an obscure TOPS-10 UUO pop up... I doubt DEC will change MACRO now, so be wary of the following built- in symbols in MACRO: CALL, INIT, CALLI, OPEN, TTCALL, RENAME, IN, OUT, SETSTS, STATO, GETSTS, STATZ, INBUF, OUTBUF, INPUT, CLOSE, RELEAS, MTAPE, UGETF, USETI, USETO, LOOKUP, ENTER. Also, apparently MACRO has some of the CALLI's built in as well. ------- 4-Dec-87 15:47:08-PST,649;000000000000 Return-Path: <@SUMEX-AIM.Stanford.EDU:Crispin@SUMEX-AIM.Stanford.EDU> Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 4 Dec 87 15:47:04-PST Received: from KSL-1186-4.Stanford.EDU by SUMEX-AIM.Stanford.EDU with TCP; Fri, 4 Dec 87 15:41:36 PST Date: Fri, 4 Dec 87 15:35:47 PST From: Mark Crispin Subject: NREMIND program To: SU-TOPS-20@Score.Stanford.EDU Message-ID: <595628499.A0355.KSL-1186-4.Crispin@SUMEX-AIM.Stanford.EDU> One of our users asked about a program called NREMIND which seems to exist on Turing and How. Can anyone give any information about it? -- Mark -- 5-Dec-87 00:37:02-PST,4573;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SCORE.STANFORD.EDU with TCP; Sat 5 Dec 87 00:36:13-PST Date: Sat, 5 Dec 1987 03:41 EST Message-ID: From: Rob Austein To: TOPS-20@SCORE.STANFORD.EDU Subject: Support for supported domain mailer for TOPS-20 Reply-To: Bug-CHIVES@XX.LCS.MIT.EDU In-reply-to: Msg of 3 Dec 1987 13:10-EST from Mark Crispin I was going to wait until I got back from DECUS to announce this, but in light of Mark's message I might as well do so now. The resolver portion of the CHIVES system, an implementation of the domain name system protocols, is about ready for a formal beta-release. The code consists of: The resolver itself, RESOLV, which runs as a system fork, communicating with local processes via IPCF and with foreign nameservers via UDP. The normal way of communicating with RESOLV is via the GTDOM% JSYS (below), but it is possible to issue queries directly via IPCF if desired. GTDOM.MAC, which provides the user interface. GTDOM is primarily intended to be run as a JSYS (GTDOM%), but can, with some effort, be made to work in user context. MIT GTDOM% is compatible with ISI's GTDOM% and with the original GTHST% JSYS, for those functions which ISI GTDOM% and GTHST% implement. In addition, there are several new functions for mailsystem support; more may be added as I see a need. Several support programs, which handle things like zone transfers and control dialog with the resolver. These are not as far along as RESOLV and GTDOM, so they may not be included in the initial beta-release. GTDOM% is of course implemented in MACRO-20. All the other code is implemented in C, using the Stanford/SRI KCC compiler. GTDOM% has proven to be quite stable: it has been running on XX.LCS.MIT.EDU, C.CS.CMU.EDU, and SUMEX-AIM.STANFORD.EDU for several months now, without any known system problems. If the resolver doesn't answer a query within a reasonable period of time, or if the resolver isn't available, GTDOM% just returns a temporary error. The only bad news is that GTDOM% requires a few additions to IPCF.MAC, to permit sending and receiving paged IPCF messages in monitor context (sending paged IPCF from monitor context is supported by DEC as of 6.1, for use by the QUEUE% JSYS). So far this has been done for releases 5.4 and 6.1 at source sites; there shouldn't be any serious problem for any version of TOPS-20 after 5.0. I have a volunteer who wants to try installing GTDOM% in a non-source version of 6.1; it won't be pretty, but it should be relatively straightforward. The beta-version of RESOLV will support, among other things, search paths. The only major omission is negative caching, because it's only within the last few weeks that the necessary information has begun to be available. Depending on how long this takes to implement, it may or may not be in the initial beta-version. The CHIVES system is not quite ready for public consumption yet. There are a few minor last-minute changes, mostly things that came up while Mark was debugging the domain mailer. I also need to update and expand the documentation; right now you have to read the code to figure out what a lot of the options do. This shouldn't take very long, so the beta-release should be available before Christmas for those of you who like to test things while your users are elsewhere. I'll be giving a talk on the domain name system on Wednesday at DECUS, attendees can ask questions then. For those who have to worry about legal issues: CHIVES is freeware, with a copyright by MIT intended to keep it that way. This, along with the (no) warranty policy, is spelled out in a short notice which is distributed along with the code. If you have any worries in this regard, I'll be happy to send you a copy of the notice (preferably via email); send mail to BUG-CHIVES. We are not currently set up to do tape distribution; if you need this, send mail to BUG-CHIVES and we'll see what we can work out. Lastly, I'd like to publicly thank Mark Crispin and Vince Fuller for alpha-testing CHIVES and for providing both code and ideas for enhancements. Ken Harrenstien and Ian Macky also deserve kudos for cheerfully putting up with a massive barrage of KCC bug reports and for fixing the bugs as fast as they were reported. I'll send another short message describing where the code can be found, once it's ready. --Rob 5-Dec-87 11:02:36-PST,679;000000000000 Return-Path: <@SUMEX-AIM.Stanford.EDU:MRC@PANDA.COM> Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Sat 5 Dec 87 11:02:08-PST Received: from PANDA.COM by SUMEX-AIM.Stanford.EDU with Cafard; Sat, 5 Dec 87 11:07:15 PST Date: Sat, 5 Dec 87 10:47:18 PST From: Mark Crispin Subject: CSKBUG bughlts To: TOPS-20@Score.Stanford.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12356100516.6.MRC@PANDA.COM> Has anyone else been seeing CSKBUG bughlts from the CALL FFORKI in JOBCOF? The fork lock code is totally gross and it looks like it is subject to timing races. ------- 14-Dec-87 16:58:06-PST,774;000000000000 Return-Path: Received: from SRI-NIC.ARPA by SCORE.STANFORD.EDU with TCP; Mon 14 Dec 87 16:55:41-PST Date: Mon, 14 Dec 87 17:01:03 PST From: Mark Lottor Subject: ip bug To: tops-20@SCORE.STANFORD.EDU Message-ID: <12358527849.25.MKL@SRI-NIC.ARPA> We've been running with the last bug fix I sent out without any problems. Also, another useful tidbit of code comes from BBN. It keeps wrong option counts from screwing you. In TCPTCP in routine TCPXXO, add the two lines: ILDB OPT,RP ; Get option length CALL @OPTXOF(T1) ; Interpret option LDB OPT,RP ; Option length IFN NICSW,< CAIGE OPT,2 ; Make sure at least this long MOVEI OPT,2 ; So we don't lose >;IFN NICSW SUBI RC,1 ; Count option code ------- 15-Dec-87 09:48:44-PST,1055;000000000000 Return-Path: Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 15 Dec 87 09:48:42-PST Date: Tue, 15 Dec 87 09:24:23 PST From: Mark Crispin Subject: STCMP% bug To: SU-TOPS-20@Score.Stanford.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12358706859.16.CRISPIN@SUMEX-AIM.Stanford.EDU> Stanford TOPS-20 still has a bug in STCMP% that makes it lose with OWGBP's. This has been fixed at SUMEX for ages. Some kind soul, please fix the standard Stanford sources! The fix is at STRC2 in COMND.MAC; delete: JUMPE T3,[MOVX T1,SC%SUB ;TEST STRING ENDED, IS A SUBSET ADD T2,[7B5] ;DECREMENT BASE POINTER ONE BYTE RET] and in its place add: IFE. T3 ;TEST STRING ENDED? MOVE T1,T2 ;YES, PREPARE TO DECREMENT BASE POINTER SETO T2, ; BY ONE BYTE ADJBP T2,T1 ;DO IT SO IT WORKS FOR NON-7BIT AND OWGBP'S MOVX T1,SC%SUB ;FLAG TEST STRING IS A SUBSET RET ENDIF. ------- 15-Dec-87 09:48:51-PST,1321;000000000000 Return-Path: Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 15 Dec 87 09:48:48-PST Date: Tue, 15 Dec 87 09:30:23 PST From: Mark Crispin Subject: Chives domain software and MX mailing To: SU-TOPS-20@Score.Stanford.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12358707951.16.CRISPIN@SUMEX-AIM.Stanford.EDU> The Chives software from MIT and the new mailsystem that supports MX mailing has been running at SUMEX for a few weeks now with no major problems. I suggest that other Stanford sites give serious consideration to migrating to it. The advantages of migration include: (1) cleaner, supported domain software; (2) less monitor code with more powerful GTDOM% functions; (3) more reliable monitor code (Chives has never caused a system crash or reload); (4) elimination of the mailsystem software skew between Stanford and my supported version of the mailsystem; (5) support for MX records in mail. I have no plans to implement any mailsystem support for the ISI domain resolver. My supported version of MM will not run with the ISI resolver, since it uses several functions of Chives that are not available with the ISI resolver. ------- 15-Dec-87 14:19:29-PST,574;000000000000 Return-Path: Received: from MACBETH.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Tue 15 Dec 87 14:19:27-PST Date: Tue 15 Dec 87 14:20:15-PST From: Rich Alderson Subject: Re: STCMP% bug To: Crispin@SUMEX-AIM.STANFORD.EDU cc: SU-TOPS-20@SCORE.STANFORD.EDU In-Reply-To: <12358706859.16.CRISPIN@SUMEX-AIM.Stanford.EDU> Message-ID: <12358760720.313.A.ALDERSON@MACBETH.STANFORD.EDU> I will take care of this on Sierra and Macbeth today. Thanks for pointing it out (again). Rich ------- 16-Dec-87 03:20:12-PST,807;000000000000 Return-Path: Received: from decwrl.dec.com by SCORE.STANFORD.EDU with TCP; Wed 16 Dec 87 03:18:56-PST Received: by decwrl.dec.com (5.54.4/4.7.34) id AA05933; Wed, 16 Dec 87 03:25:42 PST Date: Wed, 16 Dec 87 03:25:42 PST Message-Id: <8712161125.AA05933@decwrl.dec.com> From: praetorius%warlok.DEC@decwrl.dec.com To: tops-20@SCORE.STANFORD.EDU Subject: MACLisp documentation ======== Date: 16 Dec 1987 0424-MST From: PRAETORIUS@WARLOK To: "tops-20@SCORE.STANFORD.EDU"@DECWRL Subject: MACLisp documentation Message-ID: <"MS11(6006)+GLXLIB5(0)" 12358903437.103.205.4895 at WARLOK> Does anybody out there still have the MACLisp documentation online in an anonymously FTPable place? thx, RP -------- 16-Dec-87 09:49:27-PST,873;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SCORE.STANFORD.EDU with TCP; Wed 16 Dec 87 09:48:54-PST Date: Wed, 16 Dec 1987 12:50 EST Message-ID: From: Rob Austein To: praetorius%warlok.DEC@DECWRL.DEC.COM Cc: TOPS-20@SCORE.STANFORD.EDU Subject: MACLisp documentation In-reply-to: Msg of 16 Dec 1987 06:25-EST from praetorius%warlok.DEC@decwrl.dec.com Date: Wednesday, 16 December 1987 06:25-EST From: praetorius%warlok.DEC@decwrl.dec.com Does anybody out there still have the MACLisp documentation online in an anonymously FTPable place? Look in the the directories "INFO" and ".INFO." on AI.AI.MIT.EDU. Note that ITS filename syntax is "dev: dir; fn1 fn2", eg "AI:.INFO.;LISP STRUCT". Yes, the space is part of the filename. --Rob 16-Dec-87 11:36:12-PST,932;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SCORE.STANFORD.EDU with TCP; Wed 16 Dec 87 11:35:43-PST Date: Wed 16 Dec 87 13:55:45-EST From: John Wroclawski Subject: Re: MACLisp documentation To: praetorius%warlock.DEC@DECWRL.DEC.COM cc: sra@XX.LCS.MIT.EDU, TOPS-20@SCORE.STANFORD.EDU In-Reply-To: Message-ID: <12358985636.13.JTW@XX.LCS.MIT.EDU> The last version of the "old" Maclisp manual can be obtained by FTPing the file LSPMAN;LISP DOC from AI.AI.MIT.EDU. Sources for Kent Pitman's wonderful "new" Maclisp manual are in the directories LSPMAN; and LSPDOC; on AI. These are, however, heavily macroized TeX sources and somewhat hard to read online. The printed version of this manual was released as a MIT LCS Technical Report; it is remotely possible that it can still be obtained from the MIT LCS Publications Office. ------- 17-Dec-87 17:50:18-PST,693;000000000000 Return-Path: Received: from SRI-NIC.ARPA by SCORE.STANFORD.EDU with TCP; Thu 17 Dec 87 17:49:19-PST Date: Thu, 17 Dec 87 17:54:41 PST From: Mark Lottor Subject: Dec 20 brunch To: tops-20@SCORE.STANFORD.EDU Message-ID: <12359324044.21.MKL@SRI-NIC.ARPA> This Sunday, Dec 20th, is DEC 20 day! How many DEC-20 hackers in the Bay Area would be interested in getting together for a Sunday brunch? If you can make it, let me know and send along suggestions for where we could eat. If enough people respond I'll send out a confirmation notice including time and place (hopefully before Sunday morning). Check your mail often. Mark ------- 18-Dec-87 14:11:11-PST,626;000000000000 Return-Path: Received: from SRI-NIC.ARPA by SCORE.STANFORD.EDU with TCP; Fri 18 Dec 87 14:10:11-PST Date: Fri, 18 Dec 87 14:15:29 PST From: Mark Lottor Subject: dec 20 brunch To: tops-20@SCORE.STANFORD.EDU Message-ID: <12359546285.34.MKL@SRI-NIC.ARPA> OK, we'll be eating brunch at Su Hong's; 1037 El Camino Real in the middle of Menlo Park. Sunday at noon. For about $11 each we get champagne and all you can eat 19 item buffet, tip included. I think it's a sort of dim sum item combo. Please RSVP if you haven't already so I can reserve enough space. Mark ------- 21-Dec-87 11:36:03-PST,1167;000000000000 Return-Path: <@SUMEX-AIM.Stanford.EDU:MRC@PANDA.COM> Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 21 Dec 87 11:34:41-PST Received: from PANDA.COM by SUMEX-AIM.Stanford.EDU with Cafard; Sun, 20 Dec 87 10:17:14 PST Date: Sun, 20 Dec 87 09:21:09 PST From: Mark Crispin Subject: hung NOT.NOT TCB's To: TOPS-20@Score.Stanford.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12360016992.6.MRC@PANDA.COM> I've recently encountered a situation with old crufty TCB's ending up hung in NOT.NOT state. SYSDPY shows a "partial pkt rcvd". In the routine that flushes NOT.NOT TCB's, there's a bunch of checks for various things still pending (e.g. packetizer, reassembly). If you patch a skip around those checks, the hung TCB's vanish immediately with no apparent ill effect on the system. My guess is that the TCB is waiting for the other fragments of a fragmented packet. I would think that once the TCB goes NOT.NOT it should just flush any such stuff. In one system, almost all the TCB's available to the system were hung in NOT.NOT! ------- 25-Dec-87 02:19:26-PST,1236;000000000000 Return-Path: Received: from XX.LCS.MIT.EDU by SCORE.STANFORD.EDU with TCP; Fri 25 Dec 87 02:18:20-PST Date: Fri, 25 Dec 1987 05:20 EST Message-ID: From: Rob Austein To: TOPS-20@SCORE.STANFORD.EDU Reply-To: Chives-Request@XX.LCS.MIT.EDU Subject: TOPS-20 domain software in your stocking The beta-release of the CHIVES domain software is now available from the tree XX: on XX.LCS.MIT.EDU via anonymous FTP. Start by reading the -READ-.-THIS- files, it should be self-explanatory. The most recent version of the GTDOM% JSYS has not been tested in a monitor yet, due to unrelated local problems; it has, however, been tested in user context. I've also provided an older version tested for those who prefer to let someone else take the first plunge. There's a mailing list, CHIVES-BETA@XX.LCS.MIT.EDU, for use by people who are interested in using and improving this software. Reports of outright bugs should go to BUG-CHIVES@XX.LCS.MIT.EDU. Both of these lists have associated -REQUEST addresses, please do not send subscription requests directly to me. Happy hacking to all and to all a good night! --Rob