2-Jan-85 10:52:45-PST,2077;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Wed 2 Jan 85 10:52:26-PST Date: 2 Jan 1985 1347-EST From: Reed B. Powell To: KNUT_SMAALAND_UIO%QZCOM at MIT-MULTICS cc: TOPS-20 at SU-SCORE Large-Systems-Marketing: LCG Product Line Location: "231-4261 MRO2-2/3C (Pole 4A)" REPLY: "MARKET:: or MRVAX::" Subject: QUESTIONS ABOUT V6.0 uCODE, DEVICE NUMBERS, etc. Message-ID: <"MS10(2124)-1+GLXLIB1(1135)" 12076392966.27.146.80099 at DEC-MARLBORO> Here is the information on Microcode requirements for 2060/2065 under V6.0, and on changing RA81 drive numbers....... -reed q1 -- the microcode (400) will work on both 2060 and 2065. q2 -- according to the "RA81 Disk Drive User Guide" (EK-ORA81-UG-001) 2.3.3 Programming the Drive Unit Address Plug The READY cover on the operator control panel is also the drive unit address plug. The drive unit numbers between 0 and 251 must be programmed in this plug. The plug comes as "Unit 0". To set up a drive unit number other than zero, remove the READY switch from the control panel and cut off the tabs that add up to the required number. The picture shown shows 4 slotted tabs along one long edge and 4 non-sloted tabs along the other long edge. With the sloted tabs on top, they correspond (left to right) to the values 1 2 4 8 the non sloted tabs correspond (left to right with plug in same position to: 16 32 64 128 The text continues: For example, if unit number 7 is required for a specific drive, tabs 1 1,2 and 4 would have to be cut off the switch cap (plug). If unit number 113 is required, tabs 64, 32, 16, and 1 must be removed. Leave all tabs on if unit number 0 is required. After the drive unit number has been selected, place the gummed label with the corresponding number in the recessed area on the front of the switch cover. Repleace the switch cover on the operator control panel. ..enough ? -------- -------- 3-Jan-85 06:31:46-PST,2558;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Thu 3 Jan 85 06:31:29-PST Date: Thu 3 Jan 85 09:31:35-EST From: Kevin Paetzold Subject: DSK* To: tops-20@SU-SCORE.ARPA Telephone: 617-467-7430 (DTN: 231-7430) Mail-stop: MRO1-2/L10 Here is a fix for the DSK* problems that many of you are having. THis should fix all problems encountered when PS: is not named PS: and has more than 4 characters in its name. File 1) DSK:GTJFN.MAC[4,242] created: 1136 02-Jan-85 File 2) AM51:GTJFN.MAC[4,132] created: 1300 26-Oct-84 1)1 ;Fix DSK*. 1) ;Edit 3175 to GTJFN.MAC by LOMARTIRE on Fri 26-Oct-84, for SPR #20339 **** 2)1 ;Edit 3175 to GTJFN.MAC by LOMARTIRE on Fri 26-Oct-84, for SPR #20339 ************** 1)16 MOVEM T1,ENDDVS ; SAVE POSSIBLY ALTERED BLOCK POINTER 1) JRST ENDDV0 ; GO SET UP THIS STR **** 2)16 JRST ENDDV0 ; GO SET UP THIS STR ************** 1)17 STKVAR ;TEMPS FOR DSK* 1) ANDCAM B,FLAGS(TXT) ;CLEAR IT **** 2)17 ANDCAM B,FLAGS(TXT) ;CLEAR IT ************** 1)17 NOINT ;MAKE SURE ASGFRE DOES NOT GET UPSET 1) CALL GNJFN3 ;MAKE SURE WE HAVE AN UNTRIMMED BLOCK 1) RETBAD (,) ;FROM THE JSB, PASS DOWN FREE SPACE ERROR 1) OKINT 1) MOVX T2, ;GET BYTE POINTER LEFT HALF 1) HRRI T2,1(T1) ;GET THE ADDRESS OF THE BLOCK 1) MOVEM T2,DPTR ;SAVE THE TARGET POINTER 1) MOVX T2, ;GET SIXBIT BYTE POINTER 1) HRR T2,STRTAB+PSNUM ;GET ADR OF SDB FOR PS 1) MOVEM T2,LPTR ;SAVE THE SOURCE POINTER 1) MOVEI T3,6 ;SIX CHARACTERS 1) STRDE9: ;SIXBIT TO ASCII LOOP 1) ILDB T2,LPTR ;GET A BYTE 1) SKIPN T2 ;NULL? 1) JRST STRD10 ;YES 1) ADDI T2,40 ;CONVERT TO ASCII 1) IDPB T2,DPTR ;STORE THE ASCII 1) SOJG T3,STRDE9 ;LOOP FOR ALL SIX CHARS OR UNTIL NULL 1) STRD10: ;HERE WHEN ALL CHARS CONVERTED 1) SETZ T2, ;GET A NULL BYTE 1) IDPB T2,DPTR ;SAVE THE NULL BYTE 1) MOVEI T2,2(T1) ;DETERMINE A REASONABLE END OF THE BLOCK 1) HRRM T2,FILOPT(JFN) ;MAKE SURE THIS BLOCK DOES NOT GET OVERTRIMMED 1) TQO ;REMEMBER THAT THE DEVICE FIELD IS * **** 2)17 MOVE B,[ASCIZ/PS/] ;START AT STRUCTURE 0 2) MOVEM B,1(A) ;STORE NEW STRING OVER OLD ONE 2) TQO ;REMEMBER THAT THE DEVICE FIELD IS * ************** 1)24 HRLM A,FILTMP(JFN) ;IN CASE STRDVD CHANGED IT 1) CALL CHKLNM ; SEE IF THIS DEFAULT IS A LOGICAL NAME **** 2)24 CALL CHKLNM ; SEE IF THIS DEFAULT IS A LOGICAL NAME ************** ------- 3-Jan-85 11:53:47-PST,353;000000000000 Mail-From: MRC created at 3-Jan-85 11:53:43 Date: Thu 3 Jan 85 11:53:43-PST From: Mark Crispin Subject: KWP's DSK* fix To: SU-TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Is in the 5.3 monitor sources at Score. ------- 6-Jan-85 08:24:34-PST,804;000000000000 Mail-From: MRC created at 6-Jan-85 08:24:27 Date: Sun 6 Jan 85 08:24:27-PST From: Mark Crispin Subject: ten years ago today To: SU-BBoards@SU-SCORE.ARPA, TOPS-20@SU-SCORE.ARPA, BBoard@LOTS-A Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Ten years ago today, the world ended at SAIL and at TOPS-10 systems. The system date for files for these systems was a 12 bit value of the form ((((year-1964)*12)+(month-1))*31)+day-1. The world began on January 1, 1964 for a small operating system for an obscure computer, the PDP-6. On January 5, 1975 the date overflowed. This was fixed by adding 3 bits to the value in a different place in the file descriptor block. ------- 6-Jan-85 15:36:52-PST,1225;000000000000 Return-Path: Received: from SRI-AI.ARPA by SU-SCORE.ARPA with TCP; Sun 6 Jan 85 15:36:43-PST Date: Sun 6 Jan 85 15:37:12-PST From: William "Chops" Westfield Subject: SQ program for tops20 is working.... To: info-micro@BRL.ARPA, kpeterson@SIMTEL20.ARPA, wancho@SIMTEL20.ARPA cc: tops20@SU-SCORE.ARPA I have managed to get the SQ.C program to compile and work under tops20. (at least, the SQed files can be unsqueezed using GZ's USQ.MID program). For those of you unfamilliar with SQ and USQ, they are huffman data compression programs originally written for CPM, and more recently converted to MSDOS and UNIX. Byte count reductions of 30-40% are common on typical text files, and 20% or so page count reductions occur even on tops20, where you lose a byte per word going from 7bit to 8bit bytes. The files SQ.C and SQ.EXE are available for anonymous FTP from SRI-AI:. Note that SQ.C is compiled using a C compiler under development at Stanford that I dont think is available for distribution yet. Also, an object code patch is required to the .EXE file in order to prevent it from converting CRLFs to unix style newlines... Enjoy BillW ------- 6-Jan-85 15:51:48-PST,633;000000000000 Return-Path: Received: from SRI-KL.ARPA by SU-SCORE.ARPA with TCP; Sun 6 Jan 85 15:51:41-PST Date: Sun 6 Jan 85 15:52:03-PST From: William "Chops" Westfield Subject: warning on tops20 SQ program... To: wancho@SIMTEL20.ARPA, kpeterson@SIMTEL20.ARPA, tops20@SU-SCORE.ARPA, info-micro@BRL.ARPA I just SQ'ed a 500+ page mail file, and found it wouldn't unsqueze (got a premature end of file message). It would probably be a good idea to make sure anything you SQ can be USQed before the original file is deleted... (meanwhile, Ill try to track down the bug...) BillW ------- 7-Jan-85 15:11:14-PST,684;000000000000 Return-Path: Received: from EDWARDS-2060.ARPA by SU-SCORE.ARPA with TCP; Mon 7 Jan 85 15:10:52-PST Date: Mon 7 Jan 85 15:12:43-PST From: RALLIS@EDWARDS-2060.ARPA Subject: MICRO FILE TRANSFERS THRU THE TAC To: TOPS20@SU-SCORE.ARPA Is there a version of MODEM that will support file transfers to/from the TAC? I tried doing file transfers to/from the 20 from a KAYPRO using both MODEM and KERMIT... No luck. KERMIT gets further along than MODEM but the error rate is quite high. I have read the TAC-USERS.whatever file from the NIC but still have problems? Any assistance would be appreciated. Jim Rallis (805) 277-6990 ------- 7-Jan-85 16:07:12-PST,1714;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Mon 7 Jan 85 16:06:17-PST Date: 7 Jan 1985 17:07 MST (Mon) Message-ID: From: "Frank J. Wancho" To: RALLIS@EDWARDS-2060 Cc: TOPS20@SU-SCORE Subject: MICRO FILE TRANSFERS THRU THE TAC In-reply-to: Msg of 7 Jan 1985 16:12-MST from RALLIS at EDWARDS-2060.ARPA Jim, THE *latest* version of MODEM (and other related CP/M-related programs for TOPS-20) are kept in MICRO: here. Make sure you have the current version. Secondly, you *must* use the "N" secondary option to tell MODEM to negotiate binary mode with the TAC on your behalf. However, binary mode negotiations *will* fail without notice if TAC Flow Control is on in either direction. (It is *not* clear, but supposedly there is a change in the TAC code that will permit Flow Control in one direction OR the other to co-exist with binary mode, but you don't want this.) The TAC port @R command, a host or user @C, or a hangup does NOT clear any previously invoked Flow Control. Therefore, for insurance, you must type @F I E and @F O E to clear those modes before using either MODEM or KERMIT. Lastly, do not expect to upload (to your mainframe) at *any* speed above 300bps UNLESS the port you're using has been explicitly reconfigured for an input buffer size of at least 134. The default is 64 (or less in some cases) and both MODEM and KERMIT will overrun that buffer. KERMIT, however, has an option to control buffer size. Check directly with Keith Petersen (W8SDZ@SIMTEL20) for specifics on using KERMIT through a TAC. --Frank 7-Jan-85 21:03:20-PST,2025;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Mon 7 Jan 85 21:03:07-PST Date: 7 Jan 1985 22:04 MST (Mon) Message-ID: From: "Frank J. Wancho" To: INFO-MODEMXX@SIMTEL20.ARPA Cc: INFO-CPM@AMSAA, INFO-MICRO@BRL, TOPS-20@SCORE Subject: TOPS-20 SQ and TOPS-20 MODEM Bill Westfield and I were working on somewhat different versions of C sources to SQ for TOPS-20 use, using different compilers. My version, based on SQU-PORT.LBR, a "portable" version, uses the "MIT C" compiler and runtime package, and was completed shortly after Bill's announcement, with Eliot Moss' help. Although there are some significant differences in both versions - look for an announcement momentarily, both produce files with a byte size of 8. One difference is that my version produces files with the ITS Binary header. This caused a problem with MODEM only - the other CP/M-related programs for TOPS-20, such as USQ, handled this just fine. So, there is now a new version of MODEM (310) for TOPS-20 with reworked automatic file type determination code, and which now also happens to write ITS Binary files with a bytesize of 8 instead of the old 36. Source and a ready-to-run executable are in MICRO:MODEM.* here. For those of you wishing to try my version of SQ, you may FTP it from SYS: here. Sources are not quite ready for release yet. As Bill noted earlier, both versions of TOPS-20 SQ are capable of squeezing arbitrarily large TOPS-20 files (hopefully text files as both programs assume). Unfortunately, USQ/TYPESQ use file memory mapping techniques which limit the size of the files that can be handled. (At the time USQ/TYPESQ was written, it wasn't expected to handle but typically sized CP/M files.) There *may* be a version of USQ/TYPESQ available to handle such large files in the near future. In the meantime, be aware of the potential problem. --Frank 8-Jan-85 07:14:02-PST,1656;000000000000 Return-Path: Received: from columbia.arpa by SU-SCORE.ARPA with TCP; Tue 8 Jan 85 07:13:51-PST Received: from CU20B.ARPA by columbia.arpa; Tue, 8 Jan 85 10:15:35 est Date: Tue 8 Jan 85 09:48:52-EST From: Frank da Cruz Subject: [Jim Guyton : Kermit over Arpanet/Milnet TAC's] To: RALLIS@EDWARDS-2060.ARPA Cc: TOPS-20@SU-SCORE.ARPA Here are some hints about use of Kermit thru a TAC. Also note that some versions of Kermit (including DEC-20 Kermit and version 4 of CP/M-80 Kermit) have built-in commands for dealing with TACs. It should be noted that once the TAC is in binary mode, any FF (hex) bytes need to be sent twice, since they are the TAC intercept character; DEC-20 and CP/M Kermits take care of this, but I don't think any of the others do. This would only make a difference for binary files. --------------- From: Jim Guyton Date: 23 Dec 84 22:17:32 PST (Sun) To: Info-Kermit-request@columbia-20 Subject: Kermit over Arpanet/Milnet TAC's Excuse me if this is already documented, but it might be worth a note in the Kermit user's manual on how to run kermit over TAC's. What I've read / figured-out is ... 1) Use the "@B O S" and "@B I S" commands to the tac to get into binary mode, and 2) Reduce the size of the send buffer (by "set send packet-size 25" to the pc version of kermit). This combination just worked over a two-network hop (milnet-arpanet-randnet) but that a packetsize of 96 was too big for the tac took me by surprise. Anyway, just fyi ... -- Jim ------- 8-Jan-85 08:15:47-PST,1083;000000000000 Return-Path: <@SRI-CSL:GEOFFM@SRI-CSL.ARPA> Received: from SRI-CSL.ARPA by SU-SCORE.ARPA with TCP; Tue 8 Jan 85 08:15:33-PST Date: 8 Jan 1985 08:10-PST Sender: GEOFFM@SRI-CSL Subject: Re: [Jim Guyton : Kermit over Arpanet/Miln... From: Geoffrey C. Mulligan (USAFA) Reply-To: GeoffM@SRI-CSL To: sy.fdc%cu20b@COLUMBIA-20 Cc: RALLIS@EDWARDS-2060, TOPS-20@SU-SCORE Message-ID: <[SRI-CSL] 8-Jan-85 08:10:07.GEOFFM> In-Reply-To: The message of Tue 8 Jan 85 09:48:52-EST from Frank da Cruz I would not use the TAC commands @b i s and @b o s since you will not be able to issue any other tac commands after that. If you use @i ( = decimal ascii equivalent) it will change the TAC's intercept character from @ to whatever you set it to. I usually use @i 4. This will set the intercept character to control-d. Since kermit will not send any non-printing characters any control character will work. Also a packet size of 25 is much to small. I usually use a packet size of 50. geoff 8-Jan-85 13:43:41-PST,1516;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Tue 8 Jan 85 13:43:24-PST Date: 8 Jan 1985 14:29 MST (Tue) Message-ID: From: "Frank J. Wancho" To: INFO-CPM@AMSAA Cc: TOPS-20@SCORE Subject: Another TOPS-20 SQ/USQ Available Yet another version of a TOPS-20 SQ and USQ is now available, based on the "portable" C version, for ANONYMOUS FTP from MICRO: here on SIMTEL20. These programs are meant to be compiled with the "MIT C" compiler. However, ready-to-run executables are available in the same directory. Note: USQ is a special version, not to be confused with the more generic and significantly faster version of USQ by GZ@MC in MICRO:. Please rename this special version of USQ to LUSQ (for Large file USQ) if you choose to install it on our system. SQ differs from Bill Westfield's recently announced version in the handling of input and output filenames and input and output padding. This version also writes output files with the ITS Binary header, a known sore point subject to change. USQ is different from GZ's USQ in that it will handle any arbitrarily large file that SQ can produce; it assumes the original file was an ASCII text file; it is more than three times slower. It also has the TYPESQ functionality by the use of the -count option for previewing without actually unsqueezing. Bug reports to me, please. --Frank 8-Jan-85 15:06:42-PST,960;000000000000 Mail-From: MRC created at 8-Jan-85 15:06:18 Date: Tue 8 Jan 85 15:06:18-PST From: Mark Crispin Subject: WARNING re: Kermit and TAC's To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Kermit takes advantage of a BUG in TOPS-20, that is, that 0FFh (or '377 octal) in the output data stream is not doubled and hence is seen as the Internet Telnet protocol escape (IAC). This bug is FIXED at Score and at several other Internet sites, and I imagine that DEC will have it fixed in a forthcoming release. I have suggested to Kevin Paetzold that a new TTY MTOPR% be added which will put the network in binary mode (which is what Kermit wants to do). I wrote up a description of the interface, but as yet I have had no answer. Do NOT trust this misfeature in Kermit! Use @B I S !!! -- Mark -- ------- 8-Jan-85 17:13:36-PST,668;000000000000 Return-Path: Received: from UCI-750a by SU-SCORE.ARPA with TCP; Tue 8 Jan 85 17:13:22-PST Date: 08 Jan 85 17:14:15 PST (Tue) To: tops-20@su-score Subject: 2020 needed From: Mike Iglesias Received: from Localhost by UCI-750a; 08 Jan 85 17:14:27 PST (Tue) We at the University of California are looking for a 2020 to run TOPS-10 on. We need the following configuration: 512k memory, TU77 tape drive, 16-32 ports. If you know of one that is available, please let me know. Also, has anybody used ABLE or EMULEX DZ equivalents on a 2020? Thanks. Mike Iglesias University of California, Irvine iglesias@uci 9-Jan-85 02:15:26-PST,1030;000000000000 Return-Path: Received: from oslo-vax.ARPA by SU-SCORE.ARPA with TCP; Wed 9 Jan 85 02:15:14-PST Received: by oslo-vax.ARPA (4.12/4.7) id AA06156; Wed, 9 Jan 85 10:59:43 -0100 Date: Wed, 9 Jan 85 10:59:43 -0100 From: steinar@oslo-vax (Steinar Kj{rnsr|d) Message-Id: <8501090959.AA06156@oslo-vax.ARPA> To: TOPS-20@SU-SCORE.ARPA Subject: PCL not working with version 6 TOPS-20 ? At the Institute of Informatics at the University of Oslo we are currently installing the CI ( Computer Interconnect ) software to interconnect our two DEC-2065's. To run this software, V6 TOPS-20 is needed and is now installed. However, a great problem has arised: Our PCL-EXEC will not work. This is really a great problem since most of our local system software depends on PCL, i.e. building of user directories etc. ( We have approx. 1400 local users, most of them students!) Now, have anyone out there heard about a PCL-EXEC running under V6 ? Does anyone know about cites running V6 ? -- Steinar. 9-Jan-85 06:23:42-PST,939;000000000000 Return-Path: Received: from columbia.arpa by SU-SCORE.ARPA with TCP; Wed 9 Jan 85 06:23:34-PST Received: from CU20B.ARPA by columbia.arpa; Wed, 9 Jan 85 09:25:17 est Date: Wed 9 Jan 85 09:23:48-EST From: Frank da Cruz Subject: Re: WARNING re: Kermit and TAC's To: MRC@SU-SCORE.ARPA, TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Mark Crispin " of Tue 8 Jan 85 22:13:33-EST Mark's right, of course. The TAC support in DEC-20 Kermit was put there at the insistent urging of many people who wanted it that way. It is only enabled if you do a SET command to turn it on. If you don't do the SET command, then you can do "@B I S", "@B O S" yourself, which would be preferable on DEC-20 systems that DO double IAC's themselves. When DEC decides how it's going to handle binary mode on TAC's, Kermit will be changed accordingly. - Frank ------- 10-Jan-85 11:55:04-PST,943;000000000000 Return-Path: <@MIT-MULTICS.ARPA:POSTMASTER_at_QZ@QZCOM.MAILNET> Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Thu 10 Jan 85 11:54:50-PST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2651687340016202@MIT-MULTICS.ARPA>; 10 Jan 1985 14:49:00 est Date: 10 Jan 85 18:13 +0100 From: Knut_Smaaland_UiO%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Knut_Smaaland_UiO%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA, steinar_%_OSLO-VAX%QZCOM.MAILNET@MIT-MULTICS.ARPA To: TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20@SU-SCORE.ARPA, steinar_%_OSLO-VAX%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: PCL not working with version 6 TOPS-20 ? Message-ID: <85665@QZCOM> In-Reply-To: <8501090959.AA06156@oslo-vax.ARPA> The PCL Exec distributed on the 6.0 Tools tape works fine with T20/6.0 10-Jan-85 23:32:49-PST,559;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Thu 10 Jan 85 23:32:38-PST Date: 10 Jan 85 23:19:00 EST From: Charles Hedrick Subject: Unix for the 20? To: tops-20@SU-SCORE.ARPA From "perspective, Digital Equipment Corporation's Computer Newsletter", p. 9: With the introduction of PRO/VENIX, Digital becomes the first major vendor to provide UNIX-based systems for all of its processors. Anyone sufficiently tired of Tops-20 that you want to move to ULTRIX-20? ------- 11-Jan-85 09:29:50-PST,880;000000000001 Return-Path: Received: from nadc by SU-SCORE.ARPA with TCP; Fri 11 Jan 85 09:29:36-PST Date: 11 Jan 1985 12:26:16-EST From: eraps1@NADC To: tops-20@su-score Subject: DUMPER Tape Format Cc: eraps1@NADC Hi, Does anyone know the format (at a bit level) of a tape dumped useing the TOPS-20 utility DUMPER? I made some tapes useing DUMPER when I was working under a TOPS-20 system and am now unable to read them. I am now working under UNIX, and so have been able to read the records but the data is unitelligable (I believe some type of data compression algorithm was used). Given the detailed format of the tape I would be able to write a conversion routine fairly easily, but without it the task verges on impossible. Replies directly to me please, as I am not on this net. Thanks in advance, Rob Ginn (eraps1@NADC.ARPA) 11-Jan-85 19:09:31-PST,1073;000000000000 Return-Path: Received: from MIT-XX.ARPA by SU-SCORE.ARPA with TCP; Fri 11 Jan 85 19:09:03-PST Date: Fri 11 Jan 85 22:07:44-EST From: Clifford Neuman Subject: CRDIR allows negative quotas To: TOPS-20@SU-SCORE.ARPA It seems that CRDIR allows one to set their logged out (permanent) quota to a negative value, and that doing so (quite naturally) increases the quota of the superior. Here is a patch to JSYSF that will fix the problem. Actually, this fix will also cause an error when NOT updating ones logged out quota if it is currently negative. Not wanting to add a new error to CRDIR, I used CRDI14 - Request exceeds superior directory permanent quota. ------- CRD3AC: LOAD A,DRLOQ,(Q1) ;GET CURRENT LOQ UMOVE B,.CDLOQ(Q2) ;GET USERS VALUE TXNN Q3,CD%LOQ ;SETTING LOQ? MOVE B,A ;NO - NO CHANGE ;;; Begin 3053 (DON'T ALLOW NEGATIVE LOGGED OUT QUOTA) SKIPGE B RETBAD (CRDI14,) ;CAN'T SET NEGATIVE QUOTA ;;; End 3053 SUB A,B ;COMPUTE DELTA MOVEM A,CRDDOQ ;SAVE IT ------- 13-Jan-85 20:53:39-PST,947;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Sun 13 Jan 85 20:53:31-PST Date: 13 Jan 1985 21:55 MST (Sun) Message-ID: From: "Frank J. Wancho" To: INFO-CPM@AMSAA Cc: TOPS-20@SCORE Subject: TOPS-20 SQ/USQ Update SQ now accepts wild-card filenames and properly handles ITS Binary and TOPS-20 Binary input files as well as common ASCII text files. However, if a file with a bytesize of 36 is not an ITS Binary file, it blindly assumes the file is ASCII, even though the file may be something else. USQ (which should be renamed LUSQ to avoid confusion with GZ's far superior USQ) now also accepts wild-card filenames and still blindly assumes the output file is an ASCII text file. (GZ's USQ tries to guess the output file bytesize.) Sources and executables are in MICRO: on SIMTEL20. --Frank 14-Jan-85 15:23:10-PST,549;000000000000 Return-Path: Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Mon 14 Jan 85 15:22:32-PST Date: Mon 14 Jan 85 15:23:09-PST From: David Roode Subject: PRIMARY-MASTER-QUEUE-FILE.QUASAR To: tops-20@SU-SCORE.ARPA Location: EJ286 Phone: (415) 859-2774 Is there a fix for the problem of this file ballooning way out of proportion to the amount of useful data contained therein? Specifically, we see it grow to 1200 or 1500 pages where 100 pages ought to be more than enough. ------- 15-Jan-85 07:30:19-PST,1226;000000000000 Return-Path: Received: from BBNF.ARPA by SU-SCORE.ARPA with TCP; Tue 15 Jan 85 07:30:08-PST Date: 15 Jan 1985 10:29-EST Sender: RBASCH@BBNF.ARPA Subject: Re: PRIMARY-MASTER-QUEUE-FILE.QUASAR From: RBASCH@BBNF.ARPA To: ROODE@SRI-NIC.ARPA Cc: TOPS-20@SU-SCORE.ARPA Message-ID: <[BBNF.ARPA]15-Jan-85 10:29:50.RBASCH> In-Reply-To: The message of Mon 14 Jan 85 15:23:09-PST from David Roode We had the same problem, and discovered that the cause was the monitor sending messages to Quasar every time an archived file was expunged, so that notification could be sent to the directory owner. Since the queue file contains one request per page, and can grow to a maximum of only about 2500 pages, we had to kill off the queue file every time someone deleted a sizable number of archived files. Our solution was simply to stop the monitor from sending these messages to Quasar, in the belief that the notification (which doesn't work that well in any case) is less important than having a reliable spooling system. Since then, I believe that our queue files have not grown at all. If you are interested, the code to be removed is in DELFI3 (DISC.MAC). Bob Basch 15-Jan-85 15:05:06-PST,1812;000000000000 Return-Path: Received: from columbia.arpa by SU-SCORE.ARPA with TCP; Tue 15 Jan 85 15:04:22-PST Received: from CU20B.ARPA by columbia.arpa; Tue, 15 Jan 85 18:05:15 est Date: Tue 15 Jan 85 18:03:49-EST From: Thomas De Bellis Subject: Re: PRIMARY-MASTER-QUEUE-FILE.QUASAR To: RBASCH@BBNF.ARPA Cc: ROODE@SRI-NIC.ARPA, TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "RBASCH@BBNF.ARPA" of Tue 15 Jan 85 10:29:00-EST That is not the whole story. When Quasar deallocates a page in the Q file (most often when some processor does a RELEASE), it does NOT do a PMAP% to get rid of the page in the file. It marks the page as not in use and considers it for usage before allocating another page in the Q file (most often when a CREATE is requested). As you can see, this is not exactly a bug as it makes Quasar somewhat more efficient be virtue of the fact that you cut the number of PMAP%'s (and associated allocations and DSKBTTBL writes) roughly in half. This is good. Here, however, we were very tight on disk space so I wrote some code that tosses the page in the Q file. I don't toss the index pages (for you folks who know the format of the Q file). This code took me 20 minutes to write and involved a one line change to QSRFSS (the failsoft module) and the addition of one routine to QSRT20 (the Tops-20 interface) to handle the associated PMAP%'s. It doesn't seem to have slowed Quasar down at all. Our Q files are about 40 pages long on the average. If anyone is interested in this, I will dust off my sources and post the changes. They are pretty trivial if you look at QSRFSS; that's why I refrained from saying anything at first. -- Tom De Bellis CUCCA Systems Group ------- 16-Jan-85 08:31:49-PST,1688;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Wed 16 Jan 85 08:31:27-PST Date: 16 Jan 85 11:32:54 EST From: Charles Hedrick Subject: APL problem To: tops-20@SU-SCORE.ARPA We are having a problem with APLSF. The problem is so basic that I can't believe it is really present in the distributed version. The copy that we have is suspect. Somehow we don't seem to get distributions, and I am not quite sure what the history is of the copy we have. Anyway, could someone who has an up to date copy, 2(554), please see whether this bug is present in their copy: A_(.IO20)=(.IO20) A A[.IO20] For those of you who don't know APL, the first statement creates a vector of 20 1's. The second simply prints it out. You should see a lie with 20 1's on it. The third prints it out a different way. In effect it does for i := 1 to 20 do a[i] A[15] prints as a 0. You can also simply type A[15], which will also show as 0. We find that we get different results with different variable names. That is, if you use D instead of A, you may get a different failure. In case this is a "magic number" problem, it might be useful to test this for several different variable names before telling me it works. Anyway, if we can find a copy of 554 in which this is not present, we would like to FTP it from you. If it is present, then of course we will SPR it. We have looked around the network, and are surprised how many different, wildly out of date, copies of APLSF there are. Is there something wrong with APL distribution, or have people just dropped maintenance on it? ------- 16-Jan-85 22:04:05-PST,457;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Wed 16 Jan 85 22:03:48-PST Date: 17 Jan 85 01:04:14 EST From: Charles Hedrick Subject: APLSF problem solved To: tops-20@SU-SCORE.ARPA One of the folks at DEC was kind enough to give me a copy of the current field image APLSF. It does not have the bug that I reported. I guess I will never know whether the bug came from. ------- 17-Jan-85 17:54:56-PST,491;000000000000 Mail-From: BILLW created at 17-Jan-85 17:54:48 Date: Thu 17 Jan 85 17:54:48-PST From: William "Chops" Westfield Subject: SET TER PAUSE CHARACTER To: tops20@SU-SCORE.ARPA the character you specify for the pause/unpause functions seems to only have any effect when TER PAUSE END-OF-PAGE is turned on - they have no effect when TER PAUSE END is off and TER PAUS COMMAND in on. Is this a bug, or is this the way it is supposed to be? Thanks Bill W ------- 17-Jan-85 23:49:55-PST,2087;000000000000 Mail-From: ALMQUIST created at 17-Jan-85 23:49:45 Date: Thu 17 Jan 85 23:49:45-PST From: Philip Almquist Subject: Re: SET TER PAUSE CHARACTER To: BILLW@SU-SCORE.ARPA cc: tops20@SU-SCORE.ARPA In-Reply-To: Message from "William "Chops" Westfield " of Thu 17 Jan 85 17:55:05-PST Bill, As I recall, I puzzled for quite a while over the TER PAUSE CHAR stuff in the Monitor once upon a time and decided it was a "feature", or at least that's what the guy who wrote the code thought. My users (at CMU at that time) thought it damn confusing... Here is the explanation I garnered from studying the code (perhaps by now a bit confused by time; I haven't looked at that code since it got out of field test): TERMINAL PAUSE END controls what the Montitor calls page mode. In page mode, output is stopped when the page fills up and is resumed when the user types his "page unpause" character. Also in page mode, the user can type his "page pause" character to stop output immediately. Again, output is resumed only when the user types his page unpause character. This is all very obvious I'm sure. But what may not have been obvious: in the above cases, the user cannot restart output with ^Q unless ^Q is the user's "page unpause" character. That is because XON/XOFF processing, controlled by TERMINAL PAUSE COMMAND, is a very different concept. Output stops when the user types ^S, and resumes when the user types ^Q. As you might have guessed after the last paragraph, typing the "page unpause" character is not a substitute for typing ^Q. The observant reader will note from the above that there is a bug, though not quite where Bill suspected: the TERMINAL [NO] PAUSE COMMAND command has no business futzing with the page mode stuff. I forget whether that is an Exec bug or a Monitor bug. I didn't fix it at CMU because by the time I figured out all of the above my users had become so confused they had all decided not to use the new TERMINAL PAUSE CHAR command... Philip ------- 18-Jan-85 06:31:22-PST,827;000000000001 Return-Path: <@MIT-MULTICS.ARPA:POSTMASTER_at_QZ@QZCOM.MAILNET> Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Fri 18 Jan 85 06:31:13-PST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2652349502321103@MIT-MULTICS.ARPA>; 18 Jan 1985 06:45:02 est Date: 16 Jan 85 10:04 +0100 From: Klaas_Lingbeek%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Klaas_Lingbeek%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA To: TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20@SU-SCORE.ARPA, eraps1@NADC Cc: eraps1@NADC Subject: DUMPER Tape Format Message-ID: <86438@QZCOM> In-Reply-To: <85916@QZCOM> THE FORMAT IS IN DUMPER.MAC IN COMMENTS,TRY TO GE A COPY OF IT FROM ONE OF YOUR U.S. COLLEGUES 18-Jan-85 06:32:00-PST,1005;000000000000 Return-Path: Received: from LLL-MFE.ARPA by SU-SCORE.ARPA with TCP; Fri 18 Jan 85 06:31:52-PST Date: Fri, 18 Jan 85 14:33 GMT From: SAMUELSON%LLL@LLL-MFE.ARPA Subject: Re: SET TER PAUSE CHARACTER To: tops-20@SU-SCORE.ARPA From: Norm Samuelson To: tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Philip Almquist " of Fri 18 Jan 85 00:00:03-PST Telephone: (415) 422-0661, [FTS 532-0661] Office-Location: Bldg 543, room 1067 Postal-Address: LLNL, PO Box 5511, L-630, Livermore, CA 94550 There is one place where it is very important to know about that silliness with pause/unpause characters. If you happen to use DECNET, and you make a virtual terminal connection to a remote host, and the remote host is in pause on end-of-page mode, then you MUST use some pause/unpause character that will get thru DECNET. If I remember correctly, it is set to control-A by default on DECNET lines. - Sam - ------- 18-Jan-85 09:28:08-PST,602;000000000000 Mail-From: MRC created at 18-Jan-85 09:27:59 Date: Fri 18 Jan 85 09:27:59-PST From: Mark Crispin Subject: TER PAUSE To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) If you want to have pausing on a character without pausing at end of page, all you have to do is set your page length to 0 (infinity). That is pretty much all the monitor uses that value for. Some utilities such as EMACS and SYSDPY use it to, but I think they default to 24 if it is 0. ------- 18-Jan-85 14:19:38-PST,785;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Fri 18 Jan 85 14:18:55-PST Date: 18 Jan 85 17:20:01 EST From: Charles Hedrick Subject: APLSF: I spoke too soon. To: tops-20@SU-SCORE.ARPA The new version of APLSF I referred to in a previous message (edit 554) turns out to have its own problem: A _ 2 2 .RO 0 A 0 0 0 0 A[1;1] _ 1.5 domain error 2 2 .RO 0 creates an integer array, filling it with 0's. In order to execute A[1;1] _ 1.5, APL has to convert the array to a real array. Apparently that conversion fails. This is a fairly serious error. We have now backed up to our old version of APLSF, edit 435, pending a fix to this. We are issuing a priority 1 SPR. ------- 18-Jan-85 16:19:36-PST,1448;000000000000 Mail-From: MRC created at 18-Jan-85 16:18:10 Date: Fri 18 Jan 85 16:18:10-PST From: Mark Crispin Subject: MMAILR maintenance release To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) This is to announce a very important bugfix to MMAILR. All sites should update their copies of the mailsystem from MRC: in order to get this fix. There have been a number of reports of "hung MMAILRs", but until recently I haven't gotten enough information to track it down. It finally happened on Score when I was around. The problem was due to certain cases of untimed outputs to the network, in particular, when negotiating protocol. All network output is now timed; unless there is a special timer (e.g. the performance timers on message text) the default is 5 minutes. So if a TCP connection hangs but doesn't cause a JSYS error the longest that the connection can be hung for is 5 minutes. This timeout is for the completion of a BOUT%, SOUT%, or SOUTR% system call and is not an overall performance timeout the way it is when transmitting the text of the message. I hope this will remove most of the occurances of hung MMailrs. It was quite unlikely (NCP didn't have this problem) so it's only now that TCP is in reliable production that we see this sort of problem. ------- 19-Jan-85 12:41:08-PST,749;000000000000 Mail-From: MRC created at 19-Jan-85 12:41:04 Date: Sat 19 Jan 85 12:41:04-PST From: Mark Crispin Subject: NICUPD program To: SU-TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I just saw that the NICUPD program has a flag called INSTAL which will do the IPOPR% to make the monitor read in HOSTS.TXT. This is *not* a good idea, due to a monitor bug. GTHST% queries are not locked against while this is happening, so unless MMailr is stopped you are likely to have all of your queued mail become bad queued mail. I patched NICUPD at Score not to do the IPOPR% until somebody decides to fix the monitor. ------- 19-Jan-85 12:54:12-PST,1265;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Sat 19 Jan 85 12:54:09-PST Date: Sat 19 Jan 85 12:57:14-PST From: Kirk Lougheed Subject: Re: NICUPD program To: MRC@SU-SCORE.ARPA cc: SU-TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Mark Crispin " of Sat 19 Jan 85 12:46:51-PST Mark, if you run the program at 6:00AM the chances of screwing up a mail message or two are neglible. I've been running NICUPD at Sierra for over a year now without any such problems. The one time I did have a problem was when I reloaded HOSTS.TXT by hand on a heavily loaded system in the middle of the day. One message to BBNG ended up queued as "bad" mail. I have looked at the GTHST interlock bug. The whole damn JSYS needs to be rewritten. The major problem is that there is at least one MRETN for every possible function, making interlocking extremely ungraceful. If someone is interested in some monitor hacking, it would be useful to carve the existing GTHST% out of the monitor (i.e. create GTHST.MAC) and redo it in a manner permitting interlocking. The same module would eventually be replaced or rewritten to handle domain handling. Kirk ------- 19-Jan-85 14:16:50-PST,1997;000000000000 Mail-From: MRC created at 19-Jan-85 14:16:47 Date: Sat 19 Jan 85 14:16:47-PST From: Mark Crispin Subject: Re: NICUPD program To: Lougheed@SU-SIERRA.ARPA cc: SU-TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Kirk Lougheed " of Sat 19 Jan 85 12:54:15-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Kirk - The problem is that if MMailr is running through the retransmit fork NICUPD will kill most or all of the retransmit queue. I suspect that Sierra has a *much* lighter mail load than Score, although I am unable to do direct comparisions. However, Score handles 1500 or so messages daily. A lot of what ends up in the retransmit queue is BBoard, of course, but Score also has some other, important (like research related!), mailing lists which tend to get into the retransmit queue. Essentially, MMailr on Score is almost always busy, even at 6AM, and it isn't safe to run NICUPD in install mode at Score. I too looked at the GTHST% problem once upon a time and came to similar conclusions. Thank you, Mr. Borchek, for that wonderful JSYS. Dan Tappan, Paul Mockapetris, and I started on a specification for a new GTHST% which would include domain support. We came to the conclusion that several extensions are essential, such as protocol/address mapping (there are already hosts which have TELNET service on a different address from SMTP) and otherwise better support for multi-homed hosts. Some of the earlier extensions, such as your network/gateway additions, had to be done more cleanly (as in "get gateway" and "get network" functions which are different from "get host"). It was also clear that indices would have to be flushed (this would probably affect only ancient software). I got out of the loop when I left for Europe last summer. I think ISI has the ball right now. -- Mark -- ------- 19-Jan-85 15:27:16-PST,767;000000000000 Mail-From: BILLW created at 19-Jan-85 15:27:12 Date: 19 Jan 1985 15:27-PST Sender: BILLW@SU-SCORE.ARPA Subject: NICUPD and MMAILR From: William "Chops" Westfield To: su-tops-20@SU-SCORE.ARPA Message-ID: <[SU-SCORE.ARPA]19-Jan-85 15:27:11.BILLW> Since the primary conflict is between NICUPD and MMAILR, perhaps a user level fix would solve the problems. Perhaps the two programs can do ENQ/DEQ type operations. For efficiency, I suppose that the best thing to do would be to use a couple of bits in MAILR.FLAGS, since MMAILR already has this mapped. One bit for MMAILR to say that its doing a scan or looking up a host name, one bit for NICUPD to say that its updating the host tables... I realize this is a kludge. BillW 19-Jan-85 15:30:14-PST,731;000000000000 Mail-From: MRC created at 19-Jan-85 15:30:09 Date: Sat 19 Jan 85 15:30:09-PST From: Mark Crispin Subject: Re: NICUPD and MMAILR To: BillW@SU-SCORE.ARPA cc: su-tops-20@SU-SCORE.ARPA In-Reply-To: Message from "William "Chops" Westfield " of Sat 19 Jan 85 15:27:00-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Gawd, what a kludge. I'm trying to move away from the MAILER.FLAGS hack. It won't port too well to a CFS type of environment. I've been considering an IPCF protocol to pause and resume MMAILR, as part of the wakeup stuff. However, the right thing is to fix the monitor. ------- 20-Jan-85 22:48:23-PST,1215;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Sun 20 Jan 85 22:48:14-PST Date: Sun 20 Jan 85 22:51:21-PST From: Kirk Lougheed Subject: TCOPR% bugs To: tops-20@SU-SCORE.ARPA It is possible for the monitor to leave a TCP: JFN in a locked state (i.e, no longer usable) if you use either an unimplemented TCOPR% function or if you attempt to use TCOPR% on a TCP: JFN that is no longer associated with a TCB. The problem is caused by using the RETERR macro without first making sure that the JFN is indeed unlocked. The problem occurs in two places in TCPJFN.MAC. ;;; ;;; First occurence ;;; TCOPR2: ;here when we have the jfn and it is tcp SKIPN TCB,FILTCB(JFN) ;get the TCB address IFE STANSW,< RETERR(TCPX36) ;can not reopen a TCP JFN >;IFE STANSW IFN STANSW,< RETERR(TCPX36,) ;can not reopen a TCP JFN >;IFN STANSW UMOVE T1,T2 ;get the function code back ;;; ;;; Second occurence ;;; DTCSUB: ;set upper bound for retransmission IFE STANSW,< RETERR (TCPX40) ;not yet implemented >;IFE STANSW IFN STANSW,< RETBAD (TCPX40) ;not yet implemented >;IFN STANSW ------- 20-Jan-85 23:01:08-PST,1422;000000000001 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Sun 20 Jan 85 23:01:04-PST Date: Sun 20 Jan 85 23:04:06-PST From: Kirk Lougheed Subject: TCOPR% bug and MAISER To: su-tops-20@SU-SCORE.ARPA I found the TCOPR% bug mentioned in my message to the general TOPS-20 list by attempting to use MRC's latest MAISER. If you run MAISER as an inferior process of SMTPSV (the Columbia SMTP server), it trys to figure out the foreign host by executing a currently unimplemented TCOPR% function. The TCOPR% returns an error which causes alternative code to be executed to determine the foreign host. The JFN, however, ends up locked and useless. Mail service comes to a halt. To run SMTPSV with MRC's latest MAISER, you will need a patched monitor. I've fixed the 6.0 and 5.3 sources (TCPJFN.MAC) on Sierra. Release 6.0 appears to have done something bad to TVT-based MAISER service. I had terrible problems with mail delivery to Sierra until I started using the Columbia SMTPSV. The GSB apparently also had problems with MAISER when they went to 6.0; I believe they are also running SMTPSV. The program itself is a simple minded fork controller that fires up MAISER forks with primary I/O redirected to network JFNs. It would be very convenient if SMTPSV's functionality were to be subsumed by NETSRV (hint, hint). Kirk ------- 21-Jan-85 10:01:32-PST,853;000000000000 Mail-From: ALMQUIST created at 21-Jan-85 10:01:24 Date: Mon 21 Jan 85 10:01:24-PST From: Philip Almquist Subject: Re: SET TER PAUSE CHARACTER To: SAMUELSON%LLL@LLL-MFE.ARPA cc: tops-20@SU-SCORE.ARPA In-Reply-To: Message from "SAMUELSON%LLL@LLL-MFE.ARPA" of Fri 18 Jan 85 06:32:01-PST ^S/^Q go through DECnet just fine, or at least I seem to recall that I could run Emacs over DECnet without wedging myself every time I tried to do a search. It's possible that was the result of a local mod to the HOST program, but I'm not sure anymore. Glenn Marcy had to beat up the HOST program rather extensively in order to make it work "right". We got around the pause/unpause silliness in DECnet by eliminating the "feature" that sets the pause/unpause characters to ^A on DECnet terminals. Philip ------- 21-Jan-85 11:27:02-PST,1013;000000000001 Mail-From: MRC created at 21-Jan-85 11:26:58 Date: Mon 21 Jan 85 11:26:58-PST From: Mark Crispin Subject: Re: TCOPR% bug and MAISER To: Lougheed@SU-SIERRA.ARPA cc: SU-TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Kirk Lougheed " of Sun 20 Jan 85 23:01:09-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I should mention that if you don't use TVT-based MAISER you lose the functionality of being able to get the local host address used for TCP connection. This is a feature Score needs. The purpose of the TCOPR% call Kirk refers to was to get that information. So far as I can tell there is no way in the current JFN interface to get the local host address associated with a JFN. We ought to beat on KWP to do this, and/or do it ourselves. It is a simple matter to move that cell from the TCB, and that info is really needed. -- Mark -- ------- 22-Jan-85 21:07:06-PST,5118;000000000001 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Tue 22 Jan 85 21:06:37-PST Date: 23 Jan 85 00:08:21 EST From: Charles Hedrick Subject: patches for TCP performance To: tops-20@SU-SCORE.ARPA Here is a set of patches that we have installed in an attempt to improve TCP performance in Telnet. We are interested both in getting fast response time and in having the Internet fork not use much CPU time. Several of them are tradeoffs, i.e. they may have bad as well as good effects. So please think carefully before installing them. I. Output buffers The one patch that seems certainly right is in SETOBF (TTYSRV). This is setting up terminal output buffers. It checks the speed of the line and uses 1 buffer for slow speed, 2 for high speed. Unfortunately, NVT's are unknown speed. It treats them as low speed. The simplest fix would be at SETOBF+3, after the CAMN. Instead of RET, use MOVEI T3,^D9600. This would cause NVT's to be treated as high speed. IA. Variation of I. In an attempt to get large TCP packets when typing out files, I am currently using 3 buffers for NVT's. This may well be unnecessary, and could have the following bad effects: (1) increased memory usage, (2) longer for ^C and ^S to take effect. My code is the following: CAMN T3,[-1] ;KNOWN SPEED? IFNSK. ;[147] no, assume network MOVE T4,IBFRC2 ;[147] lots of buffers, to give big TCP packets ELSE. ;[147] ;[147] RET ;NO. GIVE UP THEN HRRZS T3 ;YES. GET OUTPUT SPEED MOVE T4,IBFRC ;ASSUME SLOW SPEED CAILE T3,LOWSPD ;ACCEPTABLE? MOVE T4,IBFRC1 ;NO. GET OTHER VALUE ENDIF. ;[147] IBFRC2 is set up in STG at the same point as IBFRC1. It uses 3 buffers instead of 2: File 1) GLOBS.MAC.12,22-Jan-85 02:12:35 File 2) GLOBS.MAC.10,27-Oct-84 10:30:23 1)1 QEXT ;[147] add ibfrc2 1) QEXT **** 2)1 QEXT 2) QEXT ************** File 1) STG.MAC.3,22-Jan-85 01:48:15 File 2) STG.MAC.2,13-Dec-84 13:26:47 1)2 NDG NTTBL2,3 ;[147] # of buffers for network lines 1) NDG NTTBF,ACTLNS*NTTBL1 ;NUMBER OF TTY BUFFERS **** 2)2 NDG NTTBF,ACTLNS*NTTBL1 ;NUMBER OF TTY BUFFERS ************** 1)54 ;[147] the following is a buffer description for network lines. Give them 1) ;[147] 3 buffers in order to keep TCP packet sizes up. 1) IBFRC2:: EXP <^D100>B7+B11+B15+B25+B35 1) OVRBCT==:1 ;NUMBER OF EXTRA BUFFERS FOR HIGH SPEED LINES **** 2)54 OVRBCT==:1 ;NUMBER OF EXTRA BUFFERS FOR HIGH SPEED LINES ************** II. Quick activation of the Internet fork I am concerned about response time for Telnet connections. A character echo involves three process activiations: - the Internet fork coming in - the process doing the echo - the Internet fork going out I have reason to believe that most of the delay in echoing is caused by these activations. Our response time was noticably worse than Unix and VMS. The following code speeds up activation of the Internet fork in both directions. It simply causes incoming packets and outgoing characters to kick the scheduler. This assumes that the Internet fork has enough priority that kicking the scheduler will activate it. Since we run the Internet fork in queue 0, this is true for us. This patch is one of the questionable ones. It could increase the scheduler overhead, since it causes reschedules to happen more often. We have not seen any ill effects so far, but we don't have that many TCP connections so far. If you do this patch, you should watch your system very carefully. In TTANDV.MAC, at TVTCSO, add AOS PSKED before the RETSKP. In IPNIDV.MAC, at CBDRQ1, add AOS PSKED before the PION. III. Internet fork scheduling Now for the most questionable of all. In order to get fast response, we want to run the Internet fork in high priority. We tried various things, and are now forcing it into queue 0. Of course this means that if something goes wrong, the Internet fork can take over the system. We have not seen that so far. The following change is in IPIPIP.MAC, in the main loop. ************** 1) movei t1,1 ;[143] run in queue zero 1) MOVEM T1,JOBBIT ;[142] MAKE SURE WE CAN GO FAST 1) MOVE T1,FORKX ; ID of this fork **** 2)16 MOVX T1,JP%SYS ; GET THE SYS BIT 2) MOVEM T1,JOBBIT ; MAKE SURE WE CAN GO FAST 2) MOVE T1,FORKX ; ID of this fork ************** I believe I have mentioned in individual messages that we have also changed the HDISMS 1000 at the end of the main loop to HDISMS ^D30000. The intent was to prevent the Internet fork from being taken out of the balance set. Kevin tells me that this is a horrible idea, as the 30 sec. will be charged to the fork's quantum. This will cause performance problems. If anyone has done this on the basis of my recommendations, you might want to think again. ------- 24-Jan-85 08:21:06-PST,2259;000000000000 Return-Path: <@COLUMBIA-20.ARPA:STAFF.DOBKIN@NYU20> Received: from COLUMBIA-20.ARPA by SU-SCORE.ARPA with TCP; Thu 24 Jan 85 08:20:49-PST Received: from NYU20 by CUCS20 with DECnet; 24 Jan 85 11:21:27 EST Date: Thu 24 Jan 85 11:21:04-EST From: DBD & Ittai Subject: Monitor bug fix turns up Fortran bug Sender: STAFF.DOBKIN@NYU20 To: tops20@SU-SCORE.ARPA.Internet cc: Staff.Dobkin@NYU20, staff.hershman@NYU20 Reply-To: Staff.Dobkin@NYU20 X:REPLY.DEL.1, 24-Jan-85 11:18:33, Edit by DBD Autopatch tape #7 installs the following patch to RESET% to clear arithmetic traps set by SWRTP%: EDIT 3001 FOR MONITR [SYMPTOM] Arithmetic traps set by SWTRP% are left set when RESET% JSYS called. [DIAGNOSIS] RESET% JSYS does not clear arithmetic traps. [CURE] Add code to make RESET% clear arithmetic traps along with the rest of its duties. As we just discovered, this has the unfortunate result of making SPSSX (and who knows what else) produce completely bogus output. The following patch to SPSSX.EXE will fix the problem: [PHOTO: Recording initiated Thu 24-Jan-85 10:59AM] Tops-20 PCL Command Processor 5.1(1762)-2 $filddt FILDDT>en p FILDDT>g spssx.exe [0 symbols loaded from file] [Looking at file SPSSX.EXE.1] 54231/ JSYS 147 $$< 251120/ 0 JSYS 147 !this RESET% loses arithmetic overflow traps 251121/ 0 movei 1,400000 !so set them again for this process 251122/ 0 setz 2, !function code 251123/ 0 movei 3,242253 !arg block address 251124/ 0 jsys 573 !SWRTP% to set over/underflow traps 251125/ 0 setzb 1,2 !set ACs the way they were 251126/ 0 movei 3,11 !before closing the patch 251127/ 0 $> 251127/ 0 JUMPA 1,54232 251130/ 0 JUMPA 2,54233 54231/ JSYS 147 JUMPA 251120 ^Z $pop [PHOTO: Recording terminated Thu 24-Jan-85 11:01AM] A sure way to know if you have this problem is to run the validation suite supplied with SPSSX. If test SXT3 fails, this patch is for you. Other Fortran programs may have the same problem; an SPR will go out to DEC as soon as we have more information. Daniel B. Dobkin Ittai Hershman New York University ------- 24-Jan-85 10:05:31-PST,785;000000000000 Return-Path: <@COLUMBIA-20.ARPA:STAFF.DOBKIN@NYU20> Received: from COLUMBIA-20.ARPA by SU-SCORE.ARPA with TCP; Thu 24 Jan 85 10:05:16-PST Received: from NYU20 by CUCS20 with DECnet; 24 Jan 85 13:06:58 EST Date: Thu 24 Jan 85 13:06:26-EST From: Daniel B Dobkin Subject: more on RESET%/SWTRP% fouling SPSSX results To: tops20@SU-SCORE.ARPA.Internet cc: Staff.Dobkin@NYU20, Staff.Hershman@NYU20 The patch we supplied earlier allows the validation suite to complete, but apparently does NOT fix all of the problems; there seems to be more than one of those spurious RESET%s not followed by SWTRP%. We're working with SPSS, Inc. on the problem and should have an answer by next week, but until then I'd suggest advising your users.... \dbd ------- 25-Jan-85 07:50:32-PST,755;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Fri 25 Jan 85 07:50:08-PST Date: Thursday, 24 January 1985 17:48-MST Message-ID: Sender: Steve Feldman From: Steve Feldman Subject: TOPS-20 Backup Interchange Program tape reader for UNIX wanted ReSent-From: WANCHO@SIMTEL20 ReSent-To: TOPS-20@SCORE ReSent-Date: Fri 25 Jan 1985 08:51-MST I need to be able to read tapes written on a TOPS-20 system on our 4.2BSD VAX system. Does anyone have a program to do this? Thanks, Steve Feldman hplabs!oliveb!tymix!feldman sun!idi!tymix!feldman feldman@berkeley 25-Jan-85 12:50:35-PST,597;000000000000 Return-Path: Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Fri 25 Jan 85 12:50:24-PST Received: ID ; Fri 25 Jan 85 15:52:05-EST Date: Fri 25 Jan 85 15:52:04-EST From: Vince.Fuller@CMU-CS-C.ARPA Subject: J0NRUN during system shutdown? To: TOPS-20@SU-SCORE.ARPA Has anyone else had any trouble of this nature? It appears to be happening to us with great consistancy now. The system almost all the way shutdown (past the point of sending out "System down..." to all terminals and then gets a J0NRUN. Any suggestions? --Vince ------- 25-Jan-85 23:21:29-PST,1426;000000000000 Return-Path: Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Fri 25 Jan 85 23:21:16-PST Received: ID ; Sat 26 Jan 85 02:23:06-EST Date: Sat 26 Jan 85 02:23:06-EST From: Vince.Fuller@CMU-CS-C.ARPA Subject: J0NRUN during system shutdown To: TOPS-20@SU-SCORE.ARPA Well, I figured out the problem at last... We recently started running a process which links to the console and logs all console I/O to a file for later reference. During shutdown, the job with this process is logged-out. This kills the job but leaves the links, which causes fork 0 to block when the PTY output buffer fills up. Fork 0 is thus left in TCOTST on a nonactive PTY for all eternity, resulting in a J0NRUN bughalt. This is pretty bogus, but can easily be fixed. At CHKHS4+4 make changes as follows (new lines marked "CS139"): CALL DWNMSG ;SEND LAST MESSAGE MOVE T1,CTYLNO ;CS139 Get console line number TXO T1, ;CS139 Clear links SETO T2, ;CS139 All of them, so job 0 doesn't wait on TLINK% ;CS139 any spy PTY (causes J0NRUN) ERJMP .+1 ;CS139 Shouldn't happen, SETOM HSYST1 ;CLEAR FLAGS IN CASE RESTARTED This problem was rather confusing - it didn't start happening with a new monitor installation or new hardware, just a small change in operating procedure which seemed to have little to do with the problem... --Vince ------- 28-Jan-85 15:48:54-PST,637;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Mon 28 Jan 85 15:48:39-PST Date: 28 Jan 1985 1846-EST From: Tom Blinn To: Vince.Fuller at CMU-CS-C, TOPS-20 at SU-SCORE Subject: Re: J0NRUN during system shutdown Message-ID: <"MS10(2124)-1+GLXLIB1(1135)" 12083263004.27.275.91881 at DEC-MARLBORO> Regarding: Message from Vince.Fuller@CMU-CS-C.ARPA of 26-Jan-85 0227-EST Of course, you could just run the process that does the logging under JOB 0, and then it wouldn't get logged out, so you wouldn't get the J0NRUN. Tom -------- 28-Jan-85 20:52:45-PST,425;000000000001 Return-Path: Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Mon 28 Jan 85 20:52:34-PST Date: Mon 28 Jan 85 20:54:13-PST From: Ed Pattermann Subject: Reaper To: tops-20@SU-SCORE.ARPA Has anyone modified REAPER to use WRITE dates instead of READ dates? I'd be interested in those mods, or any others people have made to REAPER. Thanks, Ed ------- 28-Jan-85 21:18:09-PST,558;000000000000 Return-Path: Received: from TL-20B.ARPA by SU-SCORE.ARPA with TCP; Mon 28 Jan 85 21:17:54-PST Received: ID ; Tue 29 Jan 85 00:18:46-EST Date: Tue, 29 Jan 1985 00:18 EST Message-ID: From: "Leonard N. Zubkoff" To: TOPS-20@SU-SCORE.ARPA Subject: X-on/X-off response Is there any way to get TOPS-20 to respond to X-off's immediately? On our system, it appears that more than 100 characters may be printed after the X-off is sent. 29-Jan-85 10:43:51-PST,2261;000000000000 Return-Path: Received: from columbia.arpa by SU-SCORE.ARPA with TCP; Tue 29 Jan 85 10:43:21-PST Received: from CU20B.ARPA by columbia.arpa; Tue, 29 Jan 85 13:45:22 est Date: Tue 29 Jan 85 13:41:34-EST From: Thomas De Bellis Subject: TM78-C To: Tops-20@SU-SCORE.ARPA Way back in June 17, 1982, Columbia placed an order for a fourth DECSYSTEM-20. Included in that order was a dual port access kit for TU78 series tape drives called a TM78-C. We paid about 5,000 dollars for the kit. As you've probably guessed by now, DEC has never installed the part! This wasn't a big deal for us because we didn't need to put the TU78's on more than one system. We put them on our production machine where all the big four pack PS's and RP07's are. These days, however, we are testing RA81's and backing them up one of them at 1600 BPI is getting to be a chore. More over, we had about 10 more of them shipped to us! There is no way we have enough tapes or tape storage facilities to back up all those RA81's. We can't get an additional set of TU78's for the RA81 based system for awhile yet and we can't put them on our production system where the TU78's are. The obvious thing to do is to finally use that TM78-C dual port kit. DEC, however, is giving us a lot of flack about this. Simply put, they don't want to install the TM78-C because they say that the software to support it doesn't work. There was also some mumbling about hardward incompatibilities and operator scheduling problems. I don't believe this and our situation on the RA81 systems is getting worse and worse. It shouldn't crash a system to take a device offline (it certainly doesn't do this when we switch a disk pack from system to system using the RP06 dual port kit.) Is anyone out there running dual-ported TU78 or TU77 tape drives? Did you have to change your software (such as MOUNTR or the MONITR)? What did it entail? Does this work? I'd really like to cut through the smokescreen on this and do something with that 5,000 dollars we spent instead of having it sit on the floor and gather dust. -- Tom De Bellis CUCCA DEC systems group ------- 29-Jan-85 12:54:08-PST,974;000000000001 Return-Path: Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Tue 29 Jan 85 12:53:53-PST Date: Tue 29 Jan 85 12:55:58-PST From: Ed Pattermann Subject: Error in REAPER message To: tops-20@SU-SCORE.ARPA My apologies - I meant has anyone modified REAPER to use READ dates instead of WRITE dates? The problem is that REAPER picks files to be migrated by WRITE dates, which means files that are read often (like LOGIN.CMD, EMACS.VARS, etc) are eligible for migration. There are pros and cons for each method, but READ seems more applicable. Maybe a fix to use both is whats needed. -- Ed --------------- From: Ed Pattermann Subject: Reaper To: tops-20@SU-SCORE.ARPA Has anyone modified REAPER to use WRITE dates instead of READ dates? I'd be interested in those mods, or any others people have made to REAPER. Thanks, Ed ------- ------- 29-Jan-85 13:26:54-PST,1384;000000000000 Return-Path: Received: from USC-ISIB.ARPA by SU-SCORE.ARPA with TCP; Tue 29 Jan 85 13:26:38-PST Date: 29 Jan 1985 13:23:13 PST Subject: Re: TM78-C From: Bob Knight To: Thomas De Bellis cc: Tops-20@SU-SCORE.ARPA In-Reply-To: (Message from "Thomas De Bellis " of Tue 29 Jan 85 13:41:34-EST) DEC is feeding you a line. First of all, the TM-78C consists of two boards (the M8956 and M8957), flat cables and two massbus connectors. The cables and connectors are not required (the cables go from massbus connectors at the front of the drive to the back). The boards you can get from DECDirect for about $1400. Install them, and you have dual-ported your TM-78. At New Mexico Tech, we're running a pair of TU78s dual ported between two 20's under 5.4. We keep the thumbwheels locked on 2 (A/B) on both drives (one is a slave) and set one unavailable on each system with OPR. Works like a charm. When we initially dual-ported our TM78, DFTUI lost with microprocessor errors. I had a sinking feeling, but we finally traced it to the backplane which DEC subsequently replaced (at no charge). Sounds like your DEC people are extremely wedged. If you need further info, I can be reached at (505) 835-5737. Bob ------- 29-Jan-85 13:46:27-PST,709;000000000000 Return-Path: Received: from TL-20B.ARPA by SU-SCORE.ARPA with TCP; Tue 29 Jan 85 13:46:12-PST Received: ID ; Tue 29 Jan 85 16:47:04-EST Date: Tue, 29 Jan 1985 16:46 EST Message-ID: From: "Leonard N. Zubkoff" To: Ed Pattermann Cc: tops-20@SU-SCORE.ARPA Subject: Error in REAPER message In-reply-to: Msg of 29 Jan 1985 15:55-EST from Ed Pattermann Wouldn't using the latest of READ and WRITE dates be most reasonable? If a file has been either read or written recently, it's probably not a good idea to migrate it. 29-Jan-85 18:48:02-PST,965;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Tue 29 Jan 85 18:47:47-PST Date: 29 Jan 85 21:49:20 EST From: Charles Hedrick Subject: TU78 dual port To: tops-20@SU-SCORE.ARPA We also use dual-ported TU78's. It is true that your operators have to know what they are doing. If they get confused, the wrong system may own the drive. DEC is probably right that ideally there should be software handshaking between the two machines so that OPR knows who owns the tape drive, if you switch the drive any tape mounted on it gets dismounted (or at least the label rechecked), etc. So it is not total malarky to talk about missing software and operational problems. However if you explain to your staff what is going on, they should be able to keep things straight without great strain. I would certainly rather use dual-porting than fill my machine room with tape drives. ------- 29-Jan-85 19:54:20-PST,727;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Tue 29 Jan 85 19:54:09-PST Date: 29 Jan 85 22:54:15 EST From: Don Subject: Re: Error in REAPER message To: Zubkoff@TL-20B.ARPA cc: PATTERMANN@SUMEX-AIM.ARPA, tops-20@SU-SCORE.ARPA In-Reply-To: Message from ""Leonard N. Zubkoff" " of 29 Jan 85 16:46:00 EST REAPER uses CREATE, READ, WRITE, and ARCHIVE dates when determining the "age" of the file. For an extensively modified version of REAPER, see the Rutgers file PS:REAPER.MAC. Efficiency is improved and several features are added. The edit history is contained in the beginning of the source. Don ------- 30-Jan-85 07:04:48-PST,571;000000000000 Return-Path: Received: from USC-ISIB.ARPA by SU-SCORE.ARPA with TCP; Wed 30 Jan 85 07:04:41-PST Date: 30 Jan 1985 07:04:20 PST Subject: Re: TU78 dual port From: Bob Knight To: Charles Hedrick cc: tops-20@SU-SCORE.ARPA In-Reply-To: (Message from "Charles Hedrick " of 29 Jan 85 21:49:20 EST) Chuck is right about the missing software aspect. However, as he says, with an aware operations staff, the problems about drive ownership are minimal. Bob ------- 30-Jan-85 10:45:16-PST,1241;000000000000 Return-Path: Received: from columbia.arpa by SU-SCORE.ARPA with TCP; Wed 30 Jan 85 10:44:45-PST Received: from CU20B.ARPA by columbia.arpa; Wed, 30 Jan 85 13:46:56 est Date: Wed 30 Jan 85 13:44:24-EST From: Ken Rossman Subject: Re: TU78 dual port To: TOPS-20@SU-SCORE.ARPA Cc: SWG.KNIGHT@USC-ISIB.ARPA, HEDRICK@RUTGERS.ARPA In-Reply-To: Message from "Bob Knight " of Wed 30 Jan 85 07:04:20-EST Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 Anyone from DEC care to comment as to whether dual ported TU78's will be supported (i.e. allocation controlled) under CFS in a similar manner that dual ported massbus disks are supposed to be (allocation negotiations occurring across the CI)? Looks like we're probably really going to need to use some dual ported TU78's, and I'm not sure I want to depend on our operations staff to make sure thumbwheels are set right, and drives are properly set unavailable. Which reminds me of something else I wanted to ask: Can the thumbwheels be left set for either one port or the other, and switched later during timesharing, with no adverse effects? /Ken ------- 30-Jan-85 11:25:33-PST,2012;000000000000 Return-Path: Received: from LLL-MFE.ARPA by SU-SCORE.ARPA with TCP; Wed 30 Jan 85 11:24:34-PST Date: Wed, 30 Jan 85 19:24 GMT From: SAMUELSON%LLL@LLL-MFE.ARPA Subject: sharing tape drives between two systems To: TOPS-20@SU-SCORE.ARPA From: Norm Samuelson To: TOPS-20@SU-SCORE.ARPA Telephone: (415) 422-0661, [FTS 532-0661] Office-Location: Bldg 543, room 1067 Postal-Address: LLNL, PO Box 5511, L-630, Livermore, CA 94550 A few years ago, while working for Ramada Inns in Phoenix, we did something similar to what folks have been asking for. We had two TOPS-10 systems, a single KL-10 and a dual KI-10. We had an interesting (neat, simple) hardware hack that let the KI address some of the KL's memory as though it were very high addresses on the KI. That allowed us to share some tables where we kept such things as the time of day, a window for fast file transfers, and allocation bits for the tape drives. All tapes were online on both systems all the time. In the code that handled assigning a drive to a user we set the bit that said "I own this drive", then checked the bit that said the other system owned it. If he owned it, we turned our bit back off and said the tape was already assigned (to job 0). That was all that was required (other than clearing the right bits when a system crashed). All that was to say that the job is not terribly difficult IF you have some high-speed path to communicate between systems that can be accessed inside the monitor. If that link is not there, or is not fast enough, or cant be accessed at a low enough level, you will have to send messages back and forth on a regular basis (at least each time a tape assignment is made). Of course it would be nice if, when mounting a labeled tape, one system at a time would allocate the drive, check the label, and if nobody is waiting for it, deallocate the drive assuming the other system might want it. - Sam - ------- 30-Jan-85 12:34:07-PST,734;000000000000 Return-Path: Received: from USC-ISIB.ARPA by SU-SCORE.ARPA with TCP; Wed 30 Jan 85 12:33:35-PST Date: 30 Jan 1985 12:30:40 PST Subject: Re: TU78 dual port From: Bob Knight To: Ken Rossman cc: TOPS-20@SU-SCORE.ARPA, SWG.KNIGHT@USC-ISIB.ARPA, HEDRICK@RUTGERS.ARPA In-Reply-To: (Message from "Ken Rossman " of Wed 30 Jan 85 13:44:24-EST) I would guess that the monitor would not have seen a drive not locked on its RH port at startup, and would not have allocated a UDB for it. So, even if you switch the drive back, it wouldn't be useable... However, I may be wrong. Any comments from DEC? Bob ------- 30-Jan-85 13:00:46-PST,1725;000000000001 Return-Path: <@MIT-MULTICS.ARPA:POSTMASTER_at_QZ@QZCOM.MAILNET> Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Wed 30 Jan 85 12:59:16-PST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2653418937939242@MIT-MULTICS.ARPA>; 30 Jan 1985 15:48:57 est Date: 30 Jan 85 16:01 +0100 From: Kimmo_Laaksonen_HUTCC%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Kimmo_Laaksonen_HUTCC%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA To: TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20@SU-SCORE.ARPA, "Ed Pattermann" Subject: Lines: 16 Reaper Message-ID: <88415@QZCOM> In-Reply-To: <88302@QZCOM> We are just working on a set of changes to speed up migration/archival. There are some changes to REAPER included, but I'll have to check with the person working on it, if the changes affect READ DATE vs. WRITE DATE (or SYSTEM WRITE DATE). The speeding up of the process should come from changes to CHKPNT to write separate files containing pending migration and archival requests. A stripped down version of DUMPER to use the files for writing the tapes already exists (all non-migrate/archival stuff is removed). The aim is not to have DUMPER scan whole disk structures - just scan the directories containing requests (that's what the files produced by CHKPNT contain). Since most sites run CHKPNT regularly each night, we don't feel there's too much delay between the rollout request and the execution. One has only to schedule the migration/archival DUMPER run after CHKPNT, first thing in the morning, or use /START or /DEPENDENCY in batch. 30-Jan-85 15:51:28-PST,800;000000000000 Mail-From: MRC created at 30-Jan-85 15:51:17 Date: Wed 30 Jan 85 15:51:17-PST From: Mark Crispin Subject: Re: TU78 dual port To: SWG.KNIGHT@USC-ISIB.ARPA cc: sy.Ken%CU20B@COLUMBIA.ARPA, TOPS-20@SU-SCORE.ARPA, HEDRICK@RUTGERS.ARPA In-Reply-To: Message from "Bob Knight " of Wed 30 Jan 85 12:30:40-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) When a device comes online there is an attention interrupt (or rather, what DEC calls "attention interrupts" -- anything that isn't a data done interrupt!!). This causes a UDB to be created. You don't need to have the device there at startup. As far as I know a UDB, once created, is never destroyed. ------- 31-Jan-85 15:54:13-PST,1640;000000000000 Return-Path: Received: from columbia.arpa by SU-SCORE.ARPA with TCP; Thu 31 Jan 85 15:53:55-PST Received: from CU20B.ARPA by columbia.arpa; Thu, 31 Jan 85 18:56:05 est Date: Thu 31 Jan 85 18:53:06-EST From: Thomas De Bellis Subject: Re: TM78-C To: Tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Kevin Paetzold " of Thu 31 Jan 85 14:02:55-EST Hi All, It seems that there may be an ambiguity in my previous message about the TM78-C dual port kit. When I said that, "It shouldn't crash a system to take a device offline", I was refering to that process of switching the TU78 tape drives from system to system and noting that properly switching dual ported RP06's has never caused us any problem. The "situation on the RA81 systems" that "is getting worse and worse" is obviously that of having to back these things up at 1600 BPI. I was not refering to switching RA81's. In fact, the RA81's, by themselves, are *real* winners. We have been field testing them for awhile now and they are one of the best, most well thought out pieces of equipment that I have ever seen. Since we are still under field test, I really can't say anything more about them or the software that we're testing so please don't pester me for gossip. I will say, however, that I don't think I have ever worked with the kind of resources that they supply. It really is a whole new aspect of computing for me. They'll be worth the wait whenever they and the software we are testing is released for general use. -- Tom ------- 1-Feb-85 23:30:32-PST,4318;000000000000 Return-Path: Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Fri 1 Feb 85 23:30:18-PST Date: Fri 1 Feb 85 23:32:18-PST From: David Roode Subject: [pep@down.fun.ARPA: RA81 unreliability] To: TOPS-20@SU-SCORE.ARPA Location: EJ286 Phone: (415) 859-2774 A potentially important point on RA81's follows. --------------- 1) 31-Jan pep@down.fun.ARPA RA81 unreliability 2) 1-Feb To: down!pep@ZAC.ARP RA81 reliability Message 1 -- ************************ Return-Path: Received: from BRL-TGR by SRI-NIC.ARPA with TCP; Thu 31 Jan 85 04:59:36-PST Received: from usenet by BRL-TGR.ARPA id a003933; 30 Jan 85 12:08 EST From: pep@down.fun.ARPA Newsgroups: net.unix-wizards Subject: RA81 unreliability Message-ID: <2200005@down.FUN> Date: 29 Jan 85 21:49:00 GMT Nf-ID: #N:down:2200005:000:2225 Nf-From: down!pep Jan 29 16:49:00 1985 Xref: seismo net.unix-wizards:11731 To: unix-wizards@BRL-TGR.ARPA I've had a LOT of trouble with RA81 discs. I run a facility with eight RA81s (along with RM80, RA80, RA60, & RL02 discs) distributed among six VAX 11/750s. Of the eight 81s, I have had to replace four HDAs in the past year, and I may have another dead one on my hands. The Symptoms: usually start out with soft errors, status/event codes of 053, 0353, and sometimes 0213 and 0350. Most of the time, these are followed by hard errors. The errors usually become more severe (more frequent; proportion of hard errors increases) if the disc is left in service. The problem has occurred under three versions of UNIX. The Cause: unknown. I observe that the errors appear on a disc that has suddenly seen a lot of write activity, after performing reliably for months (e.g., convert to a new version of UNIX and restore data). The Diagnosis: DEC diagnostics (EVRLA) sometimes detect a problem (hard error), sometimes not. The Remedy: attempt to reformat the disc. This has succeeded (and cured the problem) four times. To date, reformatting has failed four times; these HDAs have been replaced. Reformatting has failed in various ways: usual complaints are failure to format LBN area, failure to format DBN or XBN area. I have also seen a complaint that more than 12.5% of a track is bad. One Field Service Hypothesis: is that UNIX trashes DEC's area of the disc when it encounters a bad block, clobbering tables needed to reformat. Only twelve (hard) errors were reported on the latest RA81 before we attempted to reformat - reformatting still failed. What I Believe: I've heard that RA81s have been developing bad spots in the field. (This is consistent with the war stories I've been trading with friends.) UNIX doesn't forward the bad blocks, so the most attractive cure (?) is to reformat the disc. Apparently the formatter used at the factory is more powerful than the one available in the field; if DEC's area of the disc is bad, the field formatter can't recover. The HDA must be replaced; the old HDA is returned to the factory for reformatting, or marked usable for a VMS site (VMS does dynamic bad block forwarding). Pat Parseghian Princeton Univ. EECS Dept. Message 2 -- ************************ Mail-From: ROODE created at 1-Feb-85 23:22:48 Date: Fri 1 Feb 85 23:22:48-PST From: David Roode Subject: RA81 reliability To: down!pep@ZAC.ARPA, unix-wizards@BRL.ARPA, sys-staff@SRI-NIC.ARPA Location: EJ286 Phone: (415) 859-2774 I brought up the issue of RA81 reliability with the DEC disk specialist installing our new RA81 drives today. This disk specialist is known to me to be an above average DEC field service engineer. He stated that there is a known problem that results from poor attention to Preventive Maintenance. The RA81 includes a spindle ground device which tends to flake off with age and to contaminate the HDA. If the ground device is attended to regularly, much better results can be attained. I pass this along in the even it explains some sites' poor experience. He stated that the problem has been described in recent "Tech Tips" and all field engineers should be aware of it. ------- ------- 3-Feb-85 12:43:53-PST,1287;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Sun 3 Feb 85 12:43:41-PST Date: Sun 3 Feb 85 15:44:13-EST From: Kevin Paetzold Subject: 4.0 Meg of memory To: tops-20@SU-SCORE.ARPA Telephone: 617-467-7430 (DTN: 231-7430) Mail-stop: MRO1-2/L10 Allthough 4.0 meg is not supported by any monitor other than 6.1 (which is in field test) the following patch is needed by anyone attempting to run with 4.0 meg in their monitor (which i imagine some of you might be). Date: Sun 3 Feb 85 15:41:25-EST From: Kevin Paetzold Subject: ILLGOs from 4.0 meg of memory To: v6-test@COLUMBIA-20.ARPA Telephone: 617-467-7430 (DTN: 231-7430) Mail-stop: MRO1-2/L10 The following patch is required by any site running with 4.0 meg of memory. Disk IO to the last possible physical page of memory will cause an ILLGO. Guess what hardware the monitor group just got? @GET M61:AN-MONDCN.EXE.10 @DDT DDT CKERR2+11/ SUBI T3,T1 CKERR2+12/ CAME T3,T4 FFF$< FFF/ 0 ANDI 3,17777 FFF+1/ 0 $> FFF+1/ 0 CAME T3,T4 FFF+2/ 0 JUMPA T1,CKERR2+13 FFF+3/ 0 JUMPA T2,CKERR2+14 CKERR2+12/ CAME T3,T4 JUMPA FFF1 ^Z ------- ------- 3-Feb-85 18:57:02-PST,837;000000000000 Return-Path: Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Sun 3 Feb 85 18:56:51-PST Date: Sun 3 Feb 85 19:47:33-MST From: Randy Frank Subject: Re: TM78-C To: Sy.SLogin%CU20B@COLUMBIA.ARPA, Tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Thomas De Bellis " of Tue 29 Jan 85 12:52:35-MST we are running a dual ported set of TU78s (two TU78s on one TM78) with one end on a DEC-20 and the other end on a VAX 780 running 4.2BSD Unix. We have had no problems, with the obvious caveat that it is up to users and operators to manually avoid confusion. We have made no changes to software. We run the drives in the mode where they are (at any instant in time) switched to one system or the other, never in the dynamic dual port mode. ------- 3-Feb-85 19:13:05-PST,656;000000000000 Return-Path: Received: from bbn-labs-b by SU-SCORE.ARPA with TCP; Sun 3 Feb 85 19:12:50-PST Date: Sun, 3 Feb 85 22:11:30 EST From: Dave Swindell Subject: XMODEM for Tops-10 To: ProtocolS@rutgers.arpa Cc: telecom@bbncca.arpa, tops-20@su-score.arpa I am interested in locating a version of XMODEM for a DEC 10 running TOPS 10 version 7.01. Any suggestions as to commercial or public domain packages would be appreciated. As I am not on your mailing lists, please respond directly to my computer mail address. Thanks! Dave Swindell BBN Laboratories Mailbox: dswindell@bbn-unix 6-Feb-85 03:10:14-PST,745;000000000000 Return-Path: Received: from oslo-vax.ARPA by SU-SCORE.ARPA with TCP; Wed 6 Feb 85 03:09:59-PST Received: by oslo-vax.ARPA (4.12/4.7) id AA26301; Wed, 6 Feb 85 12:10:12 -0100 Date: Wed, 6 Feb 85 12:10:12 -0100 From: steinar@oslo-vax (Steinar Kj{rnsr|d) Message-Id: <8502061110.AA26301@oslo-vax.ARPA> To: TOPS-20@SU-SCORE.ARPA Subject: Source file libraries under TOPS20 The only source-file-library utility avaiable at our site is the TOPS10 LIBMAN program which have to be run by the compatability package PA1050. We would very much like to have a TOPS20 native program for creating and maintaining source libraries. Does anyone know about such a program, hopefully avaiable from DEC ? -- Steinar. 6-Feb-85 05:29:52-PST,1431;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Wed 6 Feb 85 05:29:43-PST Date: Wed 6 Feb 85 08:29:57-EST From: PURRETTA@DEC-MARLBORO.ARPA Subject: Re: Source file libraries under TOPS20 To: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "steinar@oslo-vax (Steinar Kj{rnsr|d)" of Wed 6 Feb 85 06:13:02-EST It sounds like you should look into the following two programs distributed on the TOPS-20 TOOLS tape. This is what's used in DEC by the TOPS-20 monitor group. ALU -- Automated Library Utility ALU is a program which helps keep track of modifications to a set of program sources in one or more libraries. It is intended to handle multiple developers working on the same sources, keeping track of which developer is editing which source, and preventing inadvertant confusion from simultaneous edits. REDIT -- Source update utility REDIT is used to duplicate changes which have been made in source files. It is typically used to maintain multiple sets of sources for different versions of the same program, and can conveniently allow changes made in one set to be distributed and selectively incorporated into other sets without the use of common "grandfather" files. ------- 6-Feb-85 09:51:53-PST,1092;000000000000 Return-Path: Received: from MIT-XX.ARPA by SU-SCORE.ARPA with TCP; Wed 6 Feb 85 09:51:11-PST Date: Wed 6 Feb 85 12:03:02-EST From: Rob Austein Subject: Re: Source file libraries under TOPS20 To: steinar@OSLO-VAX.ARPA cc: tops-20@SU-SCORE.ARPA In-Reply-To: Message from "steinar@oslo-vax (Steinar Kj{rnsr|d)" of Wed 6 Feb 85 06:15:29-EST Office: [NE43-502] 545 Technology Square, Cambridge MA 02139; (617) 253-7341 The ALU and REDIT programs are fairly useful. You might also look into is the SOUPR package from the autopatch tape. It consists of three programs, COMPAR, MERGE, and UPDATE, and performs aproximately the same functions as REDIT. I prefer SOUPR, because the format is easier for merging multiple edits. Also, if you have large groups of files that are logically related, there are some programs that will let you cluster them together into a single disk file to make it easier to move them around as a unit. These aren't DEC products (they're mine), but you are welcome to them if you want them. --Rob ------- 6-Feb-85 12:17:30-PST,2607;000000000000 Return-Path: <@USC-ISIB.ARPA:Chase@ISIB> Received: from USC-ISIB.ARPA by SU-SCORE.ARPA with TCP; Wed 6 Feb 85 12:17:00-PST Received: FROM ISI-ALFALFA.ARPA BY USC-ISIB.ARPA WITH TCP ; 6 Feb 85 12:11:52 PST Date: 6 Feb 85 12:13:54 Sender: Chase@ISIB From: Dale Chase To: Tops-20@SU-SCORE Cc: Chase@ISIB Subject: TCP Packetizer bug Problem: Large data transfers to some hosts don't work. For example, MMAILR can't deliver a large message. Symptom: The transfer starts out ok, then stops dead somewhere in the middle. The user process has filled its buffer(s) and is waiting for them to empty. All previously sent data has been acked and there is plenty of window space. But nothing is being sent. Diagnosis: At some point in the transfer, the packetizer (PZ) emptied the last (currently) available user buffer, which partially filled a packet. Say that the data in this packet consumes 80% of the advertised send window. In the absence of a push, the packet was held pending more user data. When the next user buffer is presented, the PZ tries to resume filling the current packet. Just before PKTIZ5 (in TCPTCP.MAC), the PZ calculates how much available window space it has. Since, after taking into account the data already in the current packet, only 20% of the window is usable, the silly-window avoidance code holds everything pending a window update or a push. Since neither of these happens, things hang until the somebody times out. Cure: The PZ should not include data in the current packet in its silly-window calculations. It does need to account for this data immediately after that calculation, to prevent overflowing the send window. So, first the indicated instructions should be removed before PKTIZ5. LOAD T1,TSLFT,(TCB) ; Send Left LOAD T2,TSSEQ,(TCB) ; Send Sequence LOAD T3,TSWND,(TCB) ; Send window offered ;;; SKIPE PKT ; REMOVE THIS ;;; LOAD T2,PESEQ,(PKT) ; REMOVE THIS ADD T1,T3 ; Compute Send Right SUB T1,T2 ; Minus Sequence ... Then, after PKTIZ7, something along these lines is needed. SKIPN PKT ; Have partially filled pkt? IFSKP. ; Yes LOAD T2,PESEQ,(PKT) ; Get end seq LOAD T1,TSSEQ,(TCB) ; and send seq SUB T2,T1 ; Difference is number bytes in pkt MODSEQ T2 ; Possible wrap SUB WNDSPC,T2 ; WNDSPC = #bytes can still put in pkt ENDIF. ; CAML BUFCNT,WNDSPC ; Take min of what is available to be SKIPA XFRCNT,WNDSPC ; sent and space allowed to send in ... This value for WNDSPC is the correct value for subsequent uses of that AC by the PZ. 6-Feb-85 16:52:14-PST,3510;000000000000 Mail-From: BILLW created at 6-Feb-85 16:52:04 Date: Wed 6 Feb 85 16:52:04-PST From: William "Chops" Westfield Subject: 6.1 field test school... To: su-tops-20@SU-SCORE.ARPA Sean Welsh and I attended a class/seminar for TOPS20 v6.1 field test sites last week. Here are some of the things I learned. Overview: The whole session was rather interesting. The people from DEC (mostly members of the monitor development team) seemed a lot more candid and informal than they tend to be at occasions like DECUS. 6.1 is the next mainline release of tops20. It supports a common file system, CI and HSC disks, NI ethernet and phase 4 decnet as major new features. In addition, many of the modifications/options that Stanford has been using for a long time are now supported by DEC (for example: encrypted passwords and the PCL multi-forking EXEC). Attendees included Utah, Columbia, Chicago, Case Western, 3M, Mobil, and perhaps others that I dont remember. Good News. Although official claim is that 6.1 supports only a 2 cpu cluster of dec20's, it will in fact support more than that. The monitor development cluster at DEC runs continuously with 3 cpus, and they occacionally add a forth (normally standalone) cpu. They haven't noticed any problems or even performance degradations with up to 4 cpus. They plan to throw a couple vaxes on a CI cluster to see if they can share an HSC, as long as individual disks are used by only one cpu type. They don't expect any serious problems with this (!!!!). Apparently the HSC command to set sector size actually effects only the MAXIMUM sector size, its a buffer size paramter. If this works, it will make a lot of customers happy. They did say that such a configuration may never be officially supported though. Some things in 6.1 are actually faster than earlier versions. For example when the directory locking mechanism was re-vamped to handle multiple cpus, the single cpu case turned out to be faster than the old method. DEC sounded pretty confident that there will be a release 7 of TOPS20. Features will probably include things like non-PS login, and better operations level support of clusters (cluster wide MOUNTR, GALAXY, etc). Code is being moved into other sections, greatly relaxing the address space restrictions that have plagued monitor developers. On the other hand, multiple section code will help the pager to thrash unless the new MCA25 pager/cache upgrade is installed. Bad News. Despite pressure from almost everyone there, DEC was doubtful that the LAT protocol (for terminal servers) will be made public anytime soon. One presenter commented that after the Jupiter cancelation, DEC put a lot of money into software development, and that this money was now starting to run out. Because of the above, the much need re-write of the TCP/IP code will not be done (at least not by DEC). Kevin said he was looking into performance, and might be able to get another 25% or so, which is a far cry from the order of magnitude improvement it needs. Randy Frank suggested that interested sites contribute a couple $K each, and hire someone to rewrite the code... Well, thats a summary. If anyone really want's to know, I can explain how shared pmaped files under CFS work, or how LAT work, or whatever. I also have a large box of documents that is on its way, and LOTS should be receivng the tapes (9) about the same time. ------- 7-Feb-85 00:01:54-PST,799;000000000000 Return-Path: Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Thu 7 Feb 85 00:01:38-PST Date: Thu 7 Feb 85 01:00:42-MST From: Jay Lepreau Subject: Re: Source file libraries under TOPS20 To: steinar@OSLO-VAX.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "steinar@oslo-vax (Steinar Kj{rnsr|d)" of Wed 6 Feb 85 04:54:23-MST Source control: I have (most of) Walter Tichy's RCS (Revision Control System) running under Tops-20. This is a system which is widely used on Unix systems, and was distributed as "user-contributed software" in 4.2 BSD. Source library: have Unix's "ar" utility, which is a rudimentary library handler. Need to talk to Walter about giving this out, but if anyone's interested, could try. ------- 8-Feb-85 13:14:19-PST,2154;000000000000 Mail-From: MRC created at 8-Feb-85 13:14:05 Return-Path: Received: from oslo-vax.ARPA by SU-SCORE.ARPA with TCP; Thu 10 Jan 85 02:36:41-PST Received: by oslo-vax.ARPA (4.12/4.7) id AA13534; Thu, 10 Jan 85 11:39:21 -0100 Date: Thu, 10 Jan 85 11:39:21 -0100 From: steinar@oslo-vax (Steinar Kj{rnsr|d) Message-Id: <8501101039.AA13534@oslo-vax.ARPA> To: %CU20B@COLUMBIA.ARPA, MRC@SU-SCORE.ARPA, POWELL@DEC-MARLBORO, steinar@OSLO-VAX.ARPA Subject: Re: PCL not working with version 6 TOPS-20 ? ReSent-Date: Fri 8 Feb 85 13:14:05-PST ReSent-From: Mark Crispin ReSent-To: TOPS-20@SU-SCORE.ARPA Thanks for quick answer. 1: Our "old" PCL was version 4.1(55) running with V5 monitor. This version wouldn't even start with V6 - issuing the message .. Illegal memory reference, section greater than 37 ?TOPS-20 command processor not properly initialised 2: However, after digging some more among the distribution tapes, we found a program named PCL-MIC-EXEC.EXE, but no documentation. The old PCL-environment file, had to be recompiled, but after that our procedures seemed to work properly. There are several differences among the two versions - the V4.1 behaving like a program in the way that @INF VERSION gave the response .. ... Program is PCL-EXEC, version 4.1(55) but the new version seems to behave much like a "fresh" EXEC after issuing @PUSH, i.e. the @INF VERSION just responds with the version number of the monitor and command processor.~? The new version apparently seems to contain much less features than the V4. However, the most interesting point is the new version's MIC feature. We would very much like to know about this - is it TOPS-10 MIC lookalike etc. ? As I mentioned, we have got no documentation. The most used programming language in our society is SIMULA, and SIMULA have interface to MIC - at least TOPS10 MIC. 3: Am I right in thinking PCL is an unsupported CMU-product ? I won't bother you more with this stuff, regards, -- Steinar. 8-Feb-85 15:23:36-PST,424;000000000000 Return-Path: Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Fri 8 Feb 85 15:23:25-PST Date: Fri 8 Feb 85 14:19:03-PST From: Frank Subject: ARCF bug To: Tops-20@SU-SCORE.ARPA There's a small bug in the .ARSST (set tape info) function of the ARCF jsys re setting the 1st tape id. In JSYSF, the CAMN T2,T3 at SET1ST+2 should be a CAMN T2,T1. ------- 9-Feb-85 18:15:57-PST,491;000000000000 Mail-From: BILLW created at 9-Feb-85 18:15:55 Date: Sat 9 Feb 85 18:15:55-PST From: William "Chops" Westfield Subject: new exec PCL bug? To: su-tops-20@SU-SCORE.ARPA The new exec seems to have broken the INVOKE command in PCL procedures. When a PCL procedure does an invoke/typein sequence, the command seems to hang. An obvious example is PCC, which is broken on both SCORE and SIERRA. Any body have any ideas? Im pretty new to PCL... BillW ------- 9-Feb-85 20:08:51-PST,730;000000000000 Mail-From: MRC created at 9-Feb-85 20:08:46 Date: Sat 9 Feb 85 20:08:46-PST From: Mark Crispin Subject: Re: new exec PCL bug? To: BILLW@SU-SCORE.ARPA cc: su-tops-20@SU-SCORE.ARPA In-Reply-To: Message from "William "Chops" Westfield " of Sat 9 Feb 85 18:15:58-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Drat! That bug (or at least a bug with the same symptoms) was in the version 5 EXEC, and I fixed it 4 years ago. Did some change not get merged from Score's EXEC sources into this new EXEC? I forget the exact details; the change looked strange (even wrong), but it wasn't. ------- 11-Feb-85 16:02:30-PST,777;000000000000 Return-Path: Received: from SRI-KL.ARPA by SU-SCORE.ARPA with TCP; Mon 11 Feb 85 16:02:11-PST Date: Mon 11 Feb 85 15:54:11-PST From: LARSON@SRI-KL.ARPA Subject: ethernet interfaces To: tops-20@SU-SCORE.ARPA Is there anyone who is running an Ethernet through a front end, or some method not involving a Stanford MEIS or DEC NI20 interface? We have the NI20 coming, but I wondered if there was some way I could use the DN20 that came with the machine in the meantime. (I have an Interlan board that I can put in the DN20 to hook it to the Ethernet.) I would like something easy to set up if possible, and would even be happy with a set of patches that made the net run through one of the terminal lines. Thanks Alan Larson ------- 11-Feb-85 17:38:01-PST,819;000000000000 Return-Path: Received: from TL-20B.ARPA by SU-SCORE.ARPA with TCP; Mon 11 Feb 85 17:37:43-PST Received: ID ; Mon 11 Feb 85 20:34:39-EST Date: Mon, 11 Feb 1985 20:34 EST Message-ID: From: "Leonard N. Zubkoff" To: LARSON@SRI-KL.ARPA Cc: tops-20@SU-SCORE.ARPA Subject: ethernet interfaces In-reply-to: Msg of 11 Feb 1985 18:54-EST from LARSON at SRI-KL.ARPA CMU and Tartan Laboratories both use DN-20's running CMU's IP Router code to interface DEC-20's to the InterNet/EtherNet. I don't know if the IP Router code supports Interlan boards; we're using 3COM at Tartan. Contact Vince Fuller (VAF@CMU-CS-C) or Mike Accetta (Mike.Accetta@CMU-CS-IUS) for more information. Leonard 11-Feb-85 21:39:32-PST,787;000000000000 Return-Path: <@SRI-CSL:GEOFF@SRI-CSL.ARPA> Received: from SRI-CSL.ARPA by SU-SCORE.ARPA with TCP; Mon 11 Feb 85 21:39:19-PST Date: 11 Feb 1985 21:38-PST Sender: GEOFF@SRI-CSL Subject: TCP/IP Printer Interface/Spooler? From: the tty of Geoffrey S. Goodfellow To: Tops-20@SCORE Message-ID: <[SRI-CSL]11-Feb-85 21:38:30.GEOFF> Does anyone have printer spoolers for TOPS-20 which: -allow cross spooling of files with TCP/IP between TOPS-20 and/or other types of dissimilar Systems? (i.e., queue a file for printing on System A, which is then transferred to System B where it is queued and printed). -drives a TCP/IP based Imagen over an Ethernet? (i.e., queue a file on a TOPS-20 System which then is TCP/IP'd to the Imagen for printing). g 12-Feb-85 11:14:17-PST,598;000000000000 Mail-From: MRC created at 12-Feb-85 11:13:39 Date: Tue 12 Feb 85 11:13:39-PST From: Mark Crispin Subject: Foonly F3 computer To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) What can people tell me about the Foonly F3 computer? What is its footprint? Power requirements? Cooling requirements? What is its computational power? Can/Has it been microcoded so it can run TOPS-20? I would especially like to hear how it compares to the 2020. ------- 12-Feb-85 12:12:01-PST,1011;000000000000 Return-Path: Received: from MIT-XX.ARPA by SU-SCORE.ARPA with TCP; Tue 12 Feb 85 12:11:24-PST Date: Tue 12 Feb 85 12:20:47-EST From: Rob Austein Subject: Re: TCP/IP Printer Interface/Spooler? To: Geoff@SRI-CSL.ARPA cc: Tops-20@SU-SCORE.ARPA In-Reply-To: Message from "the tty of Geoffrey S. Goodfellow " of Tue 12 Feb 85 00:38:00-EST Office: [NE43-502] 545 Technology Square, Cambridge MA 02139; (617) 253-7341 I've got a crock that spools files to a Berkelely 4.2 lpd for eventual shipment to an Imagen (lpd knows how to do this). My program isn't integrated into GALAXY (yet) or have the ability to queue directly to the Imagen if the lpd is idle (ditto, although this may never get added). You're welcome to it if you like, with the above caveats. You might also check with John Romkey , who has written a program for directly spooling to the Imagen (in C, I believe) for use on a PC with TCP support. ------- 12-Feb-85 12:32:47-PST,668;000000000000 Return-Path: Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Tue 12 Feb 85 12:32:34-PST Date: Tue 12 Feb 85 13:31:26-MST From: The alleged mind of Walt Subject: Re: TCP/IP Printer Interface/Spooler? To: Geoff@SRI-CSL.ARPA cc: TOPS-20@SU-SCORE.ARPA I have a Un*x-style line printer daemon which runs on the 20 and allows the Un*x systems on our Ethernet to spool files to be printed on the 20's printers. I also have a program that runs on the 20 and allows files to be submitted for printing on one Un*x system. Either are yours for the asking, but I can't offer support. Cheers -- Walt Haas ------- 12-Feb-85 15:42:04-PST,1164;000000000000 Return-Path: Received: from CMU-CC-TE by SU-SCORE.ARPA with TCP; Tue 12 Feb 85 15:41:12-PST Date: Tue 12 Feb 85 18:38:44-EST From: Eric Crane Subject: Re: Dn20's and IP support To: tops-20@SU-SCORE.ARPA Office: Ucc 130 x3568 Secretary: x2638 To add a little to Leonard Zubkoff's info, the CMU-Router supports the following: Interland 10Mb ethernet 3Com 10Mb ethernet Proteon 10Mb proNET Xerox 3Mb experimental ethernet Dte-20 interface (how we talk to 20's) DA28-F interface DZ11 DUP-11 (better than DZs) Unibus IMP interface (whatever it is called) DMR-11 (not done yet) The code is fairly general, we have it running as Network Front Ends on 6 20's (soon to be 9) 2 at Tartan, 4 here. 1 gateway (CMU-GATEWAY) and between different network cables in a few other places. We seem to have a maximum throughput of about 60-70Kbytes for a single FTP connection to another 20. With multiple connections at once we seem to drop down to about 59Kbytes/connection. These were done on standalone 20's under Tops-20 V5.3. - Eric Crane Carnegie-Mellon Univ ------- 12-Feb-85 17:16:08-PST,677;000000000000 Mail-From: MRC created at 12-Feb-85 17:16:02 Date: Tue 12 Feb 85 17:16:02-PST From: Mark Crispin Subject: V6 EXEC To: SU-TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) The new wonderful V6 EXEC still has the bug that breaks the MM build procedures in it. I've patched Score's copy to have the published workaround, which is to patch CMIND+16 from JRST CMPER to NOP. I would appreciate it if this patch (or the right fix) would propogate to the other instances of this EXEC around Stanford. Your friendly MM developer ------- 13-Feb-85 15:38:56-PST,1303;000000000000 Mail-From: MRC created at 13-Feb-85 15:38:48 Date: Wed 13 Feb 85 15:38:48-PST From: Mark Crispin Subject: FREE SHOWING: 36-bit historical videotapes To: Bayboards@SU-AIMVAX.ARPA, BBoard@LOTS-A cc: Geoff@SRI-CSL.ARPA, Reges@SU-SCORE.ARPA, SU-TOPS-20@SU-SCORE.ARPA, G.Gorin@LOTS-A Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I have received from DEC a set of videotapes from the December '84 DECUS (DEC User's Society) symposium recording some of the sessions pertaining to the history of DEC's 36-bit computers, the DECsystem-10 and the DECSYSTEM-20. I have received permission to hold a public showing of these tapes at Stanford. Programming on these tapes include the 36-BIT TRIVIA BOWL, the 36-BIT PIONEER'S ROUNDTABLE (find out about the DEC-10 that took a steambath!), and a special bonus, some comic commercials for things such as DIGIBITS, DEC-WASH,... In order to determine what would be the most suitable facility, I need to know how many people are interested in being there. If you're thinking of coming, please send mail to MRC@SU-SCORE.ARPA. Once we have some idea of the attendance, we'll reserve some place to hold the showing. ------- 13-Feb-85 17:34:59-PST,816;000000000000 Return-Path: Received: from USC-ISIB.ARPA by SU-SCORE.ARPA with TCP; Wed 13 Feb 85 17:34:45-PST Date: 13 Feb 1985 17:32-PST Sender: JGOLDBERGER@USC-ISIB.ARPA Subject: Re: TCP/IP Printer Interface/Spooler? From: Joel Goldberger To: Geoff@SRI-CSL.ARPA Cc: Tops-20@SU-SCORE.ARPA Message-ID: <[USC-ISIB.ARPA]13-Feb-85 17:32:12.JGOLDBERGER> In-Reply-To: <[SRI-CSL]11-Feb-85 21:38:30.GEOFF> ISI has been running with network spooling for quite a while, first NCP and then TCP. Dennis Smith is the author of this code and it is fully integrated into GALAXY. We have added facilities to accept files from both VMS (using TWG's TCP) and UNIX (via TFTP). With Dennis's permission I could make the TOPS-20 components available. - Joel Goldberger - 13-Feb-85 18:22:08-PST,1948;000000000000 Return-Path: <@MIT-MULTICS.ARPA:POSTMASTER_at_QZ@QZCOM.MAILNET> Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Wed 13 Feb 85 18:21:53-PST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2654639143134409@MIT-MULTICS.ARPA>; 13 Feb 1985 18:45:43 est Date: 06 Feb 85 02:42 +0100 From: Michel_E_Debar_DECUS%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Michel_E_Debar_DECUS%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA, IPL_Software_Enquiries%QZCOM.MAILNET@MIT-MULTICS.ARPA, Sven_Olofsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Jurek_Wolodarski_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA To: TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20@SU-SCORE.ARPA, "Charles Hedrick" Cc: IPL_Software_Enquiries%QZCOM.MAILNET@MIT-MULTICS.ARPA, Sven_Olofsson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA, Jurek_Wolodarski_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: Lines: 14 is anyone using Macsyma on the 20? Message-ID: <89472@QZCOM> In-Reply-To: <71559@QZCOM> I installed Macsyma on our 20 about a year ago. I do remember having hit the sam e problems on installation, or similar. Basically Macsyma is working but: - line editing is cumbersome, or I lose the automatic evaluation on expression termination, - I wanted to use the disk copy of graphics. Unfortunately the format is totally undocumented (apart from a reference to an info: file which is not distributed). A call to Symbolics elicited the "unsupported" answer. I think that we had a couple of other minor problems. Basically the thing is working, some bells and whistles that I thought easy to port to the 20 are not working, and the support is non positive. Only answer from Symbolics is buy maintenance, or get a new tape ($ 1000). Michel 13-Feb-85 18:39:29-PST,1114;000000000000 Return-Path: <@MIT-MULTICS.ARPA:POSTMASTER_at_QZ@QZCOM.MAILNET> Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Wed 13 Feb 85 18:39:16-PST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2654641126490991@MIT-MULTICS.ARPA>; 13 Feb 1985 19:18:46 est Date: 30 Jan 85 02:36 +0100 From: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA To: TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA Cc: TOPS-10/20_SIG%QZCOM.MAILNET@MIT-MULTICS.ARPA Resent-Cc: TOPS-20@SU-SCORE.ARPA Subject: Lines: 22 Looking for harware.. Message-ID: <88329@QZCOM> I'm out to find the following flip-chips 2 pcs M171 4 pcs M126 1 pcs M241 1 pcs M321 2 pcs M177 5 pcs M143 1 pcs M172 4 pcs M629 3 pcs M511 1 pcs M243 1 pcs M175 1 pcs M246 1 pcs M170 1 pcs M921 1 pcs W970 1 pcs W990 anybody out there having some ? 14-Feb-85 01:55:06-PST,3000;000000000000 Mail-From: BILLW created at 14-Feb-85 01:55:03 Date: 14 Feb 1985 01:55-PST Sender: BILLW@SU-SCORE.ARPA Subject: new EMACS for testing. From: William "Chops" Westfield To: ROODE@SRI-NIC.ARPA Cc: su-tops-20@SU-SCORE.ARPA Message-ID: <[SU-SCORE.ARPA]14-Feb-85 01:55:03.BILLW> In-Reply-To: The message of Thu 14 Feb 85 01:20:38-PST from David Roode huh? You passing around rumors? there qwasnt much to that message you forwarded to me. Anyway, I am working on EMACS right this minute. here is whats in store: The TEXTI mods. Rewrite ALL of the terminal drivers to buffer their output until the final return, at which point do the -N form of SOUT (instead of psout), which I have already optimized in th monitor. Thats been done. This is whats still in progress: use CRLF, CR, LF for cursor positoining where possible. use INSERT MODE terminal MUCH better. Only go in and out of insert mode when absolutely necessary. And I'm sort of considering (in order of practicallity): define an IDEAL terminal type. This would be able to do all of the emacs functions in a maximum of two bytes. (on a 25x 80 display. Bigger terminals are not "ideal"). make the IDEAL terminal type do the equivilent of TEXTI locally. This would enable EMACS to use SINs for TTY input most of the time. (even better than TEXTI) The above are applicable because many of the "terminals" being connected to things these days are actually microcomputers, running terminal emulators. Many of the terminal emulators can be modified. Perhaps the ethertip can emulate the IDEAL terminal and translate as appropriate for individual terminals. SUNs can clearly do this. Do TEXTI locally in ethertip/sun via an extension to TELNET protocol (is there already a set break mask option? I wish all of the TELNET options would be collected into one RFC!) 6.1 (decnet phase 4) has a facility for doing TEXTI remotely, but I suspect that getting it to work over TCP/PUP.etc would be pretty hairy. Most of these changes are at the system level - ie they will not result in a highly visible improvement (like much faster screen updating) to users, but should lessen the impact of emacs on the system. (they also assume the TTY IO is one of the most expensive thing that emacs does, which isn't always or necessarilly true. For exmaple, Kirk has suggested that one of the UNIX emacs's like ELLE be brought up under the assumption that it is more efficient by not having (interpreted) TECO as an intermediate level). If anyone has any other suggestions, id be happy to take them into consideration. The current version of EMACS is in SCORE:XEMACS.EXE I don't think its quite up to date in terms of terminal types, but im working on it... Run it by using: DEFINE EMACS: PS: DEFINE EDITOR: EMACS:XEMACS.EXE Let me know of any problems Enjoy BillW 14-Feb-85 11:57:20-PST,842;000000000000 Return-Path: Received: from Xerox.ARPA by SU-SCORE.ARPA with TCP; Thu 14 Feb 85 11:56:50-PST Received: from Riesling.ms by ArpaGateway.ms ; 14 FEB 85 11:51:35 PST Sender: "Randy Gobbel.osbunorth"@XEROX.ARPA Date: 14 Feb 85 11:47:15 PST (Thursday) Subject: Re: FREE SHOWING: 36-bit historical videotapes From: Gobbel.osbunorth@XEROX.ARPA To: MRC@SU-SCORE.ARPA cc: Bayboards@SU-AIMVAX.ARPA, BBoard%LOTS-A@SU-SCORE.ARPA, Geoff@SRI-CSL.ARPA, Reges@SU-SCORE.ARPA, SU-TOPS-20@SU-SCORE.ARPA, G.Gorin%LOTS-A@SU-SCORE.ARPA In-Reply-to: -SCORE:ARPA's message of 13 Feb 85 22:14:10 PST (Wednesday) Reply-to: Gobbel.osbunorth@XEROX.ARPA Please add me to the list of possible attendees. I know one or two people who probably didn't get your message who'd also likely be interested. -Randy 15-Feb-85 11:26:23-PST,4492;000000000001 Mail-From: MRC created at 15-Feb-85 11:26:14 Date: Fri 15 Feb 85 11:26:13-PST From: Mark Crispin Subject: MM support status To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I would like to clarify some questions which have been raised with regard to MM support since I left Stanford. There have been a number of rumors floating around. Many of them seem to be coming from DEC, which apparently is trying to get people to migrate to MS again. FACT: I am still developing and maintaining MM. This can be easily ascertained just by following the edits which have been made to the master MM directory on Score. FACT: MM is still a free software product. MYTH: I am charging for all work done on MM. FACT: I AM accepting voluntary donations. I am also accepting funding for development of major new functionalities in MM. I will always listen to requests for new features. If it's something that can be put in simply I probably will. If it's something that will take several days of my time I will listen a LOT harder if I'm offered funding to do it. At the present time my existing funding for MM work is only about $400/month, yet in reality I am spending 5-10 man-days/month on MM. MYTH: MM won't run on TOPS-20 release 6 and I'm refusing to fix it. FACT: There are a set of known issues with MM and TOPS-20 release 6. I haven't done much about them except collect information since I do not have a release 6 system to debug on. I REFUSE to put in new code which would be triggered by a TOPS-20 release unless that code can be tested. I consider potential "timebombs" unacceptable in a product as important as MM. The current release 6 issues are: . MM does not support the release 6 POBOX: functionality which allows for non-PS: mailbox structures. This is a simple enhancement, deferred only until its support can be tested. I have a description of how POBOX: works, but I do not trust DEC not to have a few surprises in store for an implementor trying to support it. . Apparently, terminal input performance on TVT's has been broken by release 6 to the point that incoming SMTP service barely works (if that). Kirk Lougheed has been distributing an alternative SMTPSV which uses redirected TCP: JFN's instead of a TVT to get around this problem. My distributed MAISER now supports this method, as it was originally designed to. The main problem with a full migration to this scheme is that there is no way with a TCP: JFN to get the local host address of the JFN. This is necessary to support the "local port" feature of ARPANET that many sites take advantage of. There is a defined TCOPR% to supply this information, but it is not implemented and DEC refuses to make any commitment to implement it. . Due to an enlarged MONSYM and "improvements" made to MACRO, MM no longer assembles in a release 6 environment. It gets an ?MCRNEC (not enough core) error, because MACRO's data area is limited to 256 pages. DEC refuses to fix MACRO to allow a larger data area. I have been working on the rather ardous task of splitting MM into multiple source files; recently I excised the help texts and pointers out and I am awaiting word on whether that gained enough space. I am not getting any funding for this effort, so this project is proceeding slowly. . MM doesn't run in extended addressing. Yes, I know there are people out there who would like 300+ page mail files and don't care how long it takes. I agree this would be a nice extension, but it is a lot of work. If I spend a month doing this that's a month that the rent, electric, phone, credit card, etc. bills don't get paid. It will undoubtably happen eventually, but I don't consider this to be a major issue. Fewer than 1% of all MM users want 300+ page mail files. I am hoping to have satisfactory solutions to most of these problems by the time release 6 is actually distributed. It would be nice if DEC were to: (1) add the TCOPR% function to get the local host and stop dallying on this, (2) fix MACRO to have a larger symbol and macro area, (3) fix TVT performance (this could be done instead of (1), but both should be done). -- Mark -- ------- 15-Feb-85 17:25:51-PST,1396;000000000000 Mail-From: MRC created at 15-Feb-85 17:25:34 Date: Fri 15 Feb 85 17:25:34-PST From: Mark Crispin Subject: 36-Bit Historical Videotape showing: place, date, time To: "36-Bit Show Goers": ; Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) FREE SHOWING OF THE 36-BIT HISTORICAL SESSIONS FROM DECEMBER '84 DECUS Skilling Auditorium, Stanford University Thursday, 21 February 1985 6:30PM - 9:30PM Schedule (all times approximate): 6:30 36-BIT TRIVIA BOWL - see the DEC customer team (the BIT BUSTERS) decisively win over the DEC team (the STACKED DEC) in their knowledge of 10/20 trivia. Find out how it was possible, by software, to power off a Ki-10! 7:30 36-BIT PIONEER'S ROUNDTABLE - several noted figures from the early days of DEC 10's and 20's discuss what it was like "back then." Members of the panel include PDP-6/10 designers Alan Kotok and Gordon Bell, Tenex inventor Dan Murphy, and Stanford's own Ralph Gorin. Hear about the DEC-10 that took a steambath!! 9:00 DEC COMMERCIALS -- new DIGIBITS, the cereal of all ones and zeros; new DEC-WASH, the disk detergent that cleans all those lost blocks, etc... Thanks to: Digital Equipment Corporation, Stanford CSD Computer Facilities, and Panda Programming. ------- 16-Feb-85 18:20:05-PST,753;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Sat 16 Feb 85 18:19:55-PST Date: 16 Feb 85 21:18:13 EST From: Charles Hedrick Subject: more help needed from a midas wizard To: tops-20@SU-SCORE.ARPA Could someone tell me why the following code generates an error complaining that there are more constants in pass 2 than pass 1? I assume this is a bug in Midas. title test loc 140 define object(type,val) <.byte 6,30. ? type ? val> termin move 1,[object 3,<4,,a>] move 1,[object 3,<4,,b>] a: 1 b: 2 end If you replace the macro calls to OBJECT with their definition, the error does not occur. Putting () around the call does not help. ------- 17-Feb-85 03:23:28-PST,916;000000000000 Mail-From: BILLW created at 17-Feb-85 03:23:26 Date: 17 Feb 1985 03:23-PST Sender: BILLW@SU-SCORE.ARPA Subject: minor bug fix in TTYSRV... From: William "Chops" Westfield To: su-tops-20@SU-SCORE.ARPA Cc: fshu@WASHINGTON.ARPA, Gingell%CWR20B@CSNET-RELAY.ARPA Message-ID: <[SU-SCORE.ARPA]17-Feb-85 03:23:25.BILLW> Problem: backspace is converted to rubout when this is enabled, even in "emacs mode". This causes annoying beahvior in the new emacs - backspace would delete the last character if you were at the end of the line (and doing a TEXTI), but only backspace if you were in the middle of the line (and EMACS interpreted the char). Solution: always leave backspaces alone if TT%WK0 (the emacs mode bit) is on. At TTRAIS (in TTYSRV) plus a couple (just before the TXNE T1,MO%BSP), insert a TXNN T3,TT%WK0 The source on SCORE and SIERRA have both been updated. 17-Feb-85 12:08:15-PST,712;000000000000 Mail-From: MRC created at 17-Feb-85 12:08:07 Date: Sun 17 Feb 85 12:08:07-PST From: Mark Crispin Subject: Re: minor bug fix in TTYSRV... To: BillW@SU-SCORE.ARPA cc: su-tops-20@SU-SCORE.ARPA, fshu@WASHINGTON.ARPA, Gingell%CWR20B@CSNET-RELAY.ARPA In-Reply-To: Message from "William "Chops" Westfield " of Sun 17 Feb 85 03:23:00-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) But, but, but... What if you have EMACS set up so backspace is equivalent to rubout? Do I lose this then? What about texti's for filenames, etc., or isn't this affected? -- Mark -- ------- 17-Feb-85 15:36:33-PST,1050;000000000000 Mail-From: BILLW created at 17-Feb-85 15:36:30 Date: 17 Feb 1985 15:36-PST Sender: BILLW@SU-SCORE.ARPA Subject: Re: minor bug fix in TTYSRV... From: William "Chops" Westfield To: MRC@SU-SCORE.ARPA Cc: su-tops-20@SU-SCORE.ARPA, fshu@WASHINGTON.ARPA Cc: Gingell%CWR20B@CSNET-RELAY.ARPA Message-ID: <[SU-SCORE.ARPA]17-Feb-85 15:36:29.BILLW> In-Reply-To: The message of Sun 17 Feb 85 12:08:07-PST from Mark Crispin TEXTI is only invoke with the EMACS bit turned on under special circumstances. Otherwise, the bit stays off, so that reading filenames and such will behave "properly" (it isnt really a problem there - typing a ^H used to get you a "not confirmed" error or some such). Note that TEXTI does not process the rubout or backsapce by itself. Instead it is recognized as a break character and passed to emacs for processing. Thus rubout or backspace can be bound to any function, and that function will be executed whether the characer was read by TEXTI or by PBIN... BillW 18-Feb-85 18:45:36-PST,646;000000000000 Return-Path: Received: from SRI-KL.ARPA by SU-SCORE.ARPA with TCP; Mon 18 Feb 85 18:45:27-PST Date: Mon 18 Feb 85 17:57:00-PST From: Ken Olum Subject: Note for MINITS sites To: tops-20%SU-SCORE@SRI-KL If you are running MINITS as a network front-end operating system, I've just found a bug that causes communications not to resume when the 20 is rebooted. There needs to be a CLR $DTXBF(R5) somewhere in DT$INI to make sure MINITS doesn't think a leftover packet is still in progress to the 20. Mail to me if you want more details on this so we don't bother too many folks. Ken ------- 18-Feb-85 22:00:28-PST,1130;000000000000 Mail-From: MRC created at 18-Feb-85 22:00:18 Date: Mon 18 Feb 85 22:00:18-PST From: Mark Crispin Subject: [John Wroclawski : Macro data space] To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I just received this note. This may help release 6 sites which have been unable to recompile MM due to ?MCRNEC errors. I don't think there is anything MM can do after the fact to purge .ERCOD, but if somebody knows of a trick which will induce MACRO to recover this space I'll put it in MM. --------------- Return-Path: <@MIT-MC:JTW@MIT-SPEECH> Received: from MIT-MC by SU-SCORE.ARPA with TCP; Mon 18 Feb 85 13:26:40-PST Date: Mon 18 Feb 85 16:27:43-EST From: John Wroclawski Subject: Macro data space To: mrc@score.arpa You can make MONSYM.UNV some 26 pages smaller by adding .ERCOD to the list of things purged at the very end of MONSYM.MAC. Just saved me, maybe it will help you too. ------- ------- 18-Feb-85 23:59:10-PST,713;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Mon 18 Feb 85 23:59:02-PST Date: Mon 18 Feb 85 23:58:00-PST From: Kirk Lougheed Subject: MM and Release 6 To: mrc@SU-SCORE.ARPA, jtw%mit-speech@MIT-MC.ARPA cc: tops-20@SU-SCORE.ARPA Using LINK 5.1(2041), MACRO 53.1(1152), TOPS-20 6.0(6370)-4, and a 6.0 MONSYM modified to purge the .ERCOD macro, I was able to assemble the most recent MM sources. Note that there is at least one program, SYSDPY, that makes use of the .ERCOD macro. Since MM is distributed with its own copy of MONSYM, I think the most expedient thing to do would be to modify that MONSYM. Kirk ------- 19-Feb-85 06:16:53-PST,740;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Tue 19 Feb 85 06:16:44-PST Date: Tue 19 Feb 85 09:13:07-EST From: Kevin Paetzold Subject: Re: MM and Release 6 To: Lougheed@SU-SIERRA.ARPA cc: mrc@SU-SCORE.ARPA, jtw%mit-speech@MIT-MC.ARPA, tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Kirk Lougheed " of Tue 19 Feb 85 02:59:01-EST Telephone: 617-467-7430 (DTN: 231-7430) Mail-stop: MRO1-2/L10 macro 53b is in use here even though it has not hit the field yet. among other things it has polish blocks which are one word larger than they used to be. this puts mm way over the edge for free space in macro. ------- 19-Feb-85 18:10:10-PST,673;000000000000 Return-Path: Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Tue 19 Feb 85 18:09:55-PST Date: Tue 19 Feb 85 18:08:05-PST From: Ken Harrenstien Subject: Re: more help needed from a midas wizard To: HEDRICK@RUTGERS.ARPA, tops-20@SU-SCORE.ARPA cc: KLH@SRI-NIC.ARPA In-Reply-To: Message from "Charles Hedrick " of Sat 16 Feb 85 21:18:13-PST Yes, this is a constants over-optimization bug. I have noted it for future fixing -- thanks for the simple test case. If you remove the angle brackets from the macro body, your example should work (the bracketing provided by [] is sufficient). ------- 20-Feb-85 09:08:46-PST,842;000000000000 Return-Path: Received: from LLL-MFE.ARPA by SU-SCORE.ARPA with TCP; Wed 20 Feb 85 09:08:32-PST Date: Wed, 17 Nov 58 00:00 GMT From: SAMUELSON%LLL@LLL-MFE.ARPA Subject: TOPS-20 TeX spooling To: tops-20@SU-SCORE.ARPA From: Norm Samuelson To: TeXHax@SU-SCORE.ARPA, tops-20@SU-SCORE.ARPA Telephone: (415) 422-0661, [FTS 532-0661] Office-Location: Bldg 543, room 1067 Postal-Address: LLNL, PO Box 5511, L-630, Livermore, CA 94550 Has anyone modified LPTSPL on TOPS-20 to handle .DVI files directly? We currently have a VERSATEC printer/plotter which has only 100dpi resolution, we will someday get a QMS-1200 laser printer. We would like to find a version of LPTSPL with the required hacks to read DVI files and write rasters to the Versatec. - Sam - ------- 20-Feb-85 16:28:23-PST,2358;000000000000 Return-Path: Received: from MIT-MC by SU-SCORE.ARPA with TCP; Wed 20 Feb 85 16:27:31-PST Date: 20 February 1985 15:15-EST From: Alan Bawden Subject: more help needed from a midas wizard To: HEDRICK @ RUTGERS cc: BUG-MIDAS @ MIT-MC, tops-20 @ SU-SCORE Date: 16 Feb 85 21:18:13 EST From: Charles Hedrick Could someone tell me why the following code generates an error complaining that there are more constants in pass 2 than pass 1? I assume this is a bug in Midas. title test loc 140 define object(type,val) <.byte 6,30. ? type ? val> termin move 1,[object 3,<4,,a>] move 1,[object 3,<4,,b>] a: 1 b: 2 end If you replace the macro calls to OBJECT with their definition, the error does not occur. Putting () around the call does not help. I replaced the macros calls to OBJECT to obtain the following: title test loc 140 move 1,[<.byte 6,30. ? 3 ? <4,,a>>] move 1,[<.byte 6,30. ? 3 ? <4,,b>>] a: 1 b: 2 end Which also gets the "more constants on pass 2" error, so I don't think that the macro has anything to do with it. (You must have spazzed when you performed the expansion manually.) Your problem would seem to be just another instance of a perennial midas screw. This one has probably shafted everybody at least once. What is happening is that on pass 1 Midas uses 0 as the value of as-yet undefined symbols, such as A and B in your example. This causes both literals to look like they will contain the same one-word quantity. Midas tries to be clever and optimize one-word literals to share the same storage. Then on pass 2 they turn out to be different and Midas hasn't allocated enough constants space. I don't understand why this one doesn't shaft people -more- than it does now. Big programs generally generate enough noise in their constants between pass 1 and pass 2 that they don't get screwed, only small programs get bit. I guess I would advocate putting in a switch to turn the constant-sharing hack off so that people can work around this screw when it happens. Clearly there are better solutions, but that would be sufficient. 21-Feb-85 14:34:36-PST,865;000000000000 Return-Path: Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Thu 21 Feb 85 14:32:47-PST Received: ID ; Thu 21 Feb 85 17:32:32-EST Date: Thu 21 Feb 85 17:32:31-EST From: Vince.Fuller@CMU-CS-C.ARPA Subject: Bug in my hack for UDP access... To: TOPS-20@SU-SCORE.ARPA If anyone has imported my changes to IPIPIP which allow non-priviliged users access to the Internet queues for UDP datagrams, I discovered a bug in that causes the system to hang. At ASNIQ0+28, there is a RETERR(NETWKX), taken if a user needs but does not have SC%ANA. This causes ASNIQ% to return with INTQLK locked, which hangs all jobs which attempt to use the Internet queues (and all jobss to RELIQ%'s during login/logout). This line should be changed to a JRST ASNIX1. At ASNIQX+2, add a SKIPA T1,[-1,,NETWKX]. --Vince ------- 21-Feb-85 16:25:57-PST,895;000000000000 Return-Path: Received: from COLUMBIA-20.ARPA by SU-SCORE.ARPA with TCP; Thu 21 Feb 85 16:25:45-PST Date: Thu 21 Feb 85 19:24:58-EST From: Chris Maio Subject: Re: Bug in my hack for UDP access... To: Vince.Fuller@CMU-CS-C.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Vince.Fuller@CMU-CS-C.ARPA" of Thu 21 Feb 85 17:53:48-EST I have another patch for system hangs in tcp/ip monitors. The symptoms are the same as Vince describes (processes hanging uninterruptably during RESET% or CLZFF% jsyses, or after ^C), and is related to TCP jfns (more specifically, TCBHLK is more than 10 or so and page zero of INTSEC exists). I don't recommend installing this patch if it's not needed, since it's really only a workaround, but if you've had this problem before let me know and I'll mail you the patch. - Chris ------- 22-Feb-85 13:06:36-PST,1173;000000000000 Mail-From: MRC created at 22-Feb-85 13:06:11 Date: Fri 22 Feb 85 13:06:11-PST From: Mark Crispin Subject: DTR control To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I know this issue is getting rather tiresome, but it's time for another round of the great "how do I set DTR on a dialout modem" series. I'd like to know what the current popular method is, for a site with Ven-Tel modems and *no* front-end sources running some version of the release 5 RSX with some unknown number of patches. Personally, I feel that having separate jsi to control DTR on modems (even as MTOPR's) is a crock. DTR should be set on a modem on creation of a dynamic data block from a user's OPENF% or ASND% and should be dropped on deletion of the dynamic data block. It even makes sense. ACJ can be used to enforce any access restrictions to dialout lines, just as any security-conscious site controls opening ordinary TTY's as devices. I tried using DEC's DTRFE.MIC file, but seem to have come up with a big zero. ------- 22-Feb-85 16:50:31-PST,1225;000000000000 Return-Path: Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Fri 22 Feb 85 16:49:42-PST Date: Fri 22 Feb 85 17:50:12-MST From: Randy Frank Subject: Re: DTR control To: MRC@SU-SCORE.ARPA, TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Mark Crispin " of Fri 22 Feb 85 14:41:33-MST The latest release of RSX20F (version 15-xx) finally contains supported code for controlling DTR from the back end. I believe that 20F 15-15 is currently in the SDC so it should be available shortly. Basically the code enables the queued protocol code .DFLDU (line dialed up) in the to-11 direction, in which case it turns on DTR. Previously this was only supported in the to-10 direction which was used when a remote line was connected. (Turning off DTR has always been supported via .DFLHU (line hang up)). At the moment there is no supported mtopr function for accessing these, but at least the front-end is no longer a problem. I agree with Mark that turning on DTR when a local line become active is a good idea; however, an MTOPR should also be provided since therre are cases where controlling DTR for other purpose is needed. ------- 22-Feb-85 17:37:33-PST,1010;000000000000 Return-Path: Received: from SRI-KL.ARPA by SU-SCORE.ARPA with TCP; Fri 22 Feb 85 17:37:22-PST Date: Fri 22 Feb 85 16:31:55-PST From: Ken Olum Subject: Re: DTR control To: MRC%SU-SCORE@SRI-KL cc: tops-20%SU-SCORE@SRI-KL In-Reply-To: Message from "Mark Crispin " of Fri 22 Feb 85 16:12:20-PST There's two problems -- how to get the front-end to set DTR and how to get the monitor to tell it. We tell the FE to set DTR on ASND/OPENF and also with MTOPR and that all works fine. The protocol that TOPS-20 uses to tell RSX20F what to do is the DIALUP function of the Queued-protocol, which is handled by some source-level patches to the FE. I've heard that some FE version from DEC does this without the patches, but no one has confirmed it. Failing that there's an OBJECT level patch to RSX20F, in use by HP, whereby when you send a set-speed command to the FE with the remote bit set that it sets DTR on the line. Ken ------- 23-Feb-85 10:49:03-PST,623;000000000000 Return-Path: Received: from SU-GSB-WHY.ARPA by SU-SCORE.ARPA with TCP; Sat 23 Feb 85 10:48:55-PST Date: Sat 23 Feb 85 10:48:53-PST From: Joel P. Bion Subject: DTR control To: tops-20@SU-SCORE.ARPA Indeed, the new front end does support DTR control. I used to run a modified front end, but now the new Digital front end standard does everything the modified one did. Include not working on DEC-DH controlled lines! (It seems to work on the Able DHs we have; HP had similar problems recently when they tried to use the new DEC front end.) Joel ------- 25-Feb-85 10:14:47-PST,753;000000000000 Return-Path: Received: from SRI-KL.ARPA by SU-SCORE.ARPA with TCP; Mon 25 Feb 85 10:14:32-PST Date: Mon 25 Feb 85 10:02:09-PST From: Haruka Takano Subject: Re: DTR control To: KDO@SRI-KL.ARPA, MRC%SU-SCORE@SRI-KL.ARPA cc: tops-20%SU-SCORE@SRI-KL.ARPA In-Reply-To: Message from "Ken Olum " of Mon 25 Feb 85 00:18:23-PST Actually, HP no longer uses the FE patch to which Ken Olum referred. Instead, we are running an unpatched RSX20F VB15-13. Since we were able to incorporate the monitor changes in use at the Stanford Graduate School of Business without any other mods, I assume that DEC is using FE code very similar to that developed by Joel P. Bion for GSB. --Haruka ------- 26-Feb-85 13:19:00-PST,2061;000000000000 Mail-From: MRC created at 26-Feb-85 13:18:42 Date: Tue 26 Feb 85 13:18:42-PST From: Mark Crispin Subject: MAISER status To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I now know of a way to get the local host address for a JFN-based connection (thank you, JTW) and consequently this interface to MAISER is now fully supported as an alternative to the TVT-based interface commonly in use. There are now two different SMTP listening programs, SMTPSV and SMTJFN. SMTPSV is as it has been; it listens for SMTP connections and will fire up MAISER jobs on network terminals to satisfy those requests without limit. SMTJFN runs MAISER subforks by redirecting the primary I/O to those subforks, and is assembled with a limit of 8 simultaneous connections. At the present time, the NETSRV program uses an SMTPSV style TVT interface; eventually it will be converted to a JFN interface. Which style of SMTP listener you run is mostly up to you. The TVT interface is probably less vulnerable to problems which would crash the JFN interface, because of the former's intrinsic simplicity. The TVT interface also allows many more simultaneous SMTP connections (assuming you care). The JFN interface is reputed to perform better, especially under TOPS-20 release 6. I believe that eventually the focus of support will migrate to the JFN interface. Also, contrary to earlier statements by me and some others, it looks like the SMTP/TVT performance problems are not due to any bug introduced in TVT service explicitly. In particular, the problem with "go-ahead" signals at MIT-XX was due to XX's using an unsupported portion of TVT service which DEC has turned off. So, apparently the "release 6 TVT problem" is a general behavior of release 6 and not some new bug. We all beat on KWP enough that it's only fair to set the record straight when it isn't his bug! -- Mark -- ------- 27-Feb-85 14:56:05-PST,1330;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Wed 27 Feb 85 14:55:33-PST Date: 27 Feb 85 17:55:34 EST From: Charles Hedrick Subject: I/O performance To: tops-20@SU-SCORE.ARPA We have 3 DEC-20's. They are all 1.25 or 1.5 MW of memory. Two of them have 3 RP06's for PS:. The third has 1 RP07. The third one seem to have much worse response for the same load average as the other two. It certainly has a somewhat different job mix, but we are beginning to suspect that the disk configuration is a problem. WATCH seems to show that we are getting about 50 pages/sec of I/O to PS:. Previous tests suggest that on our other systems, we get 75 to 100 pages/sec. We are wondering whether this means that 50 pages/sec is in fact the practical limit for RP07's in a timesharing mix (i.e. with PS: and paging on it). Does anybody have enough experience to know how an RP07 compares with 3 RP06's? As you may imagine, we are considering reconfiguring disks, either swapping drives around so that we use RP06's for PS: on all systems, going to a 2 RP07 PS:, or moving swapping to a non-PS: drive. We would be curious whether anyone else has either experience or measurements that would help us decide whether this is worth doing. ------- 27-Feb-85 18:20:48-PST,558;000000000000 Mail-From: MRC created at 27-Feb-85 18:20:13 Date: Wed 27 Feb 85 18:20:13-PST From: Mark Crispin Subject: more Ventel modems To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I have determined that in fact I am getting DTR set and the system is receiving characters from me. However, I am not getting anything from the modem. Could there be some problem in the lines being set to autobaud in the config file? ------- 27-Feb-85 20:54:54-PST,775;000000000000 Mail-From: CRISPIN created at 27-Feb-85 20:54:39 Date: Wed 27 Feb 85 20:54:39-PST From: Mark Crispin Subject: WARNING to MACREL users!!! Sender: CRISPIN@SU-SCORE.ARPA To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) It appears that the release 6 MACREL now assembles in a DEC copyright notice into the EXE file. As this may have substantial legal implications to users of the MACREL library I strongly suggest not using the release 6 MACREL and/or developing a private MACREL library for your own software. I just discovered this myself when debugging one of my programs. I was amazed to find the DEC copyright... ------- 27-Feb-85 22:42:48-PST,926;000000000000 Mail-From: BILLW created at 27-Feb-85 22:42:43 Date: Wed 27 Feb 85 22:42:43-PST From: William "Chops" Westfield Subject: bug in EXEC/Sumex GTJFN To: su-tops-20@SU-SCORE.ARPA When you type something on the order of G? to the exec, It will respond with a list of exec commands beginning with "G", followed by a list of FILES IN YOUR DIRECTORY that begin with "G". Clearly this in wrong. At worst, the files should come from SYS:, but I don't think that this is what is wanted either (since it would interfere with defaulting of commands). There ought to be a way to supress COMND from passing the "?" on to GTJFN. This could be either a new bit, or could be tied to CM%SDH and CM%HPP. Any feelings how this should be done? (I've looked at the code in COMND, and it should be fairly easy to fix CHKFIL to do the proper thing, once we decide what "proper" is.) BillW ------- 28-Feb-85 09:53:42-PST,1146;000000000000 Return-Path: Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Thu 28 Feb 85 09:53:37-PST Date: Thu 28 Feb 85 09:51:23-PST From: Andrew Sweer Subject: Re: bug in EXEC/Sumex GTJFN To: BILLW@SU-SCORE.ARPA cc: su-tops-20@SU-SCORE.ARPA Bill, I'm not sure what you're driving at. Here at Sumex, when you type something like M? to the exec, you get a list of exec commands beginning with M, followed by a list of files beginning with M that are in the 1st directory in your current definition of SYS:. It sounds like you may have had DSK: in there, whereas I usually have NEW: as the 1st item in my SYS:. It has been suggested that GTJFN be smartened up to search all the dirs in the logical name chain, but that is another story... Andy [PHOTO: Recording initiated Thu 28-Feb-85 9:37AM] @m? Command, one of the following: MAIL MAP MERGE MODIFY MOUNT or kept fork name, MCHECK MERLIN MODEM MTCOPY @m^C @v sys:m? MCHECK MERLIN MODEM MTCOPY @v sys:m^C @pop [PHOTO: Recording terminated Thu 28-Feb-85 9:38AM] ------- 28-Feb-85 10:34:56-PST,682;000000000000 Mail-From: MRC created at 28-Feb-85 10:34:52 Date: Thu 28 Feb 85 10:34:51-PST From: Mark Crispin Subject: Re: bug in EXEC/Sumex GTJFN To: BILLW@SU-SCORE.ARPA cc: su-tops-20@SU-SCORE.ARPA In-Reply-To: Message from "William "Chops" Westfield " of Wed 27 Feb 85 22:42:49-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) It isn't files in your directory that is output; it's the first directory in your SYS: search list. I'll bet you redefine SYS:. I'm not at all sure the present behavior is wrong. Sub-optimal, perhaps, but not wrong. ------- 28-Feb-85 11:11:13-PST,766;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Thu 28 Feb 85 11:11:08-PST Date: 28 Feb 1985 10:49 PST (Thu) Message-ID: From: Bill Palmer To: Andrew Sweer Cc: BILLW@SU-SCORE.ARPA, su-tops-20@SU-SCORE.ARPA Subject: bug in EXEC/Sumex GTJFN In-reply-to: Msg of 28 Feb 1985 09:51-PST from Andrew Sweer Stuart Reges posted a 2000+ char gripe/question about this same behavior to BUG-EXEC at LOTS some time ago. I'll repost it if I have a chance to hunt it down; it's a look at the problem from another viewpoint (that of a user who can't really be told to go look at the sources). Bill 28-Feb-85 11:30:50-PST,930;000000000000 Mail-From: MRC created at 28-Feb-85 11:30:41 Date: Thu 28 Feb 85 11:30:41-PST From: Mark Crispin Subject: Re: bug in EXEC/Sumex GTJFN To: whp4@SU-SIERRA.ARPA cc: SWEER@SUMEX-AIM.ARPA, BILLW@SU-SCORE.ARPA, su-tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Bill Palmer " of Thu 28 Feb 85 10:49:00-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) A more serious concern is the apparently bad interaction between the Sumex GTJFN% and the DSK* code. It seems that if you have the bugfix to support PS's which aren't named PS, there are various RELBAD bugchks which can result as well as logical names for DSK* (Score defines ALL: ala TOPS-10) not working. It isn't reliably reproducable. I imagine that the block address for the device name is remembered someplace it shouldn't be. ------- 28-Feb-85 13:27:09-PST,608;000000000000 Return-Path: Received: from SRI-KL.ARPA by SU-SCORE.ARPA with TCP; Thu 28 Feb 85 13:26:55-PST Date: Thu 28 Feb 85 12:09:20-PST From: Ken Olum Subject: Re: more Ventel modems To: MRC%SU-SCORE@SRI-KL cc: tops-20%SU-SCORE@SRI-KL In-Reply-To: Message from "Mark Crispin " of Wed 27 Feb 85 18:52:15-PST Which part of the system is getting the characters? There's a magic bit in the FE that you have to set to get it to listen to the line (I think it is TT.CON) DEC may not have set this bit in their DTR-setting routine. ken ------- 28-Feb-85 16:53:35-PST,841;000000000000 Mail-From: BILLW created at 28-Feb-85 16:52:48 Date: 28 Feb 1985 16:52-PST Sender: BILLW@SU-SCORE.ARPA Subject: Re: bug in EXEC/Sumex GTJFN From: William "Chops" Westfield To: SWEER@SUMEX-AIM.ARPA Cc: su-tops-20@SU-SCORE.ARPA Message-ID: <[SU-SCORE.ARPA]28-Feb-85 16:52:45.BILLW> In-Reply-To: The message of Thu 28 Feb 85 09:51:23-PST from Andrew Sweer oops. You are correct. I have DSK: first in my search list. And the bad interaction that I thought was happening (EXEC commands not completeing because they conflicted with file names (as in G$ not completing to GET), turns out to be due to invisible MIC commands (GOTO) instead, so I guess the problem isn't really there. (the provided help message SHOULD be printed, I think ("or system program:")). Sorry. Bill W 1-Mar-85 09:59:30-PST,658;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Fri 1 Mar 85 09:59:20-PST Date: Fri 1 Mar 85 10:00:17-PST From: Greg Satz Subject: [Ken Harrenstien : Filename wildcard lossage] To: su-tops-20@SU-SCORE.ARPA Phone: (415) 497-1004 Anyone feel like doing this? -------------------- Date: Fri 1 Feb 85 15:43:41-PST From: Ken Harrenstien Subject: filename wildcard lossage It appears that although will work to scan all subdirs of x, <.*> will not, even though you are connected to x. Barf. Something for the TOPS-20 list? ------- 2-Mar-85 13:42:19-PST,511;000000000000 Return-Path: Received: from nta-vax.ARPA by SU-SCORE.ARPA with TCP; Sat 2 Mar 85 13:41:29-PST Posted-Date: 2 Mar 1985 22:40-EST Received: by nta-vax.ARPA (4.12/3.21) id AA00600; Sat, 2 Mar 85 22:41:39 -0100 Date: 2 Mar 1985 22:40-EST From: bassen@nta-vax.ARPA Subject: oslo-vax address change To: tops-20@SU-SCORE Message-Id: <478647614/bassen@nta-vax> In-Reply-To: bassen's message of 2 Mar 1985 2205-EST Please change the network addres for oslo-vax to: 128.39.2.2 2-Mar-85 14:11:01-PST,1859;000000000000 Return-Path: Received: from columbia.arpa by SU-SCORE.ARPA with TCP; Sat 2 Mar 85 14:10:45-PST Received: from CU20B.ARPA by columbia.arpa; Sat, 2 Mar 85 04:37:52 est Date: Sat 2 Mar 85 17:10:53-EST From: Ken Rossman Subject: Query to Tops sites To: TOPS-20@SU-SCORE.ARPA Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 Dave asked me to forward this query to TOPS-20 for him. My apologies if it is inappropriate for this mailing list. /Ken --------------- Date: Fri 1 Mar 85 01:28:48-EST From: David Emigh Subject: Query to Tops sites The University of Saskatchewan is in the process of replacing the campus Dec-20 and have been wondering what kind of resale value could be expected on the hardware. The configuration is as follows: - 1 KL10-B processor, Serial# 2364 - 256Kw MB20 core memory - 1.5Mw MF20 Mos memory - 3 RP06 disk drives(1 dual-port) - 3 RH20 channels(for tapes and disks) - 1 RTP20 Disk subsystem(including 1 RH20 channel,1 Dx20 interface) - 96 asynchronous ports(Console Front-End) - 1 DN20 Front End, with 1 Synchronous line controller(KMC11/DUP11) - 2 TU45 tape drives with TM03 controller - 2 TU77 tape drives with TM03 controller - 1 LP20 900 LPM printer - 1 CD20 300 Card reader - 1 La120 console The system is about 5 years old and is currently running Top-20 Version 5.1. Replys can be forwarded to myself at the following USENET address: ...!ihnp4!sask!skyward!emigh or via snail mail address: David Emigh Systems Programmer Academic Computing Services Room 65, Arts Addtion Saskatoon, Saskatchewan Canada, S7N OWO ------- ------- 2-Mar-85 23:18:25-PST,899;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Sat 2 Mar 85 23:18:15-PST Date: 3 Mar 1985 00:18 MST (Sun) Message-ID: From: "Frank J. Wancho" To: TOPS20@SCORE Subject: Front-ending FINGER One of the features that FINGER lacks is the ability to lookup aliases (a feature I've been working with in building a finger for our C/70s under Unix). At first I considered modifying FINGER itself, but the fact that MMAILBOX loads it, and avoiding the recursive loading of MMAILBOX when FINGER is called at the normal entry point is possible although messy. The "better" solution would be to "front end" FINGER with a variant of MMAILBOX, which almost nobody knows about nor uses as a standalone program at its regular entry point. Has somebody already done this? --Frank 3-Mar-85 14:34:34-PST,1401;000000000000 Mail-From: MRC created at 3-Mar-85 14:34:20 Date: Sun 3 Mar 85 14:34:20-PST From: Mark Crispin Subject: Re: Front-ending FINGER To: WANCHO@SIMTEL20.ARPA cc: TOPS20@SU-SCORE.ARPA In-Reply-To: Message from ""Frank J. Wancho" " of Sun 3 Mar 85 00:18:00-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) One of the technical problems in this is also the fact that the TOPS-20 mailsystem makes no distinction between a mailing list, a mail forwarding, and a mail alias. All are instances of a mailbox that will deliver to one or more files/network recipients. This model has the advantage of being simple and working for most cases (the ITS mailsystem works similarly). It doesn't work too well when you really want to distinguish aliases as a separate entity (as in Frank's Finger project) from mailing lists and forwardings. Some things, such as "FINGER TOPS-20@SU-SCORE" in a system which can't tell aliases from mailing lists, would quickly demonstrate the problem. A similar problem is that it's difficult to have the "mail to mailer" feature that Unix has to get added to or removed from mailing lists in TOPS-20; there's no way for it to know that this "mailing list" isn't really an alias where the user's request should be disallowed. ------- 3-Mar-85 14:59:33-PST,1312;000000000000 Return-Path: Received: from columbia.arpa by SU-SCORE.ARPA with TCP; Sun 3 Mar 85 14:59:14-PST Received: from CU20B.ARPA by columbia.arpa; Sat, 2 Mar 85 16:46:14 est Date: Sun 3 Mar 85 18:00:24-EST From: Ken Rossman Subject: Re: Front-ending FINGER To: MRC@SU-SCORE.ARPA, WANCHO@SIMTEL20.ARPA Cc: TOPS20@SU-SCORE.ARPA In-Reply-To: Message from "Mark Crispin " of Sun 3 Mar 85 17:41:20-EST Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 As far as I'm concerned, MMAILBOX and Finger should go separate ways now. I really think the name server support in MMAILBOX should be entirely different code from Finger (i.e. I think the name lookup routine ought to be written into MMAILBOX, rather than MMAILBOX forking up Finger). There are several reasons for this: - I think the MMAILBOX name lookup code should perform a slightly different set of functions than Finger's name server code. - You would save at least three forks in the mailer subjob, depending on whether you use a multiforking SMTPSV or the job creation version (We would save a few more than three here at CU). Why not just make the name server into a separately requireable module? /Ken ------- 3-Mar-85 15:25:22-PST,794;000000000000 Mail-From: MRC created at 3-Mar-85 15:24:56 Date: Sun 3 Mar 85 15:24:55-PST From: Mark Crispin Subject: Re: Front-ending FINGER To: sy.Ken%CU20B@COLUMBIA.ARPA cc: WANCHO@SIMTEL20.ARPA, TOPS20@SU-SCORE.ARPA In-Reply-To: Message from "Ken Rossman " of Sun 3 Mar 85 14:59:32-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) The problem with putting Finger in MMailbox is that there are at least four distinct Finger programs for TOPS-20 that I know of, each with its own data base (uh, make that five). That would introduce site dependencies in MMailbox, something I abhor and have gone to great efforts to yank out of the entire mailsystem. ------- 4-Mar-85 01:52:39-PST,429;000000000000 Return-Path: Received: from oslo-vax.ARPA by SU-SCORE.ARPA with TCP; Mon 4 Mar 85 01:52:28-PST Received: by oslo-vax.ARPA (4.12/4.7) id AA10384; Mon, 4 Mar 85 10:52:56 -0100 Date: 4 Mar 1985 10:16-EST From: bassen@oslo-vax (T S Lande) Subject: oslo-vax address change To: tops-20@su-score Message-Id: <478775793/bassen@oslo-vax> I am sorry for my mistake posting address-change to the list. 4-Mar-85 12:44:59-PST,2482;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Mon 4 Mar 85 12:44:37-PST Date: 4 Mar 1985 1537-EST From: Reed B. Powell To: tops-20 at SU-SCORE, info-vax at SRI-KL cc: powell at LSMVAX, pomfret at IO Large-Systems-Marketing: LCG Product Line Location: "231-4261 MRO2-2/3C (Pole 4A)" REPLY: "MARKET:: or MRVAX::" Subject: Connecting Supercomputers to DEC's Cluster Systems Message-ID: <"MS10(2124)-1+GLXLIB1(1135)" 12092403673.40.146.104167 at DEC-MARLBORO> We are investigating the methods useful to the market for connecting the various "supercomputers" in the industry (Cybers, Crays, etc) to Digital's clustered systems. There are many reasons people have for desiring this, but usually it falls into the general catagory of "front-ending" the expensive supercomputers with lower cost systems used for data-preperation, data-presentation, etc. IE: Keep the supercomputer busy doing what it is best at. There are a number method of doing this. Hyperchannel seems to be doing well in the most general case of connecting anything to anything, but also seems to be adversely affected by coping with those generalities. What DEC is looking at is a method of hooking those systems up to DEC's systems. The only thing we have pretty much decided -- and even this is not cast in concrete -- is that is should be oriented around a connection to the CI bus, which is what connectes the systems of a cluster, as well as their disk servers, together. What we are specifically soliciting is information in two broad areas: 1. What functionality does the market want? Should we look into servers, gateways, rje-s, or what? Should the supercomputers "look" like another DEC computer on a cluster, or should there be something in between that performs a "monkey in the middle" function. 2. Ideas on implementation. It would be best if anyone submitting ideas in this catagory also include some information from the above catagory, since we must in the end justify our actions based on market needs. Since most of the supercomputers are in sites related to ARPAnet, this seems to be the best, most effecient way to gather this data. Anyone wanting to talk directly about this should leave a phone number, and someone related to this project will be glad to talk. thanks in advance, -reed -------- 4-Mar-85 21:53:04-PST,588;000000000000 Return-Path: Received: from SU-CSLI.ARPA by SU-SCORE.ARPA with TCP; Mon 4 Mar 85 21:52:58-PST Date: Mon 4 Mar 85 21:28:48-PST From: Mark Crispin Subject: <..foo[esc] To: SU-TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I crashed CSLI by doing completion on a subdirectory via "..". I have been told that this bug is well known but nobody fixed it because it is fixed in V6 and everybody will be running 6. What is this bull? ------- 4-Mar-85 21:58:10-PST,550;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Mon 4 Mar 85 21:58:05-PST Date: Mon 4 Mar 85 21:58:38-PST From: Kirk Lougheed Subject: Re: <..foo[esc] To: MRC@SU-CSLI.ARPA cc: SU-TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Mark Crispin " of Mon 4 Mar 85 21:57:26-PST That bug was fixed in the Release 5.3 sources as of 2-Oct-84. CSLI must be running an old monitor. Read the sources; don't believe what people tell you. Kirk ------- 4-Mar-85 21:58:24-PST,550;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Mon 4 Mar 85 21:58:05-PST Date: Mon 4 Mar 85 21:58:38-PST From: Kirk Lougheed Subject: Re: <..foo[esc] To: MRC@SU-CSLI.ARPA cc: SU-TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Mark Crispin " of Mon 4 Mar 85 21:57:26-PST That bug was fixed in the Release 5.3 sources as of 2-Oct-84. CSLI must be running an old monitor. Read the sources; don't believe what people tell you. Kirk ------- 5-Mar-85 15:16:00-PST,1325;000000000000 Mail-From: MRC created at 5-Mar-85 15:14:08 Date: Tue 5 Mar 85 15:14:07-PST From: Mark Crispin Subject: Announcing Cafard: TTY mail for TOPS-20 To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) The long-awaited Cafard (French for "cockroach") program has at last been completed. Cafard interfaces through the mailsystem's Special network interface to provide a mail facility over TTY lines. The current version of Cafard is Phase I, using a lock-step private protocol. I expect that there will be an operational Cafard link between two of Stanford's timesharing systems (one of which isn't on the campus Ethernet and won't be soon) sometime in the next week or two. Cafard's source files are on the usual MM distribution directory. CAFARD.MAC is the main program and script processor, CAFPRO.MAC contains the protocol routines, and CAFDTR.MAC is a site-written DTR control module (since it seems everybody has their own way to control DTR on a dialout modem). Documentation is on SCO:CAFARD.DOC; you may also want to look at the OPEN-DIALOG.TXT and CLOSE-DIALOG.TXT files on that directory as well as the SPECIAL-NETWORK.DOC file. ------- 5-Mar-85 22:21:17-PST,1037;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Tue 5 Mar 85 22:20:58-PST Date: Tue 5 Mar 85 22:21:02-PST From: Kirk Lougheed Subject: GTHST%/HSTINI interlock To: tops-20@SU-SCORE.ARPA Problem: While a new copy of the NIC's HOSTS.TXT is being loaded into the monitor, GTHST% will sometimes fail to find host names and addresses. This usually results in network mail being lost or dequeued and marked as "bad". Analysis: There is no interlocking on access to the monitor's internal host table. Solution: Implement a simple lock on the routines (HSTINI and the GTHST% JSYS) that manipulate the host table. The changes are all local to MNETDV.MAC. REDIT files for 5.3 and 6.0 monitors may be found on SU-SIERRA in PS: as MNETDV-53.RED and MNETDV-60.RED. Credit: Bill Palmer (WHP4@SIERRA) is the author of these changes. They have been running on Sierra under Release 6.0 since last Saturday without incident. ------- 5-Mar-85 22:24:42-PST,500;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Tue 5 Mar 85 22:24:33-PST Date: Tue 5 Mar 85 22:24:41-PST From: Kirk Lougheed Subject: extended FORTRAN-77 To: tops-20@SU-SCORE.ARPA Could some kind person point me to the changes necessary to create an extended addressing FORTRAN-77? I know some work was done by Norm Samuelson at Sandia, but I've lost track of where to get the changes. Thanks, Kirk ------- 6-Mar-85 07:49:11-PST,1474;000000000000 Return-Path: Received: from LLL-MFE.ARPA by SU-SCORE.ARPA with TCP; Wed 6 Mar 85 07:48:59-PST Date: Wed, 6 Mar 85 15:49 GMT From: SAMUELSON%LLL@LLL-MFE.ARPA Subject: Re: extended FORTRAN-77 To: tops-20@SU-SCORE.ARPA From: Norm Samuelson To: Lougheed@SU-SIERRA.ARPA cc: tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Kirk Lougheed " of Wed 6 Mar 85 07:24:24-PST Telephone: (415) 422-0661, [FTS 532-0661] Office-Location: Bldg 543, room 1067 Postal-Address: LLNL, PO Box 5511, L-630, Livermore, CA 94550 DEC's current FORTRAN compiler (v7) without any modifications produces code that will run in a non-zero section. With some help from a macro routine (which I can provide if anyone is interested) you can allocate memory in other sections and use it in either of two ways: 1) include an OFFSET in EVERY reference to each such extended array 2) pass the starting address of the array in a subroutine call in the first case the array can be in COMMON, in the second case the subroutine can access the argument array normally. Neither of those is absolutely ideal, and I would not put too much effort into making it work for a big program unless your needs are to have it working VERY soon. Far be it from me to say anything proprietary about an ongoing field test, but let me say that if you can wait a few months you may be VERY HAPPY. - Sam - ------- 6-Mar-85 08:23:01-PST,1307;000000000000 Return-Path: Received: from BBNA.ARPA by SU-SCORE.ARPA with TCP; Wed 6 Mar 85 08:22:50-PST Date: 6 Mar 1985 10:46-EST Sender: CLYNN@BBNA.ARPA Subject: Re: GTHST%/HSTINI interlock From: CLYNN@BBNA.ARPA To: Lougheed@SU-SIERRA.ARPA Cc: tops-20@SU-SCORE.ARPA Message-ID: <[BBNA.ARPA] 6-Mar-85 10:46:06.CLYNN> In-Reply-To: The message of Tue 5 Mar 85 22:21:02-PST from Kirk Lougheed When we installed a lock on the host tables at BBN last year we noted that things like SYS would hang when trying to translate "foreign host". We eventually added a GTHST% flag for use by those applications, such as mail, which really needed a translation; if the flag was not set and the tables were locked, GTHST% would fail. We are about to add the name resolver code being developed at ISI; I expect that the need to consult a foreign name server will make the problem more apparent. Options being considered include having the application specify a time that it is willing to wait before GTHST% should give up, a mode which gives up immediately if the translation is not in the local cache, and a mode which initiates resolution but fails if not in the cache. Does anyone have comments or suggestions about how the problem to be handled? Charlie 6-Mar-85 13:22:24-PST,846;000000000000 Return-Path: Received: from SRI-KL.ARPA by SU-SCORE.ARPA with TCP; Wed 6 Mar 85 13:21:35-PST Date: Wednesday, 6 March 1985, 12:40-PST From: Ken Olum Subject: Hung TCP connections from remote crash To: tops-20 at su-score Message-ID: <850306124023.2.KDO@FLEA.FLAIR> Here at Schlumberger we have the problem that if a TCP connection is open and the remote host crashes and remains down that the connection will be hung in EST.FIN or EST.NOT. No process ever seems to time out on the other host and declare the connection dead, so it stays around forever, and if it is a TVT connection then that TVT is wedged. 1. Have other people had this problem? Is there a fix? 2. How is it SUPPOSED to work? I can't find anything in the TCP spec that can detect the other side having crashed. Ken 6-Mar-85 15:23:20-PST,1783;000000000000 Return-Path: Received: from BBNA.ARPA by SU-SCORE.ARPA with TCP; Wed 6 Mar 85 15:23:05-PST Date: 6 Mar 1985 18:22-EST Sender: CLYNN@BBNA.ARPA Subject: Re: Hung TCP connections from remote crash From: CLYNN@BBNA.ARPA To: KDO@SRI-KL.ARPA Cc: tops-20@SU-SCORE.ARPA Message-ID: <[BBNA.ARPA] 6-Mar-85 18:22:02.CLYNN> In-Reply-To: <850306124023.2.KDO@FLEA.FLAIR> I am not sure what the protocol designers intended, but one might argue that the connection should sit there forever because the other end didn't really crash but chooses not to communicate (and possibly let everyone know they are still there). In a more commercial environment there are actions which can be taken. The TOPS-20 TCP periodically sends probes on inactive connections (unless the host administrator has disabled it). The probe is a SYN-ACK with a bad sequence number. The other end, if it has crashed and restarted, will send a reset reply which will cleanup the half open connection. If the other end has crashed and stays down, no resets will be received so the connection will stay around. The TOPS-20 TCP also has a timer (it was distributed as an hour) for inactive connections which reset the connection (a telnet job would be detached). Some sites, such as ISI, send a warning message on idle telnet connections; the message will start a retransmission timer which will kill the connection if the other host remains down. If the TOPS-20 and the other host are both on an 1822 net which gives host down messages, or if some ICMP were to send a destination unreachable message back to the 20, the connection would be aborted (but I do not think that DEC has the version of TCP which processes ICMP messages ready for distribution). Charlie 7-Mar-85 12:46:56-PST,1053;000000000000 Mail-From: CRISPIN created at 7-Mar-85 12:46:39 Date: Thu 7 Mar 85 12:46:39-PST From: Mark Crispin Subject: Re: GTHST%/HSTINI interlock Sender: CRISPIN@SU-SCORE.ARPA To: CLYNN@BBNA.ARPA cc: Lougheed@SU-SIERRA.ARPA, tops-20@SU-SCORE.ARPA In-Reply-To: Message from "CLYNN@BBNA.ARPA" of Wed 6 Mar 85 07:46:00-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) My main concern is that any application doing GTHST% in the traditional case should block. You should do something extra to get non-blocking. Upwards compatibility from the existing GTHST% is essential. This means that if you do a traditional GTHST% it must "work" in the traditional way -- "get data from host table of all hosts". Since there is no host table it should block in this case and fail only if there really is no such name anywhere. I'd be worried about major disasters with mail otherwise. Otherwise your plan sounds reasonable. -- Mark -- ------- 7-Mar-85 14:25:39-PST,710;000000000000 Return-Path: Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Thu 7 Mar 85 14:25:14-PST Received: ID ; Thu 7 Mar 85 17:25:06-EST Date: Thu 7 Mar 85 17:25:05-EST From: Vince.Fuller@CMU-CS-C.ARPA Subject: TELNET options To: tops-20@SU-SCORE.ARPA Has anyone out there experimented with adding additional TELNET option support to TOPS-20? The way that TTANDV is written, it would appear extremely difficult to add any new options - it appears to make rather bogus assumptions about the number of options in existance, being limited to about 8 of them. I would be interested to hear from anyone else who has tried to add new options. --Vince ------- 7-Mar-85 17:17:01-PST,882;000000000000 Return-Path: Received: from SRI-KL.ARPA by SU-SCORE.ARPA with TCP; Thu 7 Mar 85 17:16:41-PST Date: Thu 7 Mar 85 17:16:44-PST From: LARSON@SRI-KL.ARPA Subject: autopatch tape 8 To: tops-20@SU-SCORE.ARPA Finally, I am getting to working on the 5.4 monitor. I noticed that the files are based on the autopatch tape #8, however. I have found that tape, but I don't seem to have tape #7. Did such a tape exist? If so, are there any files on it that were not superseded by tape 8? I think the tape 8 I have may be wrong. I have the following: T20 5.1 AP6EXEC SRC MOD 16MT9 ;ap 6 T20 5.1 AP6 MON SRC MOD 16MT9 T20 5.1 AP8 EXEC SRC MOD 16M9 ;ap 8 T20 4.1 AP8 MON SRC MOD 16MT9 Why do I have a 4.1 MON SRC tape for AP8? I do not have a 2020, so I would not expect to be running rel4. Is this a typo, or what? Alan ------- 7-Mar-85 17:42:56-PST,710;000000000000 Return-Path: Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Thu 7 Mar 85 17:42:38-PST Date: Thu 7 Mar 85 17:41:09-PST From: David Roode Subject: Re: autopatch tape 8 To: LARSON@SRI-KL.ARPA, tops-20@SU-SCORE.ARPA In-Reply-To: Message from "LARSON@SRI-KL.ARPA" of Thu 7 Mar 85 17:32:43-PST Location: EJ286 Phone: (415) 859-2774 You do not have a 2020 but the Q number used for our updates is for the 2020 updates... I sent a message about this problem to the TOPS-20 list a while back. You have to change Q numbers to get the non-2020 monitor distribution, and the former Q number for "current TOPS-20" means "current 2020 TOPS-20." ------- 7-Mar-85 22:11:38-PST,2736;000000000000 Return-Path: Received: from UTEXAS-20.ARPA by SU-SCORE.ARPA with TCP; Thu 7 Mar 85 22:11:25-PST Date: Thu 7 Mar 85 23:37:14-CST From: Clive Dawson Subject: Re: TELNET options To: Vince.Fuller@CMU-CS-C.ARPA cc: tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Vince.Fuller@CMU-CS-C.ARPA" of Thu 7 Mar 85 16:53:53-CST I'm not sure what I have in mind for TELNET is an "option" of the sort you're talking about, but as long as we're on the subject... The feature I need is one which will allow selective TELNET listening based on the particular Internet network requesting the connection. In particular, I want to be able to reject TELNET requests from over the Arpanet at certain times, but continue to accept them from our internal Ethernet-based network. (We're running 5.4 with an NI.) Clearly ^ESET NO LOGIN ARPA doesn't suffice in this case, since that will reject all TCP connections, regardless of the network. There are two main approaches we're considering: 1. Add an argument to the ^ESET LOG ARPA command which will accept a foreign host "mask" specifying who gets let in. This would in turn cause a new SMON call to pass this arg to the monitor so that the Internet fork could use it in the OPEN% call when listening for a Telnet connection. An arg of 0.0.0.0 would effectively allow anybody in, an arg of 10.0.0.0 would allow only ARPA hosts, an arg of 192.5.89.0 would allow only our internal net, etc. 2. Another approach would be to set a bit in the NCT for a given interface. The FNDNCT routine could then check for the bit and fail if it wasn't set. This approach isn't quite as general since it selects based on an entire net rather than a set of hosts, but would nevertheless meet our need. Also it is cleaner in the sense that we don't have to keep be conscious of changing host addresses, etc. Has anybody out there already solved this problem in some way? In any case, I'd be interested in hearing comments from anybody on the best way to do this. On a more general level, I think Kevin could certainly use feedback from all of us regarding features of this sort. Many sites are running into problems like the one above, only in reverse--e.g. how do you keep users on internal networks off the Arpanet. It would be nice if we could reach a consensus regarding what the needs are: ability to restrict gateway functions based on network/host/port in one or both directions, ability to define a set of "trusted" or "authorized" hosts on an internal net for which we will do gatewaying, etc. etc. Cheers, Clive ------- 8-Mar-85 00:17:43-PST,541;000000000000 Mail-From: BILLW created at 8-Mar-85 00:17:38 Date: Fri 8 Mar 85 00:17:38-PST From: William "Chops" Westfield Subject: CLZFF misfeature? To: su-tops-20@SU-SCORE.ARPA CLZFF will abort any existing TCP connections, even if you specified that only non-open files should be RLJFNed. This is because there isn't any check for this flag at CLZFF1 in JSYSF. Can anyone think of a reason that this test should not be added, and TCP connections be considered always "open" for this system call? BillW ------- 8-Mar-85 13:04:58-PST,590;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Fri 8 Mar 85 13:04:43-PST Date: Fri 8 Mar 85 16:02:31-EST From: Kevin Paetzold Subject: Re: autopatch tape 8 To: LARSON@SRI-KL.ARPA cc: tops-20@SU-SCORE.ARPA In-Reply-To: Message from "LARSON@SRI-KL.ARPA" of Thu 7 Mar 85 20:28:29-EST Telephone: 617-467-7430 (DTN: 231-7430) Mail-stop: MRO1-2/L10 i think tape 8 has a complete set of sources (right?). i do not know if it is a typo or not. look at the files and i should be obvious. ------- 8-Mar-85 16:04:01-PST,970;000000000000 Mail-From: CRISPIN created at 8-Mar-85 16:03:44 Date: Fri 8 Mar 85 16:03:44-PST From: Mark Crispin Subject: Andy Sweer's patch to TCPJFN Sender: CRISPIN@SU-SCORE.ARPA To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Andy's patch to TCPJFN will fix the ILLUUO problems. It will also cause a byte to be lost from the data stream. The correct fix is NOT to install Andy's patch. Instead, after the NOP in TCSQI6, insert a SETZRO . You can clear ERRF too if you want that last byte before the error. The effect of this patch is NEVER to block if (1) a byte was read but (2) the system can't get another buffer just yet. Instead, it will return to the user and block the next time the user does a BIN%. That is of course if there is still a reason to block. -- your friendly programmer of pandas. ------- 9-Mar-85 14:07:26-PST,1041;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Sat 9 Mar 85 14:07:21-PST Date: Sat 9 Mar 85 14:06:54-PST From: Kirk Lougheed Subject: Re: CLZFF misfeature? To: BILLW@SU-SCORE.ARPA cc: su-tops-20@SU-SCORE.ARPA Bill Palmer took a look at this problem a couple of weeks ago. There turned out to be two bugs involving CZ%NCL in CLZFF%. One was the obvious non-checking of the flag near CLZFF6. The less obvious bug was a call to ABTJCS near CLZFF1. The effect is that everytime you do a CLZFF% on a process that has any active JCN's, those JCN's are going to get clobbered. Bill developed a patch for ABTJCS that fixed the CZ%NCL problem. I don't think anything was ever installed in sources -- the mixing of JCN's and JFN's really messes up the JFN interface assumptions of TOPS-20. So, if this bug needs to be fixed, it needs fixing in two places. I'm still unsure as to why anyone would want the functionality of CZ%NCL. Kirk ------- 9-Mar-85 22:11:47-PST,1324;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Sat 9 Mar 85 22:11:13-PST Date: 9 Mar 1985 23:10 MST (Sat) Message-ID: From: "Frank J. Wancho" To: TOPS-20@SCORE Subject: "Non-privileged" BUILD wanted I have two administrator types who want/need the capability to use BUILD (and perhaps related utilities like ULIST). The catch is that I don't want to give them WOPR privileges - another case for being able to subdivide the current all or nothing situation that I doubt will be available before version 7 (if there is one, and if that item is still on the list). So, I'd like to hear from *anyone* who has given some thought to this problem of providing a non-privileged BUILD, and maybe even has such a thing in production use. The prefered technique is a BUILD-like user program that communicates via IPCF to a wheel program that validates the requestor, does the actual CRDIR%, and logs the action. I have already rejected group or password access to as not much better than just giving them WOPR privileges in the first place, and certainly much less secure. (A "non-privileged" ULIST would also be of interest, but not as high a priority right now.) --Frank 12-Mar-85 08:40:26-PST,560;000000000000 Return-Path: Received: from CMU-CC-TE by SU-SCORE.ARPA with TCP; Tue 12 Mar 85 08:40:09-PST Date: Tue 12 Mar 85 11:39:38-EST From: Eric Crane Subject: Difference between FMP and FMPR To: Tops-20@SU-SCORE.ARPA Office: Ucc 130 x3568 Secretary: x2638 Someone asked me what the difference between FMP and FMPR are, it seems that they could not detect any rounding being done. Can any of you explain to me when and if rounding will take place? How about a small example. - Thanks Eric Crane ------- 12-Mar-85 10:04:17-PST,408;000000000000 Return-Path: Received: from MCC.ARPA by SU-SCORE.ARPA with TCP; Tue 12 Mar 85 10:04:07-PST Date: Tue 12 Mar 85 12:03:49-CST From: Clive Dawson Subject: FMP vs FMPR To: tops20@SU-SCORE.ARPA I just picked a couple of numbers and tried it: 1/ 123456,,123457 2/ 3 FMP 1,2 produces 1/ 271705,,175306 FMPR 1,2 produces 1/ 271705,,175307 ------- 12-Mar-85 11:01:41-PST,1364;000000000000 Return-Path: Received: from CU20B.ARPA by SU-SCORE.ARPA with TCP; Tue 12 Mar 85 11:01:17-PST Date: Tue 12 Mar 85 13:59:25-EST From: Jeff Damens Subject: Re: Difference between FMP and FMPR To: EC0N%CMU-CC-TE@CMU-CC-TE.ARPA cc: Tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Eric Crane " of Tue 12 Mar 85 11:46:50-EST When multiplying floating point numbers, two 27-bit mantissas are multiplied to form a 54-bit product. This product is normalized (ie, shifted left until its high-order bit is non-zero), and then must be stored back into 27 bits. FMP truncates after the 27th bit; FMPR rounds up before truncating. You'll see a difference when multiplying numbers whose products have significant bits at the left (so normalization doesn't leave you with a number that only has 27 significant bits) and near bit 28. Here's an example that shows a difference (my comments are on the right, preceded by an !). Jeff @sddt DDT $$f 1/ 0 2.0 2/ 0 3.0 fdv 1,2$x <> 1/ 6.6666666E-01 ! this is 2/3 move 5,1$x ! save a copy here <> 2! 0.1 fmp 5,2$x ! multiply by .1 <> fmpr 1,2$x ! multiply by .1 with rounding <> 1/ 6.6666666E-02 ! the difference crops up in the 5/ 6.6666665E-02 ! last digit ------- 12-Mar-85 16:41:29-PST,1387;000000000000 Return-Path: Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Tue 12 Mar 85 16:41:04-PST Date: Tue 12 Mar 85 16:36:30-PST From: Andrew Sweer Subject: Big Buffer Query To: TOPS20@SU-SCORE.ARPA It seems like forever that the Big Buffer (TTBBUF) for holding characters input from front-end controlled TTY lines has been 128 chars long. This relatively small size mandates the special handling of lines that that "seem" to be using a disproportinate share of this resource, either by sending an XOFF or by setting the input speed of the line to 0 for some period. My query comes due to the proliferation of what I hear called "lock step" protocol programs like XMODEM and MACGET which try to transfer files over active TTY lines in 128 byte packets (actually 132 bytes if you count the header and checksum). These programs want to send or receive single packets at a time, and wait for an acknowledgement from the other end for each packet. Clearly, the special handling referred to above gets in the way of this. The changes to increase the Big Buffer to, say, 500 chars, and at the same time allow a single line up to 132 or so chars seem straightforward enough, but I thought it was worth checking around to see if anyone else has tried it, successfully or not. Andy ------- 15-Mar-85 11:53:43-PST,536;000000000000 Mail-From: MRC created at 15-Mar-85 11:53:32 Date: Fri 15 Mar 85 11:53:32-PST From: Mark Crispin Subject: new version of NETSRV To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Sites using NETSRV's "log file" capability should get the new version of NETSRV from SCO: at Score. A bug where the log file could get locked up (and hence hang all of NETSRV) has been uncovered and fixed. ------- 17-Mar-85 16:38:14-PST,1716;000000000001 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Sun 17 Mar 85 16:38:11-PST Date: Sun 17 Mar 85 16:38:47-PST From: Kirk Lougheed Subject: Passwords and 6.0 To: eric@SU-CSLI.ARPA cc: su-tops-20@SU-SCORE.ARPA One of the hazards in going to a 6.0 system has to do with how password is handled. From telneting over to CSLI, it appears that they've been having problems in that respect. This note describes how to fix matters. Kirk -------- The format of the directory page is slightly different betweeen Stanford Release 5 and Release 6 monitors. The principle difference is in how passwords are flagged as encrypted. Under Release 5 we used a bit in the .CDMOD word; under Release 6 a new version word has been added. After you've booted the 6.0 system and have managed to login by patching the LOGIN% JSYS, you need to perform the following actions to make the password checker interpret the passwords correctly. Run the new CHECKD and give the following command: CHECKD>enable password-encryption ps: Then get into MDDT and patch the location SUFCNV to be -1. It should be zero beforehand. The SUFCNV cell enables some code in CRDIR% (see JSYSF) to convert the directory page. Then get a copy of FLUSH.EXE from Sierra (source is PS:FLUSH.FAI) and give the following command: FLUSH>convert ps: When FLUSH finishes, your 5.3 filesystem has been converted to 6.0 format. It is possible to roll back; read the code in JSYSF. The above procedure is believed to work. Caution is advised, however. It might be prudent to run DLUSER before mangling your filesystem. ------- 17-Mar-85 19:02:40-PST,863;000000000000 Mail-From: BILLW created at 17-Mar-85 19:02:38 Date: Sun 17 Mar 85 19:02:38-PST From: William "Chops" Westfield Subject: finger enhancements To: su-tops-20@SU-SCORE.ARPA I made a couple of changes to FINGER: /PHYSICAL-LOCATIONS will list Tip names and port numbers and so on always (/REAL-LOCATIONS used to do this apparently) This is useful to the people installing and/or fixing peoples terminal lines, among others. /WHOIS will now cause a persons plan file to be listed, even if they are logged in. F/WHOIS will type the plan files of everyone logged in... (precedent: MITs finger does this, sort of) There was also a bug fix to a bug that normally wouldn't show up since not much was done after a PNTPLN was called. sources on SCORE in PS:FINGER.MAC BillW ------- 19-Mar-85 23:29:51-PST,1001;000000000000 Mail-From: MRC created at 19-Mar-85 23:29:36 Date: Tue 19 Mar 85 23:29:35-PST From: Mark Crispin Subject: New Orleans DECUS To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I got my copy of the New Orleans DECUS symposium registration kit and preliminary program. Not only is the price up (now $300 for 5 days), but the hotels are even more expensive than ever (the cheapest is $74/night) with a $75 deposit. Then there's the write-up for Large Systems; a tiny 9-liner talking about the "renewed emphasis on traditional technical sessions" and "integration sessions for those of us who are converting to VAX/VMS." It's the smallest SIG writeup in the program. There are no large systems sessions at all on Friday. The Town Meeting is a mere 1 hour; most of the sessions are migration-to-VMS sessions. There is a 1-hour TCP/IP session, however. ------- 20-Mar-85 07:12:18-PST,890;000000000000 Return-Path: Received: from LLL-MFE.ARPA by SU-SCORE.ARPA with TCP; Wed 20 Mar 85 07:12:09-PST Date: Wed, 20 Mar 85 15:13 GMT From: SAMUELSON%LLL@LLL-MFE.ARPA Subject: Re: Connecting Supercomputers to DEC's Cluster Systems To: tops-20@SU-SCORE.ARPA From: Norm Samuelson To: Powell@DEC-MARLBORO.ARPA, tops-20@SU-SCORE.ARPA, info-vax@SRI-KL.ARPA In-Reply-To: Message from "Reed B. Powell " of Mon 4 Mar 85 12:37:00-PST Telephone: (415) 422-0661, [FTS 532-0661] Office-Location: Bldg 543, room 1067 Postal-Address: LLNL, PO Box 5511, L-630, Livermore, CA 94550 Since, as you noted, most CRAY sites use HYPERCHANNEL to connect their CRAYs to each other, you should come up with an interface from the CI to the HYPERCHANNEL, not try to replace the Hyperchannel. - Sam - ------- 20-Mar-85 15:12:49-PST,1148;000000000000 Return-Path: Received: from DREA-XX.ARPA by SU-SCORE.ARPA with TCP; Wed 20 Mar 85 15:12:17-PST Date: Wed 20 Mar 85 19:11:27-AST From: Peter Gergely Subject: Modifications to BBOARD.MAC To: tops-20@SU-SCORE.ARPA I have made some extensions to BBOARD.MAC (based upon edit 67, 22 Oct 82 UT version). These include: - Allowing the use of wildcards in the bulletin board file specs omitting any repeats. For example: BBOARD BBD:,SYSTEM:,* would try to read BBD:MAIL,SYSTEM:MAIL, and all BBD:*.TXT files excluding BBD:MAIL as it has already been used. - Putting the subject on a separate line, if the date, author, and subject fields will exceed a width of 72 columns. - A blank line between messages. - Fixing /ACTION so that the "Reading ..." message always starts on a new line. Availability: The file PS:BBOARD.MAC is available using ANONYMOUS FTP from DREA-XX. Note: NIC host tables 433 and greater list DREA-XX. The code is commented by .DREA.,.CRLF., and .WJFN. switches, and comments beginning with [PJG]. Peter J. Gergely ------- 20-Mar-85 20:30:15-PST,1251;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Wed 20 Mar 85 20:30:04-PST Date: 20 Mar 1985 21:29 MST (Wed) Message-ID: From: "Frank J. Wancho" To: Peter Gergely Cc: tops-20@SU-SCORE, WANCHO@SIMTEL20 Subject: Modifications to BBOARD.MAC In-reply-to: Msg of 20 Mar 1985 16:11-MST from Peter Gergely Peter, I'm glad to see that this program is not dead yet. I also made the minor change to present the header, but as a real header: From: and Subject: on separate lines all the time. Now all we need is someone to make BBOARD use the same "last message read" files as MM's BBOARD command uses and we'd be all ahead of the game. The reason is that neither knows about the other's database, and popping "down" to MM from BBOARD produces inconsistent results as to which was the last message seen by which program, and ends up confusing the user. I use a third interface and neither of those two programs. BABYL's BBOARD uses the user's SWITCH.INI file to keep track of things... But, I'll settle for two-way consistency between BBOARD and MM's BBOARD. --Frank 21-Mar-85 03:20:58-PST,664;000000000000 Return-Path: Received: from DREA-XX.ARPA by SU-SCORE.ARPA with TCP; Thu 21 Mar 85 03:20:48-PST Date: Thu 21 Mar 85 07:20:10-AST From: Peter Gergely Subject: Further Extension to BBOARD To: tops-20@SU-SCORE.ARPA Effective with this message, is one more change to BBOARD.MAC. It is the addition of the "X" command, to "Exit BBOARD, skipping all remaining bulletin boards". As per the "E" or "Q" command, nothing is updated from that point on, so you will get to see the bulletin boards again if requested. It is available as PS:BBOARD.MAC, via ANONYMOUS FTP to DREA-XX. - Peter ------- 21-Mar-85 06:22:08-PST,1096;000000000000 Return-Path: Received: from LLL-MFE.ARPA by SU-SCORE.ARPA with TCP; Thu 21 Mar 85 06:21:58-PST Date: Thu, 21 Mar 85 14:19 GMT From: SAMUELSON%LLL@LLL-MFE.ARPA Subject: Re: Modifications to BBOARD.MAC To: tops-20@SU-SCORE.ARPA From: Norm Samuelson To: WANCHO@SIMTEL20.ARPA, Gergely@drea-xx.arpa, tops-20@SU-SCORE.ARPA In-Reply-To: Message from ""Frank J. Wancho" " of Wed 20 Mar 85 21:29:00-PST Telephone: (415) 422-0661, [FTS 532-0661] Office-Location: Bldg 543, room 1067 Postal-Address: LLNL, PO Box 5511, L-630, Livermore, CA 94550 I will second Wancho's request that somebody, somewhere, please make BBOARD and MM use the same file for keeping track of which messages have been read. While anyone is working on BBOARD, the one addition that would make BBOARD easier to live with would be some way to tell it to clear the screen after you say you want to read a message, just before it starts to type it. Scrolling thru bboards is hard on the eye muscles. - Sam - ------- 21-Mar-85 11:24:17-PST,351;000000000000 Mail-From: MRC created at 21-Mar-85 11:22:45 Date: Thu 21 Mar 85 11:22:45-PST From: Mark Crispin Subject: host tables To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) It's time to increase NHOSTS again! Sigh! ------- 21-Mar-85 13:04:11-PST,1187;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Thu 21 Mar 85 13:03:53-PST Date: Thu 21 Mar 85 14:03:41-MST From: Mark Crispin Subject: avoiding increasing NHOSTS To: TOPS-20@SU-SCORE.ARPA Problem: NHOSTS again. Once again the NIC table has outgrown TOPS-20. Diagnosis: The actual host table is 2.25 times larger than the space used. Only the name space is too small. The calculation of the name space, based on NHOSTS, is much too conservative. Back in HSTNAM.TXT days it was appropriate but no longer. Solution: In STG.MAC, replace the line: NDG NHSTN, ;LENGTH OF HOST NAME TABLE (TEXT) with: NDG NHSTN, ;LENGTH OF HOST NAME TABLE (TEXT) If you are worried about GTHST% performance it may be a bit too drastic to use NHOSTS*6 and perhaps NHOSTS*5 would be better. I think NHOSTS*6 should be alright because at the current NIC ratio of name sizes to addresses you would still have 12.5% hash table free space. Right now there is more like 56% hash free space which is much more than really needed. Mark Crispin PANDA PROGRAMMING ------- 21-Mar-85 13:30:35-PST,479;000000000000 Return-Path: Received: from WASHINGTON.ARPA by SU-SCORE.ARPA with TCP; Thu 21 Mar 85 13:29:57-PST Date: Thu 21 Mar 85 13:28:08-PST From: Richard Furuta Subject: Anyone have an ANSI tape utility? To: tops-20@SU-SCORE.ARPA cc: Furuta@WASHINGTON.ARPA I need a utility to allow me to write ANSI labeled tapes, playing with things like blocking factors, etc. Anyone have one I could have? Thanks. --Rick ------- 21-Mar-85 14:08:00-PST,1902;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Thu 21 Mar 85 14:07:37-PST Date: 21 Mar 1985 1659-EST From: Tom Blinn To: Furuta at WASHINGTON, tops-20 at SU-SCORE Subject: Re: Anyone have an ANSI tape utility? Message-ID: <"MS10(2124)-1+GLXLIB1(1135)" 12096875040.17.275.17060 at DEC-MARLBORO> Regarding: Message from Richard Furuta of 21-Mar-85 1642-EST One approach is to use the TOPS-20 EXEC. I assume you wish to write regular text files, i.e., stream ASCII, onto the tapes, and wish to try different blocksizes. First, get the tape initialized to have ANSI labels, and mount it for WRITE access. Use, e.g., MT: as the logical name when you mount the tape. Then define a logical name as the destination for copying, e.g., DEFINE TAPE: MT:*.*.*;FORM:D;RECORD:nnn;BLOCK:mmm where "nnn" is at least 4 greater than the longest record in the source files (e.g., 132 if the source lines are at most 128 bytes, exclusive of the delimiting CR-LF), and "mmm" is the blocksize you want to use. Then just use the COPY command, with a possibly wild- carded input disk file and TAPE: as the destination. (If you let the destination generation default to .-1 as it normally does for disk files, then every file on the tape will have its generation number field be the 6-digit decimal value that is 777777 octal, i.e., halfword -1.) This writes variable-length records on the tape. If you want fixed- length files, the file on disk must be fixed-length, that is, every record exactly the number of bytes to be written onto the tape, and the file's size an exact multiple of the number of bytes in a record. Try it, you should like it. The secret to success is specifying the attributes on the destination file specification. Tom -------- 21-Mar-85 16:58:39-PST,1066;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Thu 21 Mar 85 16:58:20-PST Date: Thu 21 Mar 85 17:57:59-MST From: Mark Crispin Subject: NHOSTS retraction To: TOPS-20@SU-SCORE.ARPA Contrary to my previous message, the problem is not in the host name string space. The problem is that there are too many host names! Specifically, in the current NIC table there are 1867 addresses and a whopping 4035 names. Surprisingly, those names only require 10220 words of string space (all numbers decimal here), so the present setting of NHSTN=3*NHOSTS or KWP's new setting of NHSTN=4*NHOSTS is quite enough for the present. The right thing to do is to increase the size of the HOSTN table, to be, say, 2*NHOSTS. You will also have to modify the HSTINI routine in MNETDV to know that HOSTN is bigger than the other tables. This should allow for a doubling of the NIC table without increasing NHOSTS from the present 4001. Mark Crispin PANDA PROGRAMMING ------- 21-Mar-85 19:43:31-PST,580;000000000000 Return-Path: Received: from USC-ISIB.ARPA by SU-SCORE.ARPA with TCP; Thu 21 Mar 85 19:43:09-PST Date: 21 Mar 1985 19:40:53 PST Subject: Re: Anyone have an ANSI tape utility? From: Bob Knight To: Richard Furuta cc: tops-20@SU-SCORE.ARPA In-Reply-To: (Message from "Richard Furuta " of Thu 21 Mar 85 13:28:08-PST) Stanford has a utility, TAPEIO, that will tickle you pink. Perhaps Kirk Lougheed or Bill Westfield could direct you to an FTPable copy. Bob ------- 21-Mar-85 20:08:35-PST,584;000000000000 Return-Path: Received: from USC-ISIB.ARPA by SU-SCORE.ARPA with TCP; Thu 21 Mar 85 20:08:26-PST Date: 21 Mar 1985 19:59:50 PST Subject: Re: Anyone have an ANSI tape utility? From: Bob Knight To: tops20@SU-SCORE.ARPA In-Reply-To: <"MS10(2124)-1+GLXLIB1(1135)" 12096875040.17.275.17060 at DEC-MARLBORO> Tom's method will work if you have a TM02. However, I do not believe that the TM03 and TM78 support ANSI-ASCII transfers. Also, if you don't run a labelled shop, you'll generate a non-labelled tape. Bob ------- 21-Mar-85 21:39:58-PST,1548;000000000000 Return-Path: Received: from CU20B.ARPA by SU-SCORE.ARPA with TCP; Thu 21 Mar 85 21:39:46-PST Date: Fri 22 Mar 85 00:39:48-EST From: Ken Rossman Subject: Re: Anyone have an ANSI tape utility? To: TOPS-20@SU-SCORE.ARPA, SWG.KNIGHT@USC-ISIB.ARPA In-Reply-To: Message from "Bob Knight " of Thu 21 Mar 85 19:59:50-EST Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 A TM02 is not required to write a standard ANSI-ASCII tape. The ANSI-ASCII TM02 hardware mode is really just a convenience, and I assume was eliminated in later versions of tape controllers because it was, in fact unnecessary. Industry-Compatible mode will do just fine for any tape you might need to write, since it is capable of reading and writing every bit in each frame, though some software munging may be necessary. I personally don't like to use the EXEC for this type of transfer because I am never quite sure what I'll end up with on the tape. It's never been obvious to me what the effect of setting different hardware modes, and using the ASCII or BYTE n subcommands will do. There are certainly more than a few ANSI tape reader/writer programs around, some of which provide a few other conveniences in addition to being able to write the basic tape. TAPEIO is one example -- it covers quite a range of different tape formats. We use here, I believe, some variation on a set of programs by Hedrick to write our ANSI Kermit tapes. /Ken ------- 22-Mar-85 00:16:43-PST,1281;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Fri 22 Mar 85 00:16:21-PST Date: Fri 22 Mar 85 01:16:10-MST From: Mark Crispin Subject: NHOSTS: the final word To: TOPS-20@SU-SCORE.ARPA I doubled the size of HOSTN to 2*NHOSTS (I called this size NHOSTN) and fixed HSTINI in MNETDV to use this size and tested it at SIMTEL20. It works like a champ. While I was at it I replaced the loop in HSTINI that zeros the various tables with a BLT. The comments are somewhat confusing in HSTINI and STG. Basically, HOSTN is *not* a hashed table. HOSTNN is, and HOSTPN and HSTSTS are parallel to this table. HOSTN entries are in the form BYTE(1)NicknameFlag(17)HSTNAMindex(18)HashIndex NicknameFlag is set if this name is a nickname HSTNAMindex is the index into the HSTNAM (host name string space) area with the name this entry is for HashIndex is the index into the various parallel hash tables With this change in place, you can essentially leave NHOSTS set at the present ^D4001 until the NIC table approximately doubles in size. What was running out was not the number of hash slots (only 1867 were in use) but rather the number of names (NIC table 435 has 4035 names). ------- 22-Mar-85 00:29:23-PST,375;000000000000 Return-Path: Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Fri 22 Mar 85 00:29:04-PST Date: Fri 22 Mar 85 00:27:40-PST From: David Roode Subject: IDDT for extended addressing To: TOPS-20@SU-SCORE.ARPA Location: EJ286 Phone: (415) 859-2774 Has anyone got a modified IDDT to support section addressing? ------- 22-Mar-85 03:18:01-PST,611;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Fri 22 Mar 85 03:17:52-PST Date: 22 Mar 1985 0612-EST From: B.Eiben LCG Ext 617-467-4431 To: furuta at WASHINGTON cc: Tops-20 at SU-SCORE Subject: Re: Anyone have an ANSI tape utility? Message-ID: <"MS10(2124)-1+GLXLIB1(1135)" 12097019383.20.249.34685 at DEC-MARLBORO> The "Rutgers Pascal-based" programs [short and sweet - readable code and predictable functionality] from Chuck Hedricks are here in TOPS:READ%.* and TOPS:WRITE%.* - [via anonymous ftp] Bernie -------- 22-Mar-85 10:26:45-PST,461;000000000000 Return-Path: Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Fri 22 Mar 85 10:26:33-PST Received: ID ; Fri 22 Mar 85 13:26:16-EST Date: Fri 22 Mar 85 13:26:12-EST From: Vince.Fuller@CMU-CS-C.ARPA Subject: DTE question To: tops-20@SU-SCORE.ARPA Does anyone know if the DTE will accept an 1-word global byte pointer? In particular, will giving DTEQ a 1-word global byte pointer work? --Vince ------- 22-Mar-85 12:52:19-PST,505;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Fri 22 Mar 85 12:52:00-PST Date: Fri 22 Mar 85 15:50:55-EST From: GROSSMAN@DEC-MARLBORO.ARPA Subject: Re: DTE question To: Vince.Fuller@CMU-CS-C.ARPA cc: tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Vince.Fuller@CMU-CS-C.ARPA" of Fri 22 Mar 85 13:31:24-EST Nope, the DTE hardware will not accept a one-word global byte pointer. DTEQ won't accept one either. Stu Grossman ------- 25-Mar-85 10:14:41-PST,626;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Mon 25 Mar 85 10:14:22-PST Date: Mon 25 Mar 85 13:09:58-EST From: Kevin Paetzold Subject: Re: DTE question To: Vince.Fuller@CMU-CS-C.ARPA cc: tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Vince.Fuller@CMU-CS-C.ARPA" of Fri 22 Mar 85 13:31:17-EST Telephone: 617-467-7430 (DTN: 231-7430) Mail-stop: MRO1-2/L10 i do not know if a owgbp will work but I do know that the dte can not talk to sections other than zero so there is probably not a good reason to use owgbps. ------- 27-Mar-85 10:54:17-PST,4220;000000000001 Return-Path: Received: from BBNA.ARPA by SU-SCORE.ARPA with TCP; Wed 27 Mar 85 10:53:05-PST Date: 27 Mar 1985 13:51-EST Sender: CLYNN@BBNA.ARPA Subject: ADJBP Fails From: CLYNN@BBNA.ARPA To: TOPS-20@SU-SCORE.ARPA Message-ID: <[BBNA.ARPA]27-Mar-85 13:51:41.CLYNN> Has anyone else observed failures of the ADJBP instruction with global one-word 8-bit byte pointers which should generate a final pointer of the form "6000,,", when following a DPB instruction using the same byte pointer, without an intervening memory write? It happens on all three of our TOPS20's, two of which are using microcode version 326. If an instruction which writes into memory is placed between the DPB and ADJBP, it works; it might thus be a cache or microcode bug. It also fails if the byte pointer is in a register. I.e., DPB 4,200 fails but DPB 4,200 works ADJBP 4,200 MOVES 500 ADJBP 4,200 Initial BP Count Final BP Correct BP 540020,,1005 13 570020,,1010 570020,,1011 550020,,1005 13 20,,1012 600020,,1011 (540020,,1012) Below is a log showing the bug from ddt running in section 1. Charlie ------------------------------ TOPS-20 Command processor 5(725)-1 $get adjBP-BUG.EXE.1 ; a saved ddt $i mem 11. pages, Entry vector loc 1,,770000 len 1 Section 0 R, W, E, Private Section 1 R, W, E, Private 1000 ADJBP-BUG.EXE.1 1 R, CW, E 1766 ADJBP-BUG.EXE.1 2 R, CW, E 1770-1777 ADJBP-BUG.EXE.1 3-12 R, E Section 20 R, W, E, Private 20001 ADJBP-BUG.EXE.1 13 R, CW, E $start DDT 1,,76[ 13 ; initial count 1,,200[ 550020,,1005 ; initial byte pointer 20,,1005[ 26000,,0 ; where it points 1,,100/ IBP 200 ; move pointer each time 1,,101/ JFCL 0 1,,102/ MOVE 4,76 ; count for ADJBP 1,,103/ DPB 4,200 ; use the pointer 1,,104/ IBP 4,200 ; ADJBP that fails 1,,105/ JFCL 0 ; end 1,,105$b 100$g $2B>>1,,105/ JFCL 0 4[ 550020,,1010 100$g $2B>>1,,105/ JFCL 0 4[ 560020,,1010 100$g $2B>>1,,105/ JFCL 0 4[ 570020,,1010 100$g $2B>>1,,105/ JFCL 0 4[ 20,,1011 100$g $2B>>1,,105/ JFCL 0 4[ 550020,,1011 100$g $2B>>1,,105/ JFCL 0 4[ 560020,,1011 100$g $2B>>1,,105/ JFCL 0 4[ 570020,,1011 100$g $2B>>1,,105/ JFCL 0 4[ 20,,1012 100$g $2B>>1,,105/ JFCL 0 4[ 550020,,1012 76[ 13 12 ; change count to 12 100$g $2B>>1,,105/ JFCL 0 4[ 550020,,1012 100$g $2B>>1,,105/ JFCL 0 4[ 560020,,1012 100$g $2B>>1,,105/ JFCL 0 4[ 570020,,1012 100$g $2B>>1,,105/ JFCL 0 4[ 20,,1013 100$g $2B>>1,,105/ JFCL 0 4[ 550020,,1013 100$g $2B>>1,,105/ JFCL 0 4[ 560020,,1013 100$g $2B>>1,,105/ JFCL 0 4[ 570020,,1013 100$g $2B>>1,,105/ JFCL 0 4[ 20,,1014 100$g $2B>>1,,105/ JFCL 0 4[ 550020,,1014 76[ 12 377 ; try a big number 100$g $2B>>1,,105/ JFCL 0 4[ 570020,,1111 100$g $2B>>1,,105/ JFCL 0 4[ 20,,1112 100$g $2B>>1,,105/ JFCL 0 4[ 550020,,1112 100$g $2B>>1,,105/ JFCL 0 4[ 560020,,1112 100$g $2B>>1,,105/ JFCL 0 4[ 570020,,1112 100$g $2B>>1,,105/ JFCL 0 4[ 20,,1113 100$g $2B>>1,,105/ JFCL 0 4[ 550020,,1113 100$g $2B>>1,,105/ JFCL 0 4[ 560020,,1113 100$g $2B>>1,,105/ JFCL 0 4[ 570020,,1113 100$g $2B>>1,,105/ JFCL 0 4[ 20,,1114 ; force a memory write 1,,100/ IBP 200 ; move pointer each time 1,,101/ JFCL 0 1,,102/ MOVE 4,76 ; count for ADJBP 1,,103/ DPB 4,200 ; use the pointer 1,,104/ IBP 4,200 MOVES 500 ; force memory write 1,,105/ JFCL 0 ADJBP 4,200 ; ADJBP that works 1,,106/ 0 JFCL .$b 0$2b 100$g $3B>>1,,106/ JFCL 0 4[ 550020,,1114 100$g $3B>>1,,106/ JFCL 0 4[ 560020,,1114 100$g $3B>>1,,106/ JFCL 0 4[ 570020,,1114 100$g $3B>>1,,106/ JFCL 0 4[ 600020,,1114 100$g $3B>>1,,106/ JFCL 0 4[ 550020,,1115 100$g $3B>>1,,106/ JFCL 0 4[ 560020,,1115 100$g $3B>>1,,106/ JFCL 0 4[ 570020,,1115 100$g $3B>>1,,106/ JFCL 0 4[ 600020,,1115 100$g $3B>>1,,106/ JFCL 0 4[ 550020,,1116 ^Z $ 27-Mar-85 13:35:12-PST,599;000000000001 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Wed 27 Mar 85 13:34:22-PST Date: Wed 27 Mar 85 16:29:53-EST From: Kevin Paetzold Subject: Re: ADJBP Fails To: CLYNN@BBNA.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "CLYNN@BBNA.ARPA" of Wed 27 Mar 85 13:51:00-EST Telephone: 617-467-7430 (DTN: 231-7430) Mail-stop: MRO1-2/L10 your microcode is out of date. new microcode should be showing up in the rsx20f that was shipped recently. this is likely to be fixed in that microcode. ------- 28-Mar-85 13:36:43-PST,430;000000000000 Mail-From: BILLW created at 28-Mar-85 13:36:32 Date: Thu 28 Mar 85 13:36:32-PST From: William "Chops" Westfield Subject: new DOVER.MAC To: su-tops-20@SU-SCORE.ARPA Ive modified dover so that the /PAGES switch should work even on press format files. It seems to work, although so far no complicated press files have been sent through it. The new source is SCO:DOVER.MAC.71 BillW ------- 28-Mar-85 21:50:04-PST,1382;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Thu 28 Mar 85 21:47:36-PST Date: Thu 28 Mar 85 22:47:35-MST From: Mark Crispin Subject: PHYH2 bug - ILLGO bug halts To: TOPS-20@SU-SCORE.ARPA Problem: With KWP's patch for systems with 4MW of memory installed in PHYH2, SIMTEL20 (a 512K 2040) gets ILLGO bug halts. Diagnosis: There is a path by which read w/ validity check is called for page 0 which really is a no-op (your homework: find this path). The ILLGO code checks for this path and ignores it. The 4MW patch breaks it. Solution: In PHYH2, replace the following section of code in CKERR2: CAME T3,T4 ;BETTER BE THE SAME JRST [ LDB T1,IRYFCN ;GET THE FUNCTION CODE CAIN T1,IRFRVC ;READ VALIDITY? AOSE T3 ;WAS IT FOR PAGE 0 (SKIP FUNCTION)? BUG(ILLGO) RETSKP] ;HERE IF READ VALIDITY, AND PAGE 0 RETSKP ;NO with this code (note that this also incorporates KWP's patch): ANDX T3,17777 ;CATCH OVERFLOW FROM LAST PHYSICAL MEMORY PAGE CAMN T3,T4 ;BETTER BE THE SAME IFSKP. LOAD T3,LG2DBP,T1 ;GET PAGE NUMBER FROM LOGOUT AGAIN LDB T1,IRYFCN ;GET THE FUNCTION CODE CAIN T1,IRFRVC ;READ VALIDITY? SKIPE T3 ;WAS IT FOR PAGE 0 (SKIP FUNCTION)? BUG(ILLGO) ENDIF. RETSKP ;NO Mark Crispin PANDA PROGRAMMING ------- 29-Mar-85 06:11:37-PST,2111;000000000000 Return-Path: Received: from Ucl-Cs by SU-SCORE.ARPA with TCP; Fri 29 Mar 85 06:09:30-PST Received: from ddxa.ac.uk by 44d.Ucl-Cs.AC.UK via Janet with NIFTP id a005714; 29 Mar 85 14:29 BST Via: DCT; by DUNDEE on Friday, 29-Mar-85 13:02:28-GMT Date: Fri 29 Mar 85 12:56:56-GMT From: Alan Greig Subject: Aborting mapped pages in KSELF To: TOPS-20@su-score.arpa Snail-Mail: Computer Centre / Dundee College of Tech / Dundee / Scotland Sender: Alan%dct@ucl-cs.arpa Midway through version 4 of TOPS20 a change was introduced by an autopatch tape (one of the very few that DEC ever bothered to send us) that caused a lot of our applications programs (and more importantly games) to stop running correctly. The symptom was that any program that shared memory through pmap'd files would randomly crash. I tracked this down to a change in the kill self routine. The addition of the bit pm%abt to a pmap and smap call to be precise. As far as I can remember there was never an spr for which this was a fix for. The comment on the autopatch tape I think said something like "No problem observed but it might be possible for bad pages to be mapped to a file..." The trouble is that when any programs are (for example) emulating a TOPS10 shareable writeable high segment (eg Essex University's MUD) by pmaping in the high segment pages from a file opened with read/write/thaw/don't update disk then if one is killed (say by being logged out or CTRL/C reset) then the monitor drags in the pages back from the original disk copy for every one still sharing these pages. ie all the data is reinitialised. At the time I decided there was no point in submitting an SPR assuming someone else would submit one. Well all this was about 3 years ago and the problem still exists. It only recently came to light again with the increased use of shared file programs here. I've ran versions 4,5 and 5.1 with the following patch installed @get system:monitr.exe ddt ksef0+4/400200,,1000 clnzs1+6/1 29-Mar-85 07:02:41-PST,926;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Fri 29 Mar 85 07:00:47-PST Date: Fri 29 Mar 85 09:53:42-EST From: Kevin Paetzold Subject: Re: PHYH2 bug - ILLGO bug halts To: MRC@SIMTEL20.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Mark Crispin " of Fri 29 Mar 85 00:51:35-EST Telephone: 617-467-7430 (DTN: 231-7430) Mail-stop: MRO1-2/L10 it doesn't matter. the mbox cannot handle channel writes to the last quadword of the 22 bit physical address. parity errors will result and corrupted files also. this is going to become a permanent restriction in the kl and the diagnostics are also being changed accordingly. the easiest patch is to set nmaxpg to be 17,,777776 instead of 17,777777. 4mw is only supported in rel 6.1 at this time. 6.0 only supports 3.0 meg of memory. ------- 29-Mar-85 10:38:01-PST,826;000000000001 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Fri 29 Mar 85 10:35:54-PST Date: 29 Mar 1985 1325-EST From: Alan H. Martin To: CLYNN at BBNA, TOPS-20 at SCORE DTN: 231-4528 Mail-Stop: MR1-2/L14 Office-location: "MR1-2/M8 (By the cat posters)" Subject: Re: ADJBP Fails Message-ID: <"MS10(2124)-1+GLXLIB1(1135)" 12098933210.29.659.23813 at DEC-MARLBORO> The bug is visible in KL microcode V1(326), which is what has been in the field for a while. It is fixed in V1(357), which is in SDC, and is anticipated to be shipping Real Soon Now. V1(357) is for 5.1 monitors; the microcode for later monitors also does not show the bug. Thanks for reporting the problem, we were glad to find that it was fixed. /AHM/THX -------- 29-Mar-85 11:28:15-PST,2570;000000000000 Return-Path: Received: from Ucl-Cs by SU-SCORE.ARPA with TCP; Fri 29 Mar 85 11:26:46-PST Received: from ddxa.ac.uk by 44d.Ucl-Cs.AC.UK via Janet with NIFTP id a006809; 29 Mar 85 17:39 BST Via: DCT; by DUNDEE on Friday, 29-Mar-85 16:31:12-GMT Date: Fri 29 Mar 85 12:56:56-GMT From: Alan Greig Subject: Aborting mapped pages in KSELF To: TOPS-20@su-score.arpa Snail-Mail: Computer Centre / Dundee College of Tech / Dundee / Scotland Sender: Alan%dct@ucl-cs.arpa [The end of this got lost somewhere on the first mailing. Here goes again] Midway through version 4 of TOPS20 a change was introduced by an autopatch tape (one of the very few that DEC ever bothered to send us) that caused a lot of our applications programs (and more importantly games) to stop running correctly. The symptom was that any program that shared memory through pmap'd files would randomly crash. I tracked this down to a change in the kill self routine. The addition of the bit pm%abt to a pmap and smap call to be precise. As far as I can remember there was never an spr for which this was a fix for. The comment on the autopatch tape I think said something like "No problem observed but it might be possible for bad pages to be mapped to a file..." The trouble is that when any programs are (for example) emulating a TOPS10 shareable writeable high segment (eg Essex University's MUD) by pmaping in the high segment pages from a file opened with read/write/thaw/don't update disk then if one is killed (say by being logged out or CTRL/C reset) then the monitor drags in the pages back from the original disk copy for every one still sharing these pages. ie all the data is reinitialised. At the time I decided there was no point in submitting an SPR assuming someone else would submit one. Well all this was about 3 years ago and the problem still exists. It only recently came to light again with the increased use of shared file programs here. I've ran versions 4,5 and 5.1 with the following patch installed @get system:monitr.exe ddt ksef0+4/400200,,1000 clnzs1+6/1 ^Z @save system:monitr which simply turns off the pm%abt bit as tops20 behaved in virgin release 4 and before. I havn't noticed any ill efects but it bothers me slightly that the change was originally made for a reason. Has anyone else experienced this problem or developed a more general soloution, eg abort pages if file not shared, otherwise don't ? Alan ------- 29-Mar-85 11:31:04-PST,2570;000000000000 Return-Path: Received: from Ucl-Cs by SU-SCORE.ARPA with TCP; Fri 29 Mar 85 11:29:33-PST Received: from ddxa.ac.uk by 44d.Ucl-Cs.AC.UK via Janet with NIFTP id a006826; 29 Mar 85 17:40 BST Via: DCT; by DUNDEE on Friday, 29-Mar-85 16:40:22-GMT Date: Fri 29 Mar 85 12:56:56-GMT From: Alan Greig Subject: Aborting mapped pages in KSELF To: TOPS-20@su-score.arpa Snail-Mail: Computer Centre / Dundee College of Tech / Dundee / Scotland Sender: Alan%dct@ucl-cs.arpa [The end of this got lost somewhere on the first mailing. Here goes again] Midway through version 4 of TOPS20 a change was introduced by an autopatch tape (one of the very few that DEC ever bothered to send us) that caused a lot of our applications programs (and more importantly games) to stop running correctly. The symptom was that any program that shared memory through pmap'd files would randomly crash. I tracked this down to a change in the kill self routine. The addition of the bit pm%abt to a pmap and smap call to be precise. As far as I can remember there was never an spr for which this was a fix for. The comment on the autopatch tape I think said something like "No problem observed but it might be possible for bad pages to be mapped to a file..." The trouble is that when any programs are (for example) emulating a TOPS10 shareable writeable high segment (eg Essex University's MUD) by pmaping in the high segment pages from a file opened with read/write/thaw/don't update disk then if one is killed (say by being logged out or CTRL/C reset) then the monitor drags in the pages back from the original disk copy for every one still sharing these pages. ie all the data is reinitialised. At the time I decided there was no point in submitting an SPR assuming someone else would submit one. Well all this was about 3 years ago and the problem still exists. It only recently came to light again with the increased use of shared file programs here. I've ran versions 4,5 and 5.1 with the following patch installed @get system:monitr.exe ddt ksef0+4/400200,,1000 clnzs1+6/1 ^Z @save system:monitr which simply turns off the pm%abt bit as tops20 behaved in virgin release 4 and before. I havn't noticed any ill efects but it bothers me slightly that the change was originally made for a reason. Has anyone else experienced this problem or developed a more general soloution, eg abort pages if file not shared, otherwise don't ? Alan ------- 29-Mar-85 16:38:21-PST,878;000000000000 Return-Path: Received: from EDWARDS-2060.ARPA by SU-SCORE.ARPA with TCP; Fri 29 Mar 85 16:36:31-PST Date: Fri 29 Mar 85 16:37:23-PDT From: DANTE@EDWARDS-2060.ARPA Subject: Request for info on Graduate Programs To: TOPS-20@SU-SCORE.ARPA I am trying to find out what Universities offer graduate programs, preferably in the Computer Science Department, but possibly in the Business Department, in the Management of Computer Resources. Such titles as Data Center Management, Computer Center Management, Data Systems Management, etc. would probably be the type of program I am looking for. Or perhaps there are MS programs in Computer Science with a management bias. I would be particularly grateful for evaluative comments but any information would be appreciated. Please respond directly to my mailbox: Dante@Edwards-2060. ------- 29-Mar-85 17:29:35-PST,775;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Fri 29 Mar 85 17:28:01-PST Date: Fri 29 Mar 85 18:26:52-MST From: Mark Crispin Subject: Re: PHYH2 bug - ILLGO bug halts To: PAETZOLD@DEC-MARLBORO.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Kevin Paetzold " of Fri 29 Mar 85 08:00:48-MST I want to make sure that nobody gets confused by the exchange of messages between KWP and myself. If you want to install the patch for 4MW of memory, you will also need my patch. Given the latest information from Kevin, I think it is probably best not to install the original patch (the ANDI T3,17777) at all, since it is capable of causing ILLGO bughlts. ------- 29-Mar-85 18:00:26-PST,2003;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Fri 29 Mar 85 17:59:45-PST Date: Fri 29 Mar 85 18:59:38-MST From: Mark Crispin Subject: Re: Aborting mapped pages in KSELF To: CCD-ARG%dct@UCL-CS.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Alan Greig " of Fri 29 Mar 85 13:19:56-MST Alan - The PM%ABT bit only makes a difference if OF%DUD is set. What it is trying to do is this: Suppose you have an application program which manipulates a database file by pmapping its pages into memory and then manipulating memory. To be safe, it opens the file OF%DUD because if the system crashes in the middle of all of this an inconsistant copy will be left on this disk, with some pages updated and some not. An UFPGS% is done when things are in a good state, and the application tells the monitor to update all the necessary pages. MM is one of many programs which works this way. Now, suppose you run such a program, and for reasons known only to you you CTRL/C out and reset the fork. If the application was in the middle of some critical update the pages would normally be written to the disk, causing a disaster. MM tries to avoid this problem by disabling CTRL/C interrupts during the EXPUNGE and "replace message" routines which move messages around (as opposed to commands such as DELETE which merely update a bit in place). Many programs don't have CTRL/C traps, and even more are so critical that even that isn't adequate protection. So the monitor tries to help by aborting pages which were OF%DUD. It isn't clear to me what the right thing to do in this case. The problem is that I can think of cases where aborting the pages is the right thing; consider a shared database where interactions are done via ENQ%. My suggest would be to do a UFPGS% at the end of each major interaction, and use ENQ% if you aren't already. ------- 30-Mar-85 05:56:05-PST,779;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Sat 30 Mar 85 05:52:04-PST Date: Sat 30 Mar 85 08:45:25-EST From: Kevin Paetzold Subject: Re: PHYH2 bug - ILLGO bug halts To: MRC@SIMTEL20.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Mark Crispin " of Fri 29 Mar 85 20:26:30-EST Telephone: 617-467-7430 (DTN: 231-7430) Mail-stop: MRO1-2/L10 you should not install any of the 4.0 meg patches. it is not a good idea to fix problems that you do not have. 4.0 meg is not supported by tops-20 at this time unless you are running 6.1. in addition to software problems there are cpu problems in the mbox and channel/rh20 problems to overcome. ------- 30-Mar-85 10:27:55-PST,1704;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Sat 30 Mar 85 10:26:43-PST Date: 30 Mar 1985 1321-EST From: Tom Blinn To: MRC at SIMTEL20, CCD-ARG%dct at UCL-CS cc: TOPS-20 at SU-SCORE Subject: Re: Aborting mapped pages in KSELF Message-ID: <"MS10(2124)-1+GLXLIB1(1135)" 12099194611.18.275.28529 at DEC-MARLBORO> Regarding: Message from Mark Crispin of 29-Mar-85 2101-EST Mark, you've done a very good job of clarifying the reasons for TOPS-20's behavior when a program that has a file opened for thawed update with OF%DUD set gets into trouble when the file gets closed/aborted and the user expects the file to contain the modified data. In this case, TOPS-20 is doing the right thing. The problem arises due to the applications attempting to mimic a TOPS-10 feature (shared writable high segments, hence shared memory among independent jobs) by using TOPS-20 file system features in a way that does not give identically the same results. If no-one opens the file OF%DUD (since it really doesn't matter if the disk copy of the file gets updated, other than the increase in the disk and swapping traffic, for this particular case), then when someone gets blown away (e.g., by being reset after ^C or by being logged out), TOPS-20 won't bother to re-set the in-memory file pages (still shared by other users of the file) from disk. For this particular case, changing to use UFPGS% will probably be less good, since that actually FORCES the file pages out to disk. Simply letting DDMP do it should be more efficient, overall. Regards, Tom -------- 31-Mar-85 02:42:07-PST,1794;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Sun 31 Mar 85 02:41:56-PST Date: Sun 31 Mar 85 02:42:32-PST From: Kirk Lougheed Subject: Fix for TCP-related system hangs To: TOPS-20@SU-SCORE.ARPA Problem: Internet system hangs, typically with many fork lock timeout bugchks. Diagnosis: The fork lock timeouts are being generated every time a fork does a RESET%. Part of the RESET% code tries to abort JCN's. To do this, the process must obtain the TCB hash lock (TCBHLK). The hash lock appears to be overly incremented, hence it is never "released" so that other processes can have their turn. It turns out that the Internet background fork is one who owns the lock. If you look closely at a dump of a hung system, the Internet fork is busily chasing down a infinite loop of zero pointers on page zero of the Internet section. It appears that someone called NQ with a nil item pointer. This piece of detective work comes from Chris Maio of Columbia University. Next step is to insert a debugging bughlt at NQ to catch the culprit. Tracing through the stack, we discover that the BUFHNT routine in TCPTCP.MAC sets up a pointer to the TCB's receive buffer without checking if that buffer exists. Elsewhere in TCPTCP the code does make such checks. We have found our nil pointer. The fix: Add one line to TCPTCP.MAC as follows: BUFHNT:: SAVEAC MOVE TCB,T1 ; put TCB into correct AC SETZ T1, ; no special flags LOAD BFR,TRCB,(TCB) ; get the receive buffer SETZRO TRCB,(TCB) ; no more receive buffer IFN STANSW,< JUMPE BFR,R ; return now if no receive buffer >;IFN STANSW CALL USRBFF ; user buffer filled RET ; and return to caller ------- 31-Mar-85 16:38:30-PST,611;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Sun 31 Mar 85 16:38:22-PST Date: Sun 31 Mar 85 16:38:58-PST From: Kirk Lougheed Subject: SPEAR and 6.X To: su-tops-20@SU-SCORE.ARPA In case people running 6.0 and 6.1 systems haven't yet noticed, the Release 5.X SPEAR doesn't work properly on new ERROR.SYS files. Rather than sprinkle SPEAR support files throughout PS:, I've put them all in PS: and added that directory to the SYS: search path. There are about 1600 pages and 38 some files. Kirk ------- 31-Mar-85 23:44:21-PST,682;000000000001 Return-Path: Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Sun 31 Mar 85 23:43:53-PST Date: Sun 31 Mar 85 23:43:37-PST From: David Roode Subject: Bug in dumper To: TOPS-20@SU-SCORE.ARPA cc: Ian@SRI-NIC.ARPA, Vivian@SRI-NIC.ARPA Location: EJ286 Phone: (415) 859-2774 (Sorry no fix yet.) If DUMPER has just been used to do a RETRIEVE, and then a SAVE/MIGRATE follows, DUMPER finds itself in a strange state where it thinks it need not ask for tape id information but just proceeds to do the migration. Files so migrated have bad tape information in their FDB's. Has anyone seen a fix for this yet? ------- 1-Apr-85 11:16:45-PST,617;000000000000 Return-Path: Received: from CMU-CC-TE by SU-SCORE.ARPA with TCP; Mon 1 Apr 85 11:16:11-PST Date: Mon 1 Apr 85 14:13:29-EST From: Eric Crane Subject: DECnet monitor To: Tops-20@SU-SCORE.ARPA Office: Ucc 130 x3568 Secretary: x2638 I have been asked to check if any of you might know of any programs for checking the status of DECnet links. What we would like to do is have a program that wakes up every so often and checks the ability to connect to other nodes. If a connection fails it should give some sort of diagnostic. - Thanks Eric Crane ------- 2-Apr-85 12:06:38-PST,600;000000000000 Return-Path: Received: from DREA-XX.ARPA by SU-SCORE.ARPA with TCP; Tue 2 Apr 85 12:06:17-PST Date: Tue 2 Apr 85 15:51:04-AST From: Peter Gergely Subject: Separating "Digest" style messages To: tops20@SU-SCORE.ARPA Has anyone got any software for either MM or BBOARD that can "Undigestify" messages that are in Digest Format. Something in the order of the "D" command for the UNIX READNEWS would be nice (It presents digests in separate messages allowing individual selection, without affection the original message). - Peter ------- 2-Apr-85 13:47:06-PST,942;000000000000 Return-Path: Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Tue 2 Apr 85 13:46:32-PST Received: ID ; Tue 2 Apr 85 16:38:33-EST Date: Tue 2 Apr 85 16:38:26-EST From: Vince.Fuller@CMU-CS-C.ARPA Subject: FTPSRT bugfix To: tops-20@SU-SCORE.ARPA It has been suggested that I post this... There is a longstanding bug in FTPSRT that causes TYPE I/TYPE L 36 (non-paged) retrieves to send extra nulls at the end of a transfer (this is only noticiable for TOPS-10/ITS sites, since TOPS-20/TENEX sites usually use paged mode). The problem is that the file byte count is not being adjusted to account for the 36-bit transfer mode. The fix is rather trivial and may be found in the most recent version of FTPSRT in PS: on CMU-CS-C (along with some other changes, among them some, shall we say, "unique" debugging code needed to debug an active data transfer). --Vince ------- 3-Apr-85 17:17:46-PST,1805;000000000000 Return-Path: Received: from DREA-XX.ARPA by SU-SCORE.ARPA with TCP; Wed 3 Apr 85 17:16:37-PST Date: Wed 3 Apr 85 21:16:32-AST From: Peter Gergely Subject: BBOARD.MAC version's (~40 lines long) To: TOPS20@SU-SCORE.ARPA Sorry to bother the whole list with this request, but... About two weeks, I announced some changes to BBOARD that we had made here at DREA. As ours was based on edit 67 of Rutgers BBOARD, I am wondering if anyone has a newer version of BBOARD.MAC that has additional features. Features that I would like to see are (the numbers are not priorities): 1. Wildcard bulletin boards (i.e. BBOARD *, would get all BBD:*.TXT files that have corresponding .DATA files, with an error skip if no .DATA file). I have this change but based on edit 67 as mentioned. 2. The subject on a separate line if LENGTH(date + from + subject) is greater than line width. We also have this for a rigid line width of 72. 3. A switch to allow me to check if any bulletin board has new messages. 4. Common Database with MM. (If anyone has this, please announce it). 5. A facility to mark all messages as being seen. Something like the readnews "K" command in Unix. 6. Some method of "undigestifying" digest message, so that the individual messages act as a bulletin board. This is similar to the readnews "d" command in Unix. 7. Just about anything else that would ease reading the bulletin boards (maybe Unix style more processing). I would appreciate hearing from anyone who may have some or all of these. Please contact me for more information. I will be more than happy to help with BBOARD on my spare time in evenings, but cannot afford to take over maintenance. - Peter ------- 4-Apr-85 06:31:11-PST,367;000000000000 Return-Path: Received: from RADC-TOPS20.ARPA by SU-SCORE.ARPA with TCP; Thu 4 Apr 85 06:26:18-PST Date: Thu 4 Apr 85 09:26:05-EST From: Donna Lynch Subject: plot To: tops-20@SU-SCORE.ARPA cc: admin@RADC-TOPS20.ARPA Where can I get PLOT10 or PLOT20? Is it available on the net? What is the cost? ------- 5-Apr-85 22:08:29-PST,575;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Fri 5 Apr 85 22:06:04-PST Date: Fri 5 Apr 85 23:05:58-MST From: Mark Crispin Subject: GTJFN% strangeness To: TOPS-20@SU-SCORE.ARPA Is it a bug or a feature that doing a GTJFN% returns a GJFX20 error when: . an explicit generation number is given in the string . the generation is deleted . GJ%DEL isn't specified I don't think GJFX20 should be returned unless GJ%OLD is set. If it isn't, it should supercede the old version. ------- 7-Apr-85 01:19:27-PST,470;000000000000 Return-Path: Received: from CU20B.ARPA by SU-SCORE.ARPA with TCP; Sun 7 Apr 85 01:17:25-PST Date: Sat 6 Apr 85 22:00:38-EST From: Ken Rossman Subject: Source code for CHANGE program To: TOPS-20@SU-SCORE.ARPA Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 Does anyone out there know where I can get my hands on the source to CHANGE (an old character set converter program)? /Ken ------- 9-Apr-85 12:26:44-PST,995;000000000000 Return-Path: <@MIT-MULTICS.ARPA:Markku_Suni_Univ._of_Turku@QZCOM.MAILNET> Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Tue 9 Apr 85 12:26:07-PST Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2659378936646793@MIT-MULTICS.ARPA>; 09 Apr 1985 15:22:16 est Date: 09 Apr 85 09:06 +0100 From: Markku_Suni_Univ._of_Turku%QZCOM.MAILNET@MIT-MULTICS.ARPA Reply-to: Markku_Suni_Univ._of_Turku%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, Vince.Fuller@CMU-CS-C.ARPA Subject: J0NRUN during system shutdown? Message-ID: <99297@QZCOM> In-Reply-To: <87821@QZCOM> We here at University of Turku (Dec-2060, monitor 5.1, PCL-EXEC) have received J0NRUN during shutdown but so irregularly that I have not been able to notice any logic in it. 9-Apr-85 12:56:49-PST,1720;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Tue 9 Apr 85 12:54:17-PST Date: Tue 9 Apr 85 13:54:16-MST From: Mark Crispin Subject: OPOPAC bughlts To: TOPS-20@SU-SCORE.ARPA All around the ol' DEC 20 The AC blocks get pushed and popped, Sometimes it goes just a little to far Pop! Goes the system %DECSYSTEM-20 NOT RUNNING Folks, we just got an OPOPAC bughlt here. The same problem happened at Score a number of times as well. Each time it's happened, it's been an FTP server job (typically ANONYMOUS) and the UPDL has traces of TTY input code. However, it no longer has JSYS context: UPDL/ T1,SLBIN#+4 UPDL+1/ -372,,UPDL+5 UPDL+2/ .JBBLT+13,,TCITST UPDL+3/ T1,,.TRRET+1 UPDL+4/ CAIA BYTIN1+10 This UPDL wouldn't be all that bad looking if it was higher up on the stack; clearly the TRVAR return to UDPL+5 from UPDL+1 is bogus, but would be alright if it happened at, say, UPDL+10. The other less obvious bogon is that in UPDL+4 there is a section 0 PC. To me this implicates PSI service; I suspect some PSI came in while TVT BIN%'s were happening and dismissed back to here in section 0. In the process, it also managed to nuke the stack. The OPOPAC follows fairly straightforwardly from here once you recognize how MPP/MRETN/etc. will interact in this case. Frank Wancho reports that this problem happens in more-or-less vanilla DEC monitors too. The monitor we're running now has all the known fixes to JOBCOF (e.g. saving all AC's including CX, not to mention dismissing back to section 1). Has anybody else seen this problem, or better yet, has anybody already come up with a fix for it? ------- 9-Apr-85 13:14:27-PST,872;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Tue 9 Apr 85 13:12:45-PST Date: Tue 9 Apr 85 14:12:00-MST From: Mark Crispin Subject: Re: J0NRUN during system shutdown? To: Markku_Suni_Univ._of_Turku%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA cc: TOPS-20_experts_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA, TOPS-20@SU-SCORE.ARPA, Vince.Fuller@CMU-CS-C.ARPA In-Reply-To: Message from "Markku_Suni_Univ._of_Turku%QZCOM.MAILNET@MIT-MULTICS.ARPA" of Tue 9 Apr 85 09:06:00-MST Examine the crash dump, and in particular location FKSTAT. That will give you the scheduler test that fork 0 is blocked on. 9 out of 10 times it will turn out to be hung in TCOTST on a terminal line, often the CTY if the operator has typed CTRL/S on it. ------- 9-Apr-85 23:30:30-PST,1362;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Tue 9 Apr 85 23:29:11-PST Date: Wed 10 Apr 85 00:28:55-MST From: Mark Crispin Subject: IAC doubling: the saga continues To: TOPS-20@SU-SCORE.ARPA There have been several messages about a correct implementation of IAC doubling on TVT's to prevent a binary '377 character being output causing spurious interpretation of network protocol. Unfortunately, none of the previously published patches are perfect. Typically, the problems are paths which can cause a non-doubled '377 to go through or paths which could cause many '377s to go through. This solution seems to resolve these problems. In TTYSRV, rewrite TCOU6 to look like: TCOU6: CAIE T1,377 ;OUTPUT BYTE = IAC? JRST TCOU6B TDCALL D,<> ;YES, DO TCOU6A TWICE IF A TVT JRST TCOU6B TCOU6A: SAVEAC TCOU6B: LOAD 3,TOMAX,(2) ;CAPACITY OF OUTPUT BUFFERS ...etc... At TCOU5-1, replace JRST TCOU3 with JRST TCOU6B In TTANDV, rewrite TCOBN to look like: TCOBN: SAVELN ;SAVE LINE NUMBER TXZE T1,.LHALF ;WANTS IT LITERALLY? JRST TCOU6B ;YES, NO IAC DOUBLING PLEASE ANDI T1,377 ;8 BITS OF CHARACTER CALL TCOU6 ;GO OUTPUT THE CHARACTER WITHOUT ADDING ; PARITY OR DOING LINKS RET ;RETURN ------- 11-Apr-85 10:15:14-PST,500;000000000000 Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Thu 11 Apr 85 10:14:36-PST Date: 11 Apr 85 13:13:52 EST From: Rob Liebschutz Subject: Re: OPOPAC bughlts To: MRC@SIMTEL20.ARPA, TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Mark Crispin " of 9 Apr 85 15:54:16 EST I can recall seeing this problem once (this past Monday) on our student machine. We have not looked into it at all though. ------- 11-Apr-85 13:39:14-PST,2189;000000000000 Return-Path: Received: from DREA-XX.ARPA by SU-SCORE.ARPA with TCP; Thu 11 Apr 85 13:37:57-PST Date: Thu 11 Apr 85 17:37:47-AST From: Peter Gergely Subject: BBOARD and MM share a common database!!! (~45 lines) To: TOPS20@SU-SCORE.ARPA -Thanks to all who offered me a BBOARD.MAC to work. I got 3 independent versions, all having good and bad features. There is still a lot that can be done. -Thanks to Mark Crispin and Steve Berlin for explaining the .IDX format to me. Now: I have edited the version of BBOARD received from SIERRA (thanks Kirk), as it was the easiest to merge with our changes, to include the following features (all have [PJG] in the comments): - Separate subject line on long headers - Wildcard bulletin board scanning - X command to exit BBOARD reading immediately - /SCROLL-MORE (allows UNIX-style more, SIERRA already had a /MORE built in - Sharing of the database with MM. This is done by using MM's .IDX file, and adding the extra information used by BBOARD at another page location unreached by MM. MM remains untouched, with BBOARD using the message read date the same as MM. - Some cleanup of the flags in BBOARD, and other things Caveat: I haven't written a BBCHNG program to merge the .DATA information with that of the .IDX, but will be glad to suggest how to do it. Availability: The files BBOARD.MAC, and CHKBBD.MAC (see below) are available at DREA-XX via ANONYMOUS FTP. I would appreciate greatly if you drop me a note saying who picked it up, so I can advise you of BUGS or Changes. CHKBBD: This program reads an individual .IDX file, and (if WOPR) resets the read date and time for files only, and non-existent directories. It will also display the read and write date of the BBOARD. It does not touch the .IDX message map. It is strictly for use with the above mentioned BBOARD. We run it nightly so that new users don't get left-overs from somebody before them. I did not know of the existence of the BBWHO program at the time of writing this years ago. Peter J. Gergely ------- 11-Apr-85 15:40:25-PST,410;000000000000 Return-Path: Received: from DREA-XX.ARPA by SU-SCORE.ARPA with TCP; Thu 11 Apr 85 15:37:26-PST Date: Thu 11 Apr 85 19:37:17-AST From: Peter Gergely Subject: BBOARD at DREA To: TOPS20@SU-SCORE.ARPA Please make sure that you get BBOARD.MAC.101 if and/or when you pick it up. Please send me mail if you get a copy though. - Peter ------- 12-Apr-85 09:47:36-PST,962;000000000000 Return-Path: Received: from DREA-XX.ARPA by SU-SCORE.ARPA with TCP; Fri 12 Apr 85 09:46:38-PST Date: Fri 12 Apr 85 13:46:13-AST From: Peter Gergely Subject: Bug in MMAIL.EMACS.91 To: tops20@SU-SCORE.ARPA [Symptom] Editing (E command) a message marked by an "N" while in MMAIL DIRED puts you into REPLY mode on some message. Upon exit the message is sent off. It goes as a reply to the last successful message that you edited while in DIRED. [Problem] Message number is not being interpreted on a line containin an "N". [Cure] At !& MMAIL DIRED Type:! and !& MMAIL DIRED Reply:! change the code RUFAD_ on the first line to NRUFAD_, causing the flag skip to go over the N flag, and get to the message number. [[[Aside: If you have problems with the bottom window scrolling (i.e no overlap, or jumps of many lines on a CTRL-V), contact me as I have a solution]]] - Peter ------- 12-Apr-85 09:58:16-PST,1344;000000000000 Return-Path: Received: from BBNG.ARPA by SU-SCORE.ARPA with TCP; Fri 12 Apr 85 09:51:34-PST Date: Fri 12 Apr 85 12:51:30-EST From: Dan Tappan Subject: TCP FTP speed To: tops-20@SU-SCORE.ARPA I recently connected up one of our 20's to an ethernet and did a few speed comparisons with some of the other hosts on the cable (VMS Vaxes running Wollongong TCP and 4.2/Ultrix vaxes). I was shocked to discover that, while the VMS machines could do up to 310KBitsPS between themselves, the best I could get to the 20 was 60-90KBPS (depending on what processor I put in the front-end connecting it to the ether). I did some poking around and, to make a long story short, I've managed - largely by twiddling buffer sizes in the user level FTP code - to improve things enough that I now see transfer rates up to 382KBPS. At this point I've run out of machines fast enough to force a higher data rate - possibly until I get another 20 connected. The reason I mention this is that there is a generally accepted truism that "TOPS20 TCP is slow" (which I have been guilty of myself). Apparently, even at this date, a little tuning can make a big difference. The changes were to the "BBN interface" FTP code and are available if anyone wants them. Actual mileage may vary. Dan ------- 12-Apr-85 16:50:51-PST,511;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Fri 12 Apr 85 16:49:22-PST Date: Fri 12 Apr 85 14:01:18-PST From: Kirk Lougheed Subject: BBN FTP To: su-tops-20@SU-SCORE.ARPA cc: bug-ftp@SU-SIERRA.ARPA The modified version of BBN's TCP FTP is on PS: on Sierra. I brought Dan Tappan's changes over this afternoon. Hopefully there are some clues in the user code as to how to speed up TCPJFN.MAC. Kirk ------- 12-Apr-85 23:53:31-PST,472;000000000000 Return-Path: Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Fri 12 Apr 85 23:53:12-PST Received: ID ; Sat 13 Apr 85 02:23:28-EST Date: Fri 12 Apr 85 18:01:27-EST From: Vince.Fuller@CMU-CS-C.ARPA Subject: Re: TCP FTP speed To: TOPS-20@SU-SCORE.ARPA I have made Dan's changes to the versions of FTP and FTPSRT that I maintain. Mucho thanks, Dan, for the changes - they really help around here! --Vince ------- 15-Apr-85 01:49:45-PST,710;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Mon 15 Apr 85 01:48:20-PST Date: Mon 15 Apr 85 02:48:32-MST From: Mark Crispin Subject: altering value of TTSIZ To: TOPS-20@SU-SCORE.ARPA Has anybody tried upping the value of TTSIZ (currently 40) to, say, 100? The comment about it having to be a power of 4 is obviously wrong since 40 isn't a power of 4, but 100 is. If TTSIZ is 100 this would allow for 252. (decimal) bytes in a TTY buffer instead of the existing limit of 124. We would like to do this in an attempt to improve MODEM etc. performance, although it should improve TTY output performance as well. ------- 15-Apr-85 12:18:26-PST,1565;000000000000 Return-Path: Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Mon 15 Apr 85 12:17:15-PST Date: Mon 15 Apr 85 12:17:27-PST From: Mark Crispin Subject: performance measuring/monitoring To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869 Phone: 1 (415) 968-1052 What performance measuring/monitoring tools are currently in use out there? What I am looking for is something which would enable the performance evaluator to draw somewhat more scientific conclusions than can be obtained from SYSDPY (which is a good seat-of-the-pants tool, but less useful for getting quantitative data). I would also be interested in any tools which read WATCH output and digest it into more human-readable information. What would be really great is a tool which spots trends in WATCH output and graphs those trends as a function of some other trend (e.g. time, load, etc.) Another tool I would be interested in is one which measures a particular program's impact upon the system. For example, we know that as an editor, EMACS is a CPU hog and that Interlisp generates zillions of page faults. I'm looking for something which can more precisely measure this sort of impact. So much for wheel reinvention abatement. I'm also interested in people's comments about their past experiences in performance measuring; also in what luck they have had, if any, in tuning the class scheduler. -- Mark -- (wearer of many hats) ------- 15-Apr-85 12:33:55-PST,794;000000000000 Return-Path: Received: from BBNA.ARPA by SU-SCORE.ARPA with TCP; Mon 15 Apr 85 12:33:39-PST Date: 15 Apr 1985 15:33-EST Sender: CLYNN@BBNA.ARPA Subject: Re: altering value of TTSIZ From: CLYNN@BBNA.ARPA To: MRC@SIMTEL20.ARPA Cc: TOPS-20@SU-SCORE.ARPA Message-ID: <[BBNA.ARPA]15-Apr-85 15:33:50.CLYNN> In-Reply-To: The message of Mon 15 Apr 85 02:48:32-MST from Mark Crispin BBN has been running with TTSIZ equal to 100 for a long time. I do not really have hard data from the days when it was 40. I seem to remember that 100 made screen updates in EMACS a lot better. Probing the local hosts shows that about half of the packets which are not echos of one or two characters contain enough bytes to be using additional space. Charlie 15-Apr-85 12:51:48-PST,690;000000000000 Return-Path: Received: from UTEXAS-20.ARPA by SU-SCORE.ARPA with TCP; Mon 15 Apr 85 12:50:59-PST Date: Mon 15 Apr 85 14:49:47-CST From: Clive Dawson Subject: Re: performance measuring/monitoring To: Crispin@SUMEX-AIM.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Mark Crispin " of Mon 15 Apr 85 14:38:10-CST Although I have no direct experience with it, I've heard good reports regarding the AMAR-20 system that DEC markets. (There's a blurb in the March 1 Dispatch about it.) Perhaps someone out there is in a better position to give a testimonial or a condemnation? CLive ------- 15-Apr-85 14:42:24-PST,842;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Mon 15 Apr 85 14:41:52-PST Date: Mon 15 Apr 85 17:41:02-EST From: Kevin Paetzold Subject: Re: performance measuring/monitoring To: Crispin@SUMEX-AIM.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Mark Crispin " of Mon 15 Apr 85 15:22:57-EST Telephone: 617-467-7430 (DTN: 231-7430) Mail-stop: MRO1-2/L10 any performance measuring effort based on release 5.1/6.0 is almost certainly a waste of time. release 6.1 has had major and extensive changes in the performance area. the bottlenecks you find in pre 6.1 monitors will be different than the ones in 6.1. I am talking about monitor performance and not the performance of individual programs. ------- 17-Apr-85 14:43:03-PST,551;000000000000 Return-Path: Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Wed 17 Apr 85 14:42:55-PST Date: Wed 17 Apr 85 14:42:52-PST From: Andrew Sweer Subject: MERLIN To: su-tops-20@SU-SCORE.ARPA Who knows where the most recent sources for MERLIN are? We discovered a problem here dealing with the long file names created as an offshoot of subdirectories. The most recent sources I found, along with fixes and a new .EXE file can be found at SUMEX in SS:MERLIN.*. Andy ------- 18-Apr-85 00:20:13-PST,542;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Thu 18 Apr 85 00:18:42-PST Date: Thu 18 Apr 85 00:18:09-PST From: Kirk Lougheed Subject: Re: MERLIN To: SWEER@SUMEX-AIM.ARPA cc: su-tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Andrew Sweer " of Wed 17 Apr 85 22:25:30-PST I have recent sources to MERLIN on PS:MERLIN.MAC. Whatshisname at DREA has made a number of bugfixes in the past few weeks..... Kirk ------- 18-Apr-85 10:14:51-PST,791;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Thu 18 Apr 85 10:13:16-PST Date: 18 Apr 1985 1311-EST From: B.Eiben LCG Ext 617-467-4431 To: tops-20 at SU-SCORE Subject: A "minor" nitbit regarding protections Message-ID: <"MS10(2124)-1+GLXLIB1(1135)" 12104173665.36.249.136191 at DEC-MARLBORO> I had the "fun" to "secure" halfways a public account against NITs - changing LOGIN.CMD from their "standard" settings -- typically these guys just used COPY TTY: LOGIN.CMD to create an "empty" one. After some thought we came up with a solution: Use highest possible generation-Nr AND set protection to 500000 - this allows to generate a "sticky" CMD-file. i.e. LOGIN.CMD.131071;P500000 -------- 18-Apr-85 10:51:31-PST,1067;000000000000 Return-Path: Received: from CU20B.ARPA by SU-SCORE.ARPA with TCP; Thu 18 Apr 85 10:50:32-PST Date: Thu 18 Apr 85 13:50:31-EST From: Ittai Hershman Subject: Re: A "minor" nitbit regarding protections To: EIBEN@DEC-MARLBORO.ARPA cc: tops-20@SU-SCORE.ARPA In-Reply-To: Message from "B.Eiben LCG Ext 617-467-4431 " of Thu 18 Apr 85 13:11:00-EST Your method doesn't quite work since, if the generation number is known, the user can change the protection then delete it. An improvement is to set the file to the highest generation, then turn on the "undeletable" flag in the file's fdb -- FB%NDL (word 1, bit 18) -- which was added in version 5. There is still a very small window in the exec between the re-allowing of interrupts after LOGIN% has completed and the LOGIN.CMD file is executed. If you are really paranoid, you can delay the re-allowing of interrupts until after the LOGIN.CMD has been processed; but that is not recommended for obvious reasons. -Ittai ------- 19-Apr-85 07:00:01-PST,784;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Fri 19 Apr 85 06:57:38-PST Date: 19 Apr 1985 0957-EST From: B.Eiben LCG Ext 617-467-4431 To: TOPS-20 at SU-SCORE cc: lcg.Kramer at DEC-MARLBORO Subject: SEAL-20 available from here Message-ID: <"MS10(2124)-1+GLXLIB1(1135)" 12104400512.39.249.41819 at DEC-MARLBORO> ..via ANONYMOUS FTP from DEMO:[SEAL-20]*.* The software is available on an "AS IS" basis - I would like to request however that everybody, who plans to use it , drops me a small note - and [in the same vain] BUG-fixes [its only software written by humans] and/or enhancements find their way back here too - so that I can notify everybody of changes in state. Bernie -------- 19-Apr-85 13:38:12-PST,1087;000000000000 Mail-From: MRC created at 19-Apr-85 13:37:31 Return-Path: Received: from WISCVM.ARPA by SU-SCORE.ARPA with TCP; Fri 19 Apr 85 11:06:27-PST Received: from (MAILER)UDCVM.BITNET by WISCVM.ARPA on 04/19/85 at 13:03:52 CST Return-path: MHICKEY%UDCVM.BITNET@WISCVM.ARPA Received: by UDCVM (Mailer X1.20) id 0644; Fri, 19 Apr 85 13:44:24 EST Date: 19 April 1985, 13:38:17 EST From: MHICKEY%UDCVM.BITNET@WISCVM.ARPA To: ADMIN.MRC@SU-SCORE.arpa ReSent-Date: Fri 19 Apr 85 13:37:31-PST ReSent-From: Mark Crispin ReSent-To: TOPS-20@SU-SCORE.ARPA Greetings, My name is Mike Hickey from the Univ. of the District of Columbia. We have a DEC 2060 (serial 2416) and I am the Systems Programmer for it. Would it be possible if I could join the TOPS-20 group? Thanks in advance for your assistance. This note is coming from a 4341 we also have. Needless to say the first question I would have for the group is direction on how to interface BITNET to our TOPS via the 2780/3780 emulation software. Once again thanks. 19-Apr-85 17:13:02-PST,970;000000000000 Return-Path: Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Fri 19 Apr 85 17:12:53-PST Date: Fri 19 Apr 85 17:13:04-PST From: Mark Crispin Subject: Galaxy bug? To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869 Phone: 1 (415) 968-1052 I just encountered the following strange behavior. If I'm right, it's a serious bug in Galaxy. I don't know if the problem is local to Stanford (local to SUMEX?) or is all over. I am doing plots. I spool my output file with the /DELETE switch. I then generate a subsequent plot with the same file name, but with a greater generation. The previous plot is deleted when I make the new generation, but it still comes out provided it had started printing already when I wrote the new generation. But then, when it finishes printing, it deletes and EXPUNGES the new generation I just wrote! ------- 19-Apr-85 18:29:15-PST,8555;000000000000 Return-Path: Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Fri 19 Apr 85 18:28:41-PST Date: Fri 19 Apr 85 18:28:49-PST From: Mark Crispin Subject: WATCH data interpretation tool To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869 Phone: 1 (415) 968-1052 Enclosed is a little program which can be used to interpret WATCH "data records". Its output is input for the CMU "Plot" program (courtesy of Ivor.Durham@CMUA). You edit in an appropriate WRITE statement in the data record reading section to record the data points you want; you also edit in a FORMAT statement giving the title of the sample on the Y grid. This program, RDSTAT.FOR, automatically scales the plot to dates or time depending upon the input range given; if more than a day it marks by days. It attempts to grade the date/time axis (X) as reasonably as it can. Since I'm using an Imagen IMPRINT-10 printer in Tektronix mode I limited it to 8 date/time labels. I've only tested it for Type 6 WATCH records so far, but have gotten a lot of good data out of it. If you're wondering why I'm using alphanumeric interpretation instead of numeric, it's because in some cases certain values overflow the fields WATCH allocates. That poisons the data if you're reading it numerically in Fortran. Since I'm not doing any data interpretation yet in the RDSTAT program this is quite alright. There isn't anything wonderful in this program; it'll just save somebody some time if they have to do the same thing I've had to. -- Mark -- C Program to read WATCH data records and extract useful information C Mark Crispin INTEGER TIME, INTRVL, MINTAD, MAXTAD INTEGER MONTH1, DAY1, YEAR1, HOUR1, MINUT1, SECON1 REAL DATE, FDATE, TAD, BDATE, EDATE, ATAD, ADATE, ATIME C Record header declarations INTEGER RECTYP, RECSEQ, MONTH, DAY, YEAR, HOUR, MINUTE, SECOND REAL*8 INTVL, NJOBS C Type 1 declarations REAL*8 USED, IDLE, SWPW, SKED, SUSE, TCOR, FILW, BGND, NTRP, NCOR, +AJBL, NREM, TRAP, NRUN, NBAL, NWSM, BSWT, DSKR, DSKW, SWPR, NLOD, +CTXS, UPGS, FPGS, DMRD, DMWR, DKRD, DKWR, TTIN, TTOU, WAKE, TTCC, +TDIO, RPQS, GCCW, XGCW, KNOB, QDIST(10), NQDIST C Type 2 declarations REAL*8 LDAV, HQLDAV, LQLDAV, CLSNUM(32), CLSSHR(32), CLSUTL(32), +CLSLAV(32), CLSHQL(32), CLSLQL(32), NCLOAD C Type 3 declarations REAL*8 JOB, TTY, USER(2), PROG, ERT, EDEMD, EUSED, EGRDY, EBRDY, +ESWPR, EDSKR, EDSKW, ERPQW, EOTHR, EIMEM, ENLD, ENRSP, ESR, EWSS, +EUPGS, ESWPR1, EDSKR1, ETPF, EIFA C Type 4 declarations REAL*8 DELTAR, NRT, JU, CSH C Type 5 declarations REAL*8, HIT, MISSF, MISSN, TOTRC, LOKPGS, SHRPGS, AVAMEM, +NRUNMN, NRUNMX, SMNRMN, SMNRMX, NRPLMN, NRPLMX, SYMDMD, SWPRAT, +ACTSWR, MEMUTL, AVWSSZ, AVCPUT, THNKTM, DSKCHN(15), DSKUNT(15), +SEEKS(15), READS(15), WRITES(15), DSKNAM(15), DSKNUM(15), NDSKIO C Type 6 declarations REAL*8 TUSED, TSWPW, TSKED, TCTXS, TWAKE, TTDIO, TNRUN, TNWSM, +TNLOD, TUSED2, TGRDY, TBRDY, TSWPR, TDSKR, TDSKW, TRPQW, TOTHR, +TIMEM, TNLD, TNRSP, TRESP, TSR DATA ADATE, ATIME/'Date','Time'/ C Start of program C Initialization MINTAD=99999 MAXTAD=0 C Open files OPEN (UNIT=20,FILE='WATCH',ACCESS='SEQIN') OPEN (UNIT=21,FILE='PLOT.CMD',ACCESS='SEQOUT') C Get date ranges TYPE 1 1 FORMAT (' Start date in mm/dd/yy hh:mm:ss format: ',$) ACCEPT 2,MONTH1,DAY1,YEAR1,HOUR1,MINUT1,SECON1 BDATE=T10TAD(MONTH1,DAY1,YEAR1,ITIME(HOUR1,MINUT1,SECON1)) 2 FORMAT (I2,1X,I2,1X,I2,1X,I2,1X,I2,1X,I2) TYPE 3 3 FORMAT (' End date in mm/dd/yy hh:mm:ss format: ',$) ACCEPT 2,MONTH,DAY,YEAR,HOUR,MINUTE,SECOND EDATE=T10TAD(MONTH,DAY,YEAR,ITIME(HOUR,MINUTE,SECOND)) C Decide if graph should be by date or time ATAD=ADATE IF (EDATE-BDATE.LE.1) ATAD=ATIME C Write file header WRITE (21,5) MONTH1, DAY1, YEAR1, HOUR1, MINUT1, SECON1, +MONTH, DAY, YEAR, HOUR, MINUTE, SECOND 5 FORMAT ('New Graph'/'Graph Title Watch Statistics ', +I2.2,'/',I2.2,'/',I2.2,' ',I2.2,':',I2.2,':',I2.2,' to ', +I2.2,'/',I2.2,'/',I2.2,' ',I2.2,':',I2.2,':',I2.2/ +'Graph Font HELVETICA12BI'/ +'Key .0000000,.0000000, Symbol,HELVETICA8'// +'New Curve'/'Curve Font HELVETICA8'/'Curve Symbol Plus'/ +'Curve Type Solid'/'Curve Interpolation Linear'/'New Points') C Main loop 10 READ (20,1000,END=9999) RECTYP, RECSEQ, MONTH, DAY, YEAR, HOUR, +MINUTE, SECOND, INTVL, NJOBS 1000 FORMAT (I2,I3,I2,1X,I2,1X,I2,1X,I2,1X,I2,1X,I2,A7,A3) C Get time, date, and set TAD to match what graph would be TIME=ITIME(HOUR,MINUTE,SECOND) DATE=T10TAD(MONTH,DAY,YEAR,TIME) C Check TAD for being in range IF (DATE.LT.BDATE .OR. DATE.GT.EDATE) GO TO 10 C Date is in range, update bounds IF (FDATE.EQ.0) FDATE=DATE TAD=DATE IF (ATAD.EQ.ATIME) TAD=TIME+3600*INT(DATE-FDATE) IF (TAD.LT.MINTAD) MINTAD=TAD IF (TAD.GT.MAXTAD) MAXTAD=TAD C Dispatch based on record type GO TO (100,200,300,400,500,600) RECTYP C Unimplemented record type TYPE 11,RECTYP 11 FORMAT (' %Unknown record type ',I2,' encountered, discarded') GO TO 10 C Type 1 record - system statistics 100 REREAD 101, USED, IDLE, SWPW, SKED, SUSE, TCOR, FILW, BGND, NTRP, +NCOR, AJBL, NREM, TRAP, NRUN, NBAL, NWSM, BSWT, DSKR, DSKW, SWPR, +NLOD, CTXS, UPGS, FPGS, DMRD, DMWR, DKRD, DKWR, TTIN, TTOU, WAKE, +TTCC, TDIO, RPQS, GCCW, XGCW, KNOB, QDIST, NQDIST 101 FORMAT (32X,36A7,A5,10A7,A2) GO TO 10 C Type 2 record - load average 200 REREAD 201, LDAV, HQLDAV, LQLDAV, +(CLSNUM(I),CLSSHR(I),CLSUTL(I),CLSLAV(I),CLSHQL(I),CLSLQL(I), +I=1,32),NCLOAD 201 FORMAT (32X,9A7,32(A5,5A7),A2) GO TO 10 C Type 3 record - expanded per-job 300 REREAD 301, JOB, TTY, USER, PROG, ERT, EDEMD, EUSED, EGRDY, EBRDY, +ESWPR, EDSKR, EDSKW, ERPQW, EOTHR, EIMEM, ENLD, ENRSP, ESR, EWSS, +EUPGS, ESWPR1, EDSKR1, ETPF, EIFA 301 FORMAT (32X,2A3,2A10,A6,A4,A7,8A5,A6,A4,A5,A6,A3,2A7,2A5,2A4) GO TO 10 C Type 4 record - normal per-job 400 REREAD 401, JOB, TTY, USER, PROG, DELTAR, NRT, JU, CSH 401 FORMAT (32X,2A3,2A10,A6,A7,A4,2A7) GO TO 10 C Type 5 record - expanded statistics 500 REREAD 501, HIT, MISSF, MISSN, TOTRC, LOKPGS, SHRPGS, AVAMEM, +NRUNMN, NRUNMX, SMNRMN, SMNRMX, NRPLMN, NRPLMX, SYMDMD, SWPRAT, +ACTSWR, MEMUTL, AVWSSZ, AVCPUT, THNKTM, (DSKCHN(I), DSKUNT(I), +SEEKS(I), READS(I), WRITES(I), DSKNAM(I), DSKNUM(I), I=1,15), +NDSKIO 501 FORMAT (32X,3A6,10A5,A7,6A8,15(2A2,3A6,A10,A2),A2) GO TO 10 C Type 6 record - tune mode statistics 600 REREAD 601, TUSED, TSWPW, TSKED, TCTXS, TWAKE, TTDIO, TNRUN, +TNWSM, TNLOD, TUSED2, TGRDY, TBRDY, TSWPR, TDSKR, TDSKW, TRPQW, +TOTHR, TIMEM, TNLD, TNRSP, TRESP, TSR 601 FORMAT (32X,9A7,8A5,A6,A4,A5,A6,A3) write (21,9000) tad, tswpr 9997 format ('Y Label Percent Swap-In Wait (SWPR)') GO TO 10 C Format for outputting time and data point 9000 FORMAT (F9.3,', ',A10) C If time, round max and mins to inclusive hour 9999 IF (ATAD.NE.ATIME) GO TO 9991 MINTAD=3600*(MINTAB/3600) MAXTAD=3600*((MAXTAD+3599)/3600) C Compute interval - want 8 timestamps at most 9991 INTRVL=MAX0(1,(MAXTAD-MINTAD)/8) C Write file trailer WRITE (21,9996) ATAD,INTRVL,ATAD 9996 FORMAT (/'X Label ',A4/'X Font Helvetica10BI'/ +'X Unit 1'/'X Interval ',I5/'X NumberStyle ',A4,' 0') WRITE (21,9997) WRITE (21,9998) 9998 FORMAT ('Y Font Helvetica10BI'/'Y NumberStyle Floating 1') C Das Ende... STOP END C Convert from date/time components to TOPS-10 format date REAL FUNCTION T10TAD(MONTH,DAY,YEAR,TIME) INTEGER MONTH, DAY, YEAR, TIME T10TAD=(((YEAR-64)*12+(MONTH-1))*31+DAY-1)+FLOAT(TIME)/(24*60*60) RETURN END C Convert from time components to time in seconds INTEGER FUNCTION ITIME(HOUR,MINUTE,SECOND) INTEGER HOUR, MINUTE, SECOND ITIME=((HOUR*60+MINUTE)*60)+SECOND RETURN END ------- 20-Apr-85 12:43:03-PST,3996;000000000000 Return-Path: Received: from CU20B.ARPA by SU-SCORE.ARPA with TCP; Sat 20 Apr 85 12:39:55-PST Date: Sat 20 Apr 85 15:30:58-EST From: Thomas De Bellis Subject: Re: Galaxy bug? To: Crispin@SUMEX-AIM.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Mark Crispin " of Fri 19 Apr 85 20:09:11-EST Mark, Here are my suspicions. I havn't observed the behavior that you see here, so perhaps your EXEC/Galaxy is modified in some way. Normally, when you issue a queue request, the EXEC puts the entire file name along with the generation number into the IPCF packet. This is eventually sent along to the spooler that is responsible for handling jobs for the requested object type in the original message. The packet that gets sent to the spooler is pretty much what the EXEC sends with some minor header munging. Therefore, there are three or four people who can "get" you. 1) It might be the EXEC. CMU, for example, has modified their EXEC to not put explicit generation numbers into the IPCF request packet when an explicit generation number was not typed by the user. This helped them because certain requests can stay in the queue for quite a long time (ie, things being spooled off to tape for the Xerox 9700). If you EXEC is doing things like this, you might be being zapped because the wrong thing gets deleted (more on this later). Check the EXECQU module here. 2) It might be Quasar. At every scheduler call, Quasar checks its delete queue for lists of files to delete. For example, if you spool a file (in the real sense of the word, having the monitor do the submit for you, or submit a request with the SPL bit set), Quasar will toss the file for you if the request is canceled before it is scheduled. The relevent code is in QSRQUE. This bug would depend on a modified monitor or EXEC to be tickled. 3) It might be GLXLIB. The file you want to look at is GLXFIL. I would tend to doubt that it is in GLXLIB, although from what you describe, it could happen in a modified GLXLIB. The spooler can issue a F%DREL command which means to delete the file and release the FOB associated with it. This does the normal thing by doing a CLOSF% (with CZ%NRJ bit set) and the a DELF% with the expunge bit set. This is the right thing to do, I believe, since a new file is not being opened, just the current one being tossed in a special closing sequence. 4) It might be your spooler. In particular, notice that above I said to use the F%DREL call. This will delete an open file which is the right thing to have happen. If you plotter spooler is closing the file itself by issuing a F%REL and then deleting the file later by doing a F%DEL, you can have a timing window open up with a CMU'ish EXEC. The way F%DEL works is to first open the file up and then call F%DREL to toss it. Thus, without the explicit generation number information, you could open the first file, have the file deleted by somebody else, close the file with a F%REL and then later toss the wrong file with F%DEL because lack of explicit generation number information has caused you to open of the most recent file. The only spooler I really know about, LPTSPL, does do a F%DEL (the wrong thing). However, since our EXEC is unmodified in that respect (one of the few respects in which it is unmodified...) we don't suffer from the problem. I would check your spooler and EXEC see what's happening. You can find out what is being sent to Quasar by putting a breakpoint into the EXEC at SNDMS1:: where it does the actual MSEND to Quasar. The file names are stored around 20 words after the beginning of the message and can be 0$T'ed. Hope I've been of some help! -- Tom ------- 22-Apr-85 18:46:23-PST,684;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Mon 22 Apr 85 18:44:43-PST Date: Mon 22 Apr 85 18:38:48-PST From: Kirk Lougheed Subject: MSTR program To: su-tops-20@SU-SCORE.ARPA The MSTR program is an old LOTS hack that allows a wheel to mount/dismount structures without the intervention of QUASAR and friends. It is very useful when working on standalone systems. I've updated (and cleaned up) MSTR for use under Release 6.X systems. It specifically knows about RA81 disks. The source is on Sierra as PS:MSTR.MAC and the EXE is PS:MSTR.EXE. Kirk ------- 22-Apr-85 18:56:13-PST,562;000000000000 Return-Path: Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Mon 22 Apr 85 18:56:03-PST Date: Mon 22 Apr 85 18:55:53-PST From: Mark Crispin Subject: Re: MSTR program To: Lougheed@SU-SIERRA.ARPA cc: su-tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Kirk Lougheed " of Mon 22 Apr 85 18:47:51-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869 Phone: 1 (415) 968-1052 What does MSTR do that the STRTST program doesn't do just as well? ------- 23-Apr-85 12:33:16-PST,3771;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Tue 23 Apr 85 12:31:33-PST Date: Tue 23 Apr 85 13:31:32-MST From: Mark Crispin Subject: JOBCOF: The Saga Continues To: TOPS-20@SU-SCORE.ARPA SIMTEL20 crashed with an ILMNRF due to JOBCOF clobbering context again. This was in spite of it having all the currently favored patches including the save of FFL and FPC. From looking at the dump, I think that MPP needs to be saved as well. The rewritten JOBCOF routine looks like this: ;DETACH JOB IMMEDIATELY, LOGOUT AFTER 5 MINUTES IF NOT REATTACHED. ;INVOKED ON REQUEST BY PSI SERVICE JOBCOF:: IFE PANDASW,< ;[19] SKIPGE SLOWF ;IN JSYS CONTEXT? JRST [ MCENTR ;NO, GET THERE PUSH P,[IFIW!MRETN] ;SETUP RETURN JRST .+1] SE1ENT ;GET INTO SECTION 1 SAVET >;IFE PANDASW IFN PANDASW,< ;[19] SKIPL SLOWF ;IN JSYS CONTEXT? IFSKP. MOVEM CX,UPDL+NUPDL-1 ;NO, SAVE CX OVER THIS JUST IN CASE MCENTR ;GET TO JSYS CONTEXT PUSH P,[IFIW!MRETN] ;SETUP RETURN MOVE CX,UPDL+NUPDL-1 ;RETRIEVE CX FROM THIS KLUDGY PLACE ENDIF. SAVEAC ;SAVE CX BEFORE ACSAV SMASHES IT ACSAV ;SAVE ALL ACS SE1ENT ;GET INTO SECTION 1 STKVAR MOVE T1,FFL ;PRESERVE FFL MOVEM T1,CFFFL MOVE T1,FPC ;PRESERVE FPC MOVEM T1,CFFPC MOVE T1,MPP ;PRESERVE MPP XMOVEI T1,[ MOVE T1,CFFFL ;RESTORE FFL MOVEM T1,FFL MOVE T1,CFFPC ;RESTORE FPC MOVEM T1,FPC MOVE T1,CFMPP ;RESTORE MPP MOVEM T1,MPP RET] PUSH P,T1 ;ESTABLISH RESTORAL CONTEXT MOVEM P,MPP ;MAKE SURE THIS IS ALWAYS DONE >;IFN PANDASW MOVE 1,JOBNO SKIPGE B,CTRLTT ;HAVE A CONTROLLING TTY? JRST JOBCF1 ;NO CALL GTCJOB ;GET ITS OWNING JOB JRST JOBCF2 ;NONE. GO ON CAIN C,0(A) ;SAME AS THIS ONE? JRST JOBCF1 ;YES. GO ON JOBCF2: SETOM CTRLTT ;NO. CLEAR THIS ASSIGNMENT MOVE T1,JOBNO HRROS JOBPT(T1) ;ALSO CLEAR CONTROLLING TTY HERE JOBCF1: CALL LDTACH ;DO LOCAL DETACH MOVE T1,JOBNO HRRZ 1,JOBDIR(1) ;SEE IF NOW LOGGED IN IFE. T1 MOVX T1,UMODF ;NO, RESET STACK AND LOGOUT MOVEM T1,FFL SETZM FPC JRST FLOGO ENDIF. MOVE T1,BITS+.TICRF ;CHECK TO SEE WHAT THE TOP FORK THINKS TDNE T1,TTSPSI ; OF TAKING A CARRIER OFF INTERUPT RET ;IT THINKS SO, SO LET IT TRY CALL FFORKI ;INDIRECTLY FREEZE ALL INFERIORS ;**;[2941] CHANGE 1 LINE AT JOBCF1:+13L TAM 7-APR-83 MOVE 1,COFTIM ;[2941] GET TIME TO BE DETACHED CALL SETBKT ;COMPUTE BLOCKT DATA HRRI 1,COFTST ;SETUP SPECIAL TEST MOVSI T2,FHV1 ;LOW BLOCK PRIORITY HDISMS MOVE 1,JOBNO ;SEE IF NOW ATTACHED SKIPL JOBPT(1) IFSKP. MOVX T1,UMODF ;USER PC FAKE MOVEM T1,FFL SETZM FPC MCENTR ;RESET STACK, INIT JSYS CONTEXT MOVE T1,JOBNO HRRZ T1,JOBDIR(T1) ;DIRECTORY JUMPE T1,FLOGO1 ;DONT CHECK IF NOT LOGGED IN HRLI T1,USRLH CALL CNVDIR ;GET THE NUMBER OF THAT DIRECTORY GTDAL ;GET ALLOCATION ERJMP FLOGO1 ;DONT TRY ACJ IF THERE IS AN ERROR SETOM T1 ;FAKE A LOGOUT WITH -1 AS ARG ;**;[2812] CHANGE 1 LINE AT JOBCF1:+33L TAM 14-SEP-82 GTOKM (.GOLGO,,FLOGO1) ;[2812] ASK ACJ, BUT IN ANYCASE, ;LOG OUT THIS USER. (THIS IS ONLY TO BE NICE ;TO ACJ, WHO MAY NOT BE NICE TO US) JRST FLOGO1 ENDIF. NOINT ;KEEP CONTROL HLRZ T2,JOBPT(T1) ;GET CONTROLLING TTY MOVEI T3,"C"-100 ;FAKE A CONTROL-C CALL TTPSRQ ;"" CALL RFORKI ;RESUME ALL INDIRECTLY FROZEN INFERIORS OKINT ;ALLOW INTS AGAIN RET ;SCHEDULER TEST FOR ABOVE. WAITS UNTIL JOB ATTACHED OR SPECIFIED TIME ;ELAPSED RESCD COFTST: LOAD 2,FKJOBN ;GET JOB NUMBER SKIPL JOBPT(2) ;NOW ATTACHED? JRST 1(4) ;YES, WAKEUP JRST BLOCKT ;NO, GO TEST TIME SWAPCD ------- 23-Apr-85 12:38:41-PST,594;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Tue 23 Apr 85 12:37:28-PST Date: Tue 23 Apr 85 12:36:20-PST From: Kirk Lougheed Subject: Re: MSTR program To: Crispin@SUMEX-AIM.ARPA cc: su-tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Mark Crispin " of Mon 22 Apr 85 18:56:04-PST It has a source. It also displays *Release 6* status information regarding disks and structures. Both will mount/dismount structures; I don't know if STRTST knows about HSC50 disks. Kirk ------- 23-Apr-85 16:15:31-PST,894;000000000000 Return-Path: Received: from USC-ECLC.ARPA by SU-SCORE.ARPA with TCP; Tue 23 Apr 85 16:13:28-PST Date: Tue 23 Apr 85 16:11:29-PST From: Maurice J. Wuts Subject: Re: JOBCOF: The Saga Continues To: MRC@SIMTEL20.ARPA, TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Mark Crispin " of Tue 23 Apr 85 12:55:26-PST There seems to be a bug in your patch. The point was to save MPP, but you seem to forgot to: MOVE T1,FFL ;PRESERVE FFL MOVEM T1,CFFFL MOVE T1,FPC ;PRESERVE FPC MOVEM T1,CFFPC MOVE T1,MPP ;PRESERVE MPP ; Shouldn't there be the following instruction here? MOVEM T1,CFMPP XMOVEI T1,[ MOVE T1,CFFFL ;RESTORE FFL MOVEM T1,FFL MOVE T1,CFFPC ;RESTORE FPC MOVEM T1,FPC MOVE T1,CFMPP ;RESTORE MPP MOVEM T1,MPP RET] PUSH P,T1 ;ESTABLISH RESTORAL CONTEXT Maurice ------- 23-Apr-85 16:18:43-PST,962;000000000000 Return-Path: Received: from USC-ECLB.ARPA by SU-SCORE.ARPA with TCP; Tue 23 Apr 85 16:17:55-PST Date: 23 Apr 1985 16:12-PST Sender: MARK@USC-ECLB Subject: Re: JOBCOF: The Saga Continues From: Mark A. Brown To: MRC@SIMTEL20 Cc: TOPS-20@SU-SCORE Message-ID: <[USC-ECLB]23-Apr-85 16:12:37.MARK> In-Reply-To: The message of Tue 23 Apr 85 13:31:32-MST from Mark Crispin I think Mark missed a Movem.. below is the corrected code fragment. STKVAR MOVE T1,FFL ;PRESERVE FFL MOVEM T1,CFFFL MOVE T1,FPC ;PRESERVE FPC MOVEM T1,CFFPC MOVE T1,MPP ;PRESERVE MPP Movem T1,CFMPP ;*** Really preserve it *** XMOVEI T1,[ MOVE T1,CFFFL ;RESTORE FFL MOVEM T1,FFL MOVE T1,CFFPC ;RESTORE FPC MOVEM T1,FPC MOVE T1,CFMPP ;RESTORE MPP MOVEM T1,MPP RET] PUSH P,T1 ;ESTABLISH RESTORAL CONTEXT MOVEM P,MPP ;MAKE SURE THIS IS ALWAYS DONE Mark 24-Apr-85 12:26:50-PST,844;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Wed 24 Apr 85 12:24:49-PST Date: Wed 24 Apr 85 13:24:17-MST From: Mark Crispin Subject: bogus destination node To: TOPS-20@SU-SCORE.ARPA I am seen this problem at Stanford and at SIMTEL20 now. It isn't due to any Stanford mods in the EXEC or Galaxy since SIMTEL20 doesn't run those mods. The problem is that for no apparent reason a destination node gets set on all the jobs in the batch queue. Very commonly it is TOPS20::. This is on systems with no DECnet! Modifying all the jobs to have desination node LOCAL:: clears it. There seems to be no particular operational impact other than the annoying extra (twice as large) output from INFO BATCH. Any ideas on this one, Galaxy Gurus? ------- 24-Apr-85 14:12:55-PST,919;000000000000 Return-Path: Received: from LLL-MFE.ARPA by SU-SCORE.ARPA with TCP; Wed 24 Apr 85 14:12:31-PST Date: Wed, 24 Apr 85 22:11 GMT From: SAMUELSON%LLL@LLL-MFE.ARPA Subject: Re: bogus destination node To: tops20@SU-SCORE.ARPA From: Norm Samuelson To: MRC@SIMTEL20.ARPA cc: tops20@SU-SCORE.ARPA In-Reply-To: Message from "Mark Crispin " of Wed 24 Apr 85 12:39:08-PST Telephone: (415) 422-0661, [FTS 532-0661] Office-Location: Bldg 543, room 1067 Postal-Address: LLNL, PO Box 5511, L-630, Livermore, CA 94550 ALL galaxy requests have a PROCESSING-NODE set. If you change the local node name (you can set it in n-CONFIG) all the old requests in the queue will show the old node name. One easy way to handle it is to use the ROUTE command (in OPR) to route all jobs for the old node name to the new node name. - Sam - ------- 24-Apr-85 14:20:15-PST,676;000000000000 Return-Path: Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Wed 24 Apr 85 14:19:33-PST Date: Wed 24 Apr 85 14:10:54-PST From: Mark Crispin Subject: watch bug To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869 Phone: 1 (415) 968-1052 My Watch job blew up with an illegal instruction at PRINT+11; the JFN it was trying to SOUT% on wasn't open. Does anybody have a reliable version of WATCH that doesn't crap out on such things? It is irritating (to say the least) to have an attempt to record a trend over a long period of time blow up like this. ------- 24-Apr-85 14:51:17-PST,1382;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Wed 24 Apr 85 14:50:59-PST Date: 24 Apr 1985 1750-EST From: Tom Blinn To: TOPS20 at SU-SCORE Subject: Re: Bogus destination node Message-ID: <"MS10(2124)-1+GLXLIB1(1135)" 12105797321.31.275.62307 at DEC-MARLBORO> There is one other piece of information that Sam didn't mention, but that probably provides the rest of the puzzle, and that is the default local node name the monitor uses. If you don't specify it in the n-CONFIG file, and the monitor was built WITH the DECnet modules included (even if you are not running DECnet), then the local node name defaults to TOPS20. If your monitor was built WITHOUT the DECnet modules, the local node name defaults to LOCAL. Of course, building with/without DECnet is a flag, either in STG or PARAMS (I forget which, and am too lazy to look). Probably the "bogus" entries show up when you reboot a new monitor, and it was built with the switch in a different state from the old monitor. You might consider simply putting the NODE command into the n-CONFIG command file to define your node name as LOCAL whether the monitor contains DECnet or not. (Make sure SETSPD doesn't fall on its side if the appropriate DECnet JSYS fails when it trys to set the nodename.) Tom -------- 24-Apr-85 14:56:16-PST,1246;000000000000 Return-Path: Received: from CU20B.ARPA by SU-SCORE.ARPA with TCP; Wed 24 Apr 85 14:54:50-PST Date: Wed 24 Apr 85 17:54:43-EST From: Ken Rossman Subject: Dual port tape drive hangups(?) To: TOPS-20@SU-SCORE.ARPA Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 We've just recently dual ported our TU78 tape drives between two systems, though we have not yet gone into production with them switchable between two systems. I had done initial testing to make sure one could simply switch a drive from one port to the other (while there was no tape up), and both systems were able to properly recognize the drives when I put tapes up after switching. However, I found one day while one of the two systems was down, that switching those drives over to the other system which was up did NOT work. Nothing we did would cause the drives to be recognized by the system that was up (they had been switched to the system which was down before it went down). And, yes, we put tapes up and made the drives go ready. Does anyone know why this is? Do both systems indeed have to be up and running in order to be able to switch the tape drives over? /Ken ------- 25-Apr-85 06:14:22-PST,1719;000000000000 Return-Path: Received: from USC-ISIB.ARPA by SU-SCORE.ARPA with TCP; Thu 25 Apr 85 06:13:45-PST Date: Thu 25 Apr 85 02:32:05-PST From: The Mailer Daemon To: BILKIS@USC-ISIB.ARPA Subject: Message of 25-Apr-85 02:30:49 ReSent-To: tops20@SU-SCORE.ARPA ReSent-From: BILKIS at USC-ISIB.ARPA (connected to COMP:) ReSent-Date: 25 Apr 1985 Message failed for the following: sy.Ken@CU20B: 550 Mail from BILKIS@USC-ISIB.ARPA to sy.Ken@CU20B.ARPA is not authorized ------------ Date: 25 Apr 1985 02:30:49 PST Subject: Re: Dual port tape drive hangups(?) From: David Bilkis To: Ken Rossman In-Reply-To: (Message from "Ken Rossman " of Wed 24 Apr 85 17:54:43-EST) Ken, If I understand your msg correctly, the problem is that your system didn't see the Kontroller when it was coming up because the Master was unavailable to it (for some reason) when it came up. The Add Unit stuff works just fine, the 'Add Kontroller on Attention Interrupt' does not. Try reloading with all drives in dual port and not busy. ISI runs 6 drives configured dual ported as 3 dual port pairs between 6 systems with the drive select wheelies set to '2 - A/B mode' all the time. This periodically gets us into the trouble you mention, and slightly worse variations (unit 0 being mta1, and unit 1 being mta0 confuses the hell out of operators, especially when you can't switch unit select designators in order to maintain dual port mode). In general, being careful about drive operational status on shared drives during reload may be worth the extra effort. Love, Wook ------- ------- 25-Apr-85 08:11:51-PST,3107;000000000000 Return-Path: Received: from CU20B.ARPA by SU-SCORE.ARPA with TCP; Thu 25 Apr 85 08:06:40-PST Date: Thu 25 Apr 85 11:05:16-EST From: Thomas De Bellis Subject: Re: bogus destination node To: MRC@SIMTEL20.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Mark Crispin " of Wed 24 Apr 85 15:36:31-EST Hi MRC, I'm a little rusty on that particular area, but here is what I think is happening: I think you are being subject to a timing problem. Normally, when the system boots, it sets the its own local DECnet node name to be 'TOPS20'. That is where your Galaxy is getting this from. Usually SETSPD will run and then you set your local node name there. This should all happen before Quasar ever fires up. However, it is possible to change the node name of the local system *AFTER* Quasar starts up, in which case the fun begins. Alternatively, SETSPD may gronk and never set the node name. Running it later can also set the node name out from underneath Quasar. When Quasar starts, it rebuilds its internal queues by reading the failsoft file. The fail soft file contains requests, at lot of which pretty much look like the original IPCF requests sent from the EXEC. Quasar does some header munging and then submits them to itself using the internal bit. The routines that you want to look at are in QSRT20 (the file manipulation stuff), QSRFSS (Fail Soft indexing routines), QSRSCH (request scheduling and priority link in routines), QSRQSR (the rebuild routines). Now then, the request area can have a node specification in it. This is used if you are running the DN65 software so that you can schedule requests to IBM nodes. If you are a site that has implemented DECnet spooling (a lot of us have) or if you have a DN200, the node name is a DECnet node name. All this information is eventually used to construct the requested object block. Most users, particularly on systems that don't run DECnet or DN65, do not specifify a node name and that slot is left blank. So, when Quasar rebuilds its internal queues and constructs requested objects, it will fill in the blank node name with the current system local node. Later, the system node name gets set correctly and Quasar notices that and thinks that these jobs are for another node; that's why they all type /Proc:TOPS20:: I'm a little fuzzy, but I think that having them have different node names won't affect scheduling batch jobs. The only time it worries about node names for batch jobs is when the request node name is an IBM node. Otherwise it ignores the node specifications and sends everythingt to BATCON. This is different for printer objects where it really does care about the requested node in all cases. Check the QSRSCH module for further info in this area. Otherwise drop me a note and I'll try to remember some more about what happens. You are right however, it doesn't hurt anything to have these jobs like this. Hope I've been of some help! -- Tom ------- 25-Apr-85 09:37:42-PST,886;000000000000 Return-Path: Received: from BBNF.ARPA by SU-SCORE.ARPA with TCP; Thu 25 Apr 85 09:35:33-PST Date: 25 Apr 1985 12:35-EST Sender: RBASCH@BBNF.ARPA Subject: Trashed symbol table From: RBASCH@BBNF.ARPA To: Tops-20@SU-SCORE.ARPA Message-ID: <[BBNF.ARPA]25-Apr-85 12:35:39.RBASCH> We have tracked down a bug that caused 2 words in the symbol table to be trashed at start-up. (The problem came up when running SYSDPY crashed one of our systems because the value for the symbol OKSKD0 had been clobbered). The bug is that the XCT IORST at SYSLOD+3 will change the cells CONOPG and CASHF; these cells are in RSVAR, which overlaps the initial (pre-hidden) symbol table. Our solution was to move CONOPG (in STG) and CASHF (APRSRV) to RSDAT; the extra XCT IORST at SYSLD3+6 can probably be removed with this change, although we haven't tested that yet. Bob 25-Apr-85 12:14:06-PST,566;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Thu 25 Apr 85 11:51:20-PST Date: Thu 25 Apr 85 12:50:08-MST From: Mark Crispin Subject: Re: Trashed symbol table To: RBASCH@BBNF.ARPA cc: Tops-20@SU-SCORE.ARPA In-Reply-To: Message from "RBASCH@BBNF.ARPA" of Thu 25 Apr 85 10:35:00-MST Gee, that bug was reported on this list quite a while ago (1 year+). Maybe somebody ought to collect all the existing currently unfixed (by DEC) bugs in TOPS-20 and produce a single report out of it. ------- 26-Apr-85 12:51:15-PST,1245;000000000001 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Fri 26 Apr 85 11:08:21-PST Date: 26 Apr 1985 11:06 PST (Fri) Message-ID: From: "Frank M. Fujimoto" To: su-tops-20@score cc: gergely@drea Subject: New BBOARD I've installed a new BBOARD on Sierra with the following changes from Peter Gergely at DREA: . BBOARD now uses MM's .IDX files for last message read instead of its own .DATA file . If the subject field is too long to fit on the same line as the date/sender fields, it is printed on the next line . A /SCROLL-MORE switch now exists, which is similar to /MORE but it doesn't clear the display before showing a screen of data . Wildcard bboard specifications are now allowed . An X command exists to quit out of all bboards. This differs from the Q command becuase Q will only quit out of one bboard The source to BBOARD is on Sierra as PS:BBOARD.MAC. There is also PS:BMERGE.MAC which will take the .DATA and .IDX files and merge the two into the .IDX file. It will take the later read date between the two and save it in the .IDX file. -Frank 26-Apr-85 15:30:18-PST,504;000000000000 Mail-From: MRC created at 26-Apr-85 15:29:55 Date: Fri 26 Apr 85 15:29:55-PST From: Mark Crispin Subject: MMailbox bug fix To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869 Phone: 1 (415) 968-1052 Rich Alderson has reported a performance bug in MMailbox due to its supposedly prime hashing value not actually being prime. This is fixed in the most recent version of MMLBX.MAC on SCO: at Score. Thanks Rich! ------- 29-Apr-85 15:54:02-PDT,846;000000000000 Return-Path: Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Mon 29 Apr 85 15:49:30-PDT Received: ID ; Mon 29 Apr 85 18:49:09-EDT Date: Mon 29 Apr 85 18:49:08-EDT From: Vince.Fuller@CMU-CS-C.ARPA Subject: Re: FTP timeouts from simtel20. To: wancho@SIMTEL20.ARPA, tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Dave Towson (info-cpm-request) " of Thu 25 Apr 85 16:00:48-EST I believe there may be a buffering problem in the new FTP with the expanded buffer sizes. I was using it here and found that for short files, you win a lot but for long files, the average transfer rate is actually slower (it is very bursty). I would suggest reverting to the previous versions of FTP and FTPSRT, particularly if you have been having problems with timeouts. --Vince ------- 29-Apr-85 16:35:15-PDT,1330;000000000000 Return-Path: Received: from LLL-MFE.ARPA by SU-SCORE.ARPA with TCP; Mon 29 Apr 85 16:30:29-PDT Date: Mon, 29 Apr 85 23:24 GMT From: SAMUELSON%LLL@LLL-MFE.ARPA Subject: goodbye To: tops-20@SU-SCORE.ARPA From: Norm Samuelson To: tops-20@SU-SCORE.ARPA Telephone: (415) 422-0661, [FTS 532-0661] Office-Location: Bldg 543, room 1067 Postal-Address: LLNL, PO Box 5511, L-630, Livermore, CA 94550 As the old saying goes, all good things must end. For almost twelve years now I have been working with PDP-10s. Thru DECUS and the ARPANET, I have gotten to know many of you around the country. I have enjoyed working with you. I enjoyed working with DECUS and with many DEC employees and customers. It has been a lot of fun. It is now time for me to move on to other things (Since there is little of interest coming from DEC these days). I will be leaving the DEC world after tomorrow, going to work on NLTSS, a new operating system for super computers. I will keep my net mailing address for some time, although I will probably not login every day to read my mail from now on. A couple of DECUS's back I said goodbye to DECUS. Now I am saying goodbye to all my friends in TOPS-20 land. It has been nice knowing all of you. - Sam - ------- 30-Apr-85 08:50:21-PDT,594;000000000000 Return-Path: Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Tue 30 Apr 85 08:47:55-PDT Date: Tue 30 Apr 85 08:44:33-PDT From: Ed Pattermann Subject: Help on Tops20 -> VMS To: tops-20@SU-SCORE.ARPA Could someone post to the mailing list the details on accessing the info and software that DEC was collecting and providing on moving users and programs from Tops20 to VMS. I remember there being a public account back east somewhere where utilities were being collected and made available. Thanks! -- Ed ------- 30-Apr-85 09:12:23-PDT,638;000000000000 Mail-From: ALMQUIST created at 30-Apr-85 09:12:14 Date: Tue 30 Apr 85 09:12:13-PDT From: Philip Almquist Subject: Re: Trashed symbol table To: RBASCH@BBNF.ARPA cc: Tops-20@SU-SCORE.ARPA In-Reply-To: Message from "RBASCH@BBNF.ARPA" of Thu 25 Apr 85 09:35:00-PST Gee, I guess DEC must be a little slow. I reported that bug during the 5.1 field test. The answer claimed that the fix I had applied (same as yours - moving CONOPG and CASHF to RSDAT) would work in 5.1 as an interim solution and that a real fix would be included in "the next release", which I guess meant 6.0. Philip ------- 30-Apr-85 09:40:42-PDT,703;000000000000 Return-Path: Received: from LLL-MFE.ARPA by SU-SCORE.ARPA with TCP; Tue 30 Apr 85 09:39:24-PDT Date: Tue, 30 Apr 85 16:38 GMT From: SAMUELSON%LLL@LLL-MFE.ARPA Subject: Re: Help on Tops20 -> VMS To: TOPS-20@SU-SCORE.ARPA From: Norm Samuelson To: PATTERMANN@SUMEX-AIM.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Ed Pattermann " of Tue 30 Apr 85 08:57:48-PDT Telephone: (415) 422-0661, [FTS 532-0661] Office-Location: Bldg 543, room 1067 Postal-Address: LLNL, PO Box 5511, L-630, Livermore, CA 94550 Contact Powell@MARKET, he is in charge of that stuff, what there is. - Sam - ------- 30-Apr-85 10:58:29-PDT,963;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Tue 30 Apr 85 10:57:49-PDT Date: 30 Apr 1985 1325-EDT From: Tom Blinn To: PATTERMANN at SUMEX-AIM cc: TOPS-20 at SU-SCORE Subject: Re: Help on Tops20 -> VMS Message-ID: <"MS10(2124)-1+GLXLIB1(1135)" 12107310878.32.275.86274 at DEC-MARLBORO> You can access DEC-MARLBORO (MARKET) via ARPAnet. The account on MARKET is LCG.CUSTOMER, password CUSTOMER. There is also a dial-up account, if you want it, I can post it, but I don't have it close at hand. You will be guided to some help files once you log in. The tools are not presently accessible on-line. We are working on identifying the right way to make this happen. In the interim, use MS (MAIL == MS SEND) to mail TO: REQUEST to get tools tape mailed to you (no charge). Be sure to answer all the questions in the header (address, etc.) Tom -------- 1-May-85 22:19:52-PDT,564;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Wed 1 May 85 22:15:46-PDT Date: Wed 1 May 85 23:15:18-MDT From: Mark Crispin Subject: yet more JOBCOF To: TOPS-20@SU-SCORE.ARPA I just got another OPOPAC hit. I am starting to suspect that a nested JOBCOF call is happening while doing the MCENTR which is early in the JOBCOF routine. I'm working on yet another rewrite of JOBCOF. Looking through the code I also found that LDTACH has some totally bogus code in it. More later... ------- 4-May-85 01:24:31-PDT,574;000000000000 Return-Path: Received: from DREA-XX.ARPA by SU-SCORE.ARPA with TCP; Sat 4 May 85 01:24:20-PDT Date: Fri 3 May 85 13:12:41-ADT From: Reid Broome Subject: DEC-20 and WANG communications software To: tops20@SU-SCORE.ARPA We have a requirement to be able transfer files/documents to-and-from our WANG model OIS-130A word processing system and our DECsystem-20. Does anyone have or know the whereabouts of a program that runs on TOPS-20 that will do file transfers with a WANG word processor. Reid Broome ------- 4-May-85 02:20:30-PDT,1909;000000000001 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Sat 4 May 85 02:20:26-PDT Date: Thu 2 May 85 16:54:25-PDT From: Sean Welsh Subject: Fix to COMND/Sumex GTJFN interface To: su-tops-20@SU-SCORE.ARPA Problem: COMND provides cryptic help in response to "?" when .CMFIL is a possible alternate parse for a .CMKEY field, appearing to include the possible filename completions of the input in the command table. The EXEC is a case in point: @d? Command, one of the following: DAYTIME DDT DEASSIGN DEBUG DECLARE DEFINE DELETE DEPOSIT DETACH DIRECTORY DISABLE DISCARD DISMOUNT DO DBEDIT DUMPER @d Note that DBEDIT and DUMPER are programs in the system search path. Diagnosis: COMND passes the "?" on to GTJFN after providing help for the keyword parse, and GTJFN provides no guidance beyond a list of possible completions. Solution: Type out any user-supplied help message before passing the "?" to GTJFN. In COMND.MAC, in the literal at CMRAT1+12, replace: IFN STANSW,< CALL CHKFIL ;[SMXGTJ] PARSING A FILESPEC? JRST CMRATR ;[SMXGTJ] YES, PASS THE ? ON TO GTJFN >;IFN STANSW with: IFN STANSW,< CALL CHKFIL ;[SMXGTJ] PARSING A FILESPEC? JRST [ TXNN F,CMPS1F ;YES, JUST SCANNING? CALL DOHLP ;NO, GIVE PROVIDED HELP, IF ANY JRST CMRATR ] ;[SMXGTJ] NOW PASS THE ? ON TO GTJFN >;IFN STANSW This fix is in [Sierra]PS:<6-1-MONITOR>COMND.MAC. The results in the EXEC look like @d? Command, one of the following: DAYTIME DDT DEASSIGN DEBUG DECLARE DEFINE DELETE DEPOSIT DETACH DIRECTORY DISABLE DISCARD DISMOUNT DO or system program name DBEDIT DUMPER @d The patch can be retrofitted to 5.3 and 6.0 monitors. Enjoy. --Sean ------- 5-May-85 13:42:41-PDT,2477;000000000000 Return-Path: Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Sun 5 May 85 13:42:27-PDT Date: Sun 5 May 85 13:42:00-PDT From: Kirk Lougheed Subject: Stanford Host tables To: su-tops-20@SU-SCORE.ARPA The Sierra experiment to merge the NIC host table with the Stanford PUP host table seems to have worked out quite well. The way this scheme works is to use PUPUPD to get the latest PUP-NETWORK.DIRECTORY (if any) and write SYSTEM:HOSTS.PUP, a NIC-style host table. The program NICUPD is then used to read the official NIC host table and write SYSTEM:HOSTS.NIC. The program HSTUPD then takes HOSTS.PUP and HOSTS.NIC and if either of those files has a write date more recent that HOSTS.TXT, it then writes the union of those files to SYSTEM:HOSTS.TXT and installs the file. HSTUPD also reduces the size of HOSTS.TXT by leaving out irrelevant protocol information, resulting in a faster loading host table. Advantages of this scheme include: - Ability to send mail to Stanford hosts that are in only the PUP host table, but do not speak PUP protocols. There are an increasing number of such hosts at Stanford. - The MRC mailsystem as distributed assumes IP as the perferred protocol. At sites like LOTS this means obscure addresses like L.LOUGHEED@[36.48.0.1] instead of the more readable L.LOUGHEED@LOTS-A. Disadvantages of this scheme: - Mail that gets to a host that doesn't have a modified NIC host table cannot be replied to by Joe Random user. These hosts include the entire Internet outside of Stanford. DEC-20 hosts at Stanford that don't use a modified host table will use PUP protocols. Stanford UNIX hosts already use the scheme that Sierra does. It is my belief that the advantages of this scheme outweigh the disadvantages. If a Stanford host not in the NIC table is sending mail legitimately to an Internet host outside of Stanford, then that host should either register itself with the NIC or use a mail relay (Score, Sierra, Sumex). At Sierra we run a batch job at 6:00AM every morning that has the following lines for updating host tables. ! Update the host tables ! @SYSTEM:PUPUPD @SYSTEM:NICUPD @SYSTEM:HSTUPD INSTALL ! The sources are PS:PUPUPD.MAC, PS:NICUPD.MAC, and PS:HSTUPD.C. Yes, you need a copy of KCC to rebuild HSTUPD. Frank Fujimoto (FMF@SIERRA) is the author of HSTUPD. Kirk ------- 7-May-85 01:09:52-PDT,1826;000000000001 Return-Path: Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Tue 7 May 85 01:08:44-PDT Date: Tue 7 May 85 02:08:30-MDT From: Mark Crispin Subject: JOBCOF once again To: TOPS-20@SU-SCORE.ARPA I have spent the past few days carefully reviewing all the code having to do with carrier-off PSI's as well as talking with various others who have delved into this problem before me. I believe I have fixed all the known carrier-off PSI bugs. This was accomplished by rewriting most of LDTACH and JOBCOF in MEXEC, PIRCOF in SCHED, and writing TTYSRV code to break links without going through the TLINK% JSYS and maintain "in COF routines" status bits in the dynamic data to prevent nested carrier-off calls. Much of my time was taken in sorting out the confused nomenclature in the comments and code. In several places it is clear that somebody patched in something to fix a symptom without really understanding what was needed to fix the bug. I confess that some of my previous attempts in fixing JOBCOF bugs were similarly poorly-thought out. DEC apparently claims that JOBCOF bugs are fixed in release 6. From the release 6 code at Stanford I can state that this is not true. DEC has decided to flush entering JSYS level from monitor mode in release 6, which simplifies much of the code (and by extension removes many of the failure modes), but a number of the known JOBCOF bugs are still unfixed in release 6. I expect to test this code at SIMTEL20 and SUMEX for some time (they've really been hurting with these problems) before thinking about releasing it. The changes are quite extensive! If you're really being badly bit by OPOPAC bughlts and other JOBCOF related bugs send me mail. -- Mark -- ------- 7-May-85 16:23:28-PDT,1767;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Tue 7 May 85 15:41:47-PDT Date: Tue 7 May 85 16:41:30-MDT From: Mark Crispin Subject: Digital Review To: TOPS-20@SU-SCORE.ARPA I just got sent my first complimentary issue of Digital Review. As I suspected, it is pretty depressing. There is a long AI section which would have you believe that most of the world's AI is being done on VAX 11/780's although a few organizations have Symbolics Lisp Machines which while a bit expensive run Lisp applications 20% faster. I guess their point is that you use Lisp Machines for CPU-bound applications but you do all your interactive stuff on a VAX. But!! 10's and 20's ARE mentioned. In the "Logged On" column, a commentary about "2600" talks quite a bit about them. Apparently 2600 is the current phone phreak/cracker newsletter; needless to say the article abuses the term "hacker" even though the columnist professes to know better. Quite a bit is mentioned about how the 2600 people break into 10/20 systems, truly trivial, or so the article implies. Needless to say, all of the bugs turn out to be of the "known account/personal name, guess the password from that" sort of thing. Unix is mentioned as a tougher nut to crack, but there are ways to find accounts without passwords. I guess they never heard of Unix's vulnerability to known plaintext attacks. The paragon of security? VMS, of course, as long as you remember to change the passwords for the SYSTEM, FIELD, and SYSTEST accounts. Very "admirable". Enough to make you gag. Does anybody get this "2600" newsletter who'd be willing to send me a xerox of the article? ------- 7-May-85 16:25:39-PDT,1600;000000000000 Mail-From: ALMQUIST created at 7-May-85 16:10:28 Date: Tue 7 May 85 16:10:28-PDT From: Philip Almquist Subject: Re: Fix to COMND/Sumex GTJFN interface To: WELSH@SU-SIERRA.ARPA cc: su-tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Sean Welsh " of Sat 4 May 85 02:20:32-PDT Sean, I looked at the problem you mentioned several months ago and decided not to fix it because it is a harder problem than your patch suggests. The remaining bug that I know of is that CM%SDH is not honored. Although I haven't tried it, I suspect from looking at the code that it also fails if echoing is off or if one is trying to parse an output file name or... The real problem is that it is very hard to make code which is in the wrong place do the right thing in all cases. Fixing this right would take more time than I want to spend on the project, but the basic idea is: 1) Remove all the changes to CMRFLD, since it never should have been changed in the first place. 2) Remove the change at CMFIL3. ;The next step is the tricky one... 3) At CMFH1-1, replace the existing instruction with roughly the following: IFNSK. ;Input filespec? ;Yes... if question mark first char in the atom HRROI T1, [ASCIZ " input filespec"] JRST CMFH1 ;Handle in old way else deposit "?" at end of atom buffer ;May be necessary to do other minor ; things here to make world safe for ; democracy... JRST CMFIL2 ;Handle like "$" endif ENDIF. Philip ------- 8-May-85 06:47:51-PDT,1068;000000000000 Return-Path: Received: from MCC.ARPA by SU-SCORE.ARPA with TCP; Wed 8 May 85 06:47:32-PDT Date: Wed 8 May 85 02:22:38-CDT From: Clive Dawson Subject: DECUS Pre-symposium seminar on TOPS-20 Release 6 To: tops20@SU-SCORE.ARPA This is just a reminder that a one-day seminar will be held on the Sunday immediately prior to the DECUS conference in New Orleans (May 26) which will cover TOPS-20 Rel. 6 Internals. This is a good deal for folks who want to get at least an intro to this stuff without paying several times as much for the DEC Ed. Services course. Monitor developers from DEC's Large Systems Engineering will be the instructors. I'm not sure what the deadlines are for signing up, but rumor had it that the seminar registrations was just barely approaching the "break even" point as of few days ago. It would be a shame if it had to be cancelled, so if you or anybody you know can benefit from it, I'd suggest calling the DECUS office at (617)480-6419 ASAP for more information. Clive ------- 8-May-85 21:17:08-PDT,1107;000000000000 Mail-From: G.FUSSELL created at 8-May-85 21:16:58 Date: Wed 8 May 85 21:16:58-PDT From: Carl Fussell Subject: CI To: tops-20@SU-SCORE.ARPA Address: Santa Clara University Our CI/HSC etc has just arrived. I was given to understand that it would take 2 channels when installed. Our CE has just informed us that its installation will cause the loss of 4 channels rather than 2. Apparently (according to him), the problem is that backplane changes that are made for the CI also affect the next 2 channels (in anticipation of NI installation). We do not have NI, nor will we be getting it in the near future. It seems a little strange to me to lose 25% of our channels for no reason. We have 5 different RH devices currently, and are going to have to unplug one and no longer use it according to the CE. Has anyone else had experience with this? ie. have a CI and no NI yet not lost slots 5 and 6? Any comments, advice, suggestions, etc would be greatly appreciated. Thanx... Carl U. of Santa Clara (via SCORE) ------- 8-May-85 21:49:27-PDT,608;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Wed 8 May 85 21:47:35-PDT Date: Wed 8 May 85 22:47:24-MDT From: Mark Crispin Subject: Re: CI To: G.FUSSELL@SU-SCORE.ARPA cc: tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Carl Fussell " of Wed 8 May 85 22:42:38-MDT Carl - I regret to inform you that the CE is right. I believe that the electrical characteristics of all 4 internal channels are changed by the CI upgrade. By the way, that SCU need any consulting help? -- Mark -- ------- 9-May-85 06:06:43-PDT,982;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Thu 9 May 85 06:03:58-PDT Date: Thu 9 May 85 09:01:06-EDT From: Kevin Paetzold Subject: Re: CI To: G.FUSSELL@SU-SCORE.ARPA cc: tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Carl Fussell " of Thu 9 May 85 00:19:26-EDT Telephone: 617-467-7430 (DTN: 231-7430) Mail-stop: MRO1-2/L10 when you install an ni or a ci you can no longer install rh20s in any of the top four slots. in reality the rh20 is not the channel it is a massbuss adapter for the channel. all kl's have 8 channels (or one depending on how you look at it). the reason for this is that5 the klipa and the klni use a lot of power. the power system for the io backplane could not power 6 rh's and klipa and a klni. we have been "advertising" the rh reduction for a long time now and it should not be a surprise to anyone. ------- 9-May-85 16:14:52-PDT,891;000000000000 Mail-From: MRC created at 9-May-85 16:14:14 Date: Thu 9 May 85 16:14:14-PDT From: Mark Crispin Subject: commercial message To: TOPS-20@SU-SCORE.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869 Phone: 1 (415) 968-1052 A private message which had some commercial content was inadvertantly sent to the TOPS-20 list. This isn't appropriate use of the TOPS-20 list, even if the origin is the TOPS-20 list's moderator. Said person is highly embarassed, especially when he is also the MM maintainer and should know by now the difference between "REPLY SENDER" and "REPLY ALL"! By the time I realized what had happened, it was too late to stop the message. I was going to ignore it and hope everybody else did, but I got enough comments that I feel a public apology is in order. Mea culpa. -- Mark -- ------- 10-May-85 11:07:18-PDT,1417;000000000000 Return-Path: Received: from UCI-ICSA by SU-SCORE.ARPA with TCP; Fri 10 May 85 11:06:49-PDT To: tops-20@su-score.arpa Subject: Removing bad blocks in swap area Reply-To: raj@uci-icsa Date: 10 May 85 11:06:10 PDT (Fri) Message-ID: <376.484596370@uci-icsa> From: Richard Johnson Received: from Localhost by UCI-ICSA; 10 May 85 11:06:30 PDT (Fri) We have two DEC 2020's with two RP06's on each. Recently we have been getting BUGHLT's like "SWPUPT" about once every other week or so. I looked up this bug halt in the manual and it says "... the BAT blocks will not be marked". Also since there is no "Action:" specified, the manual says we should submit an SPR along with a crash dump to DEC. I don't think such an SPR or crash dump would be of much use to DEC since the problem is obviously a bad block on our disks, thus I have ignored that part. The real question here is, "Is there a way to find and enter this bad block into the BAT block tables short of reformatting the disk?" If not, I guess it's about time to reformat them anyway. Any help would be appreciated. (By the way, we don't have sources, in case that matters.) ------------------------------------------------------------------------ Richard Johnson raj@uci.arpa (ARPA) UCI ICS Research Systems Manager ucbvax!ucivax!raj (UUCP) 13-May-85 07:13:05-PDT,682;000000000000 Return-Path: Received: from COLUMBIA-20.ARPA by SU-SCORE.ARPA with TCP; Mon 13 May 85 07:09:46-PDT Date: Mon 13 May 85 10:09:40-EDT From: Rich Cower Subject: support levels To: tops-20@SU-SCORE.ARPA We have two support items here on the CS 20 - (I'll list em) Qt023-3m - tops 20 for 2040-s/2060-p,9 $277 mo and... Qt101-4m - tops-20 src pkg up 16 bpi $142 mo i tried to get rid of the first one since it apparently does nothing for us and was told we had to have it. anyone know why? (please don't suggest the obvious moneytary rewards to be gained by such policies, i understand that). thanks...rich ------- 13-May-85 07:38:52-PDT,499;000000000000 Return-Path: Received: from UTEXAS-20.ARPA by SU-SCORE.ARPA with TCP; Mon 13 May 85 07:38:43-PDT Date: Mon 13 May 85 09:38:04-CDT From: CC.KASSEBAUM@UTEXAS-20.ARPA Subject: FTP spool To: tops-20@SU-SCORE.ARPA Does anyone know about a FTP spooler. We would like to set something like this up on our local ethetnet to print file on other systems or just transfer files. All of the system do know how to speak TCP/IP. Regards, Don Kassebaum ------- 13-May-85 07:44:45-PDT,851;000000000000 Return-Path: Received: from oslo-vax.ARPA by SU-SCORE.ARPA with TCP; Mon 13 May 85 07:44:18-PDT Received: by oslo-vax.ARPA (4.12/4.7) id AA12731; Mon, 13 May 85 16:44:45 -0100 Date: 13 May 1985 16:36-EST From: bassen@oslo-vax (T S Lande) Subject: Warning: Don't use CFS!!!!! To: TOPS-20@SU-SCORE Message-Id: <484846563/bassen@oslo-vax> We are running TOPS-20 6.0 using CI and CFS with HSC50 equipped with 2 RA81s. We have one 2060 and one 2065. If you are trying to do that you'll get a corrupted file-system with destroyed directory-blocks. Our system are crashing constantly and the disks must be reformatted and file-system rebuild. So my advice is: STAY AWAY FROM CI and CFS!!!! (unless you believe i 6.1.........) Tor Sverre Lande Institute of Informatics University of Oslo 13-May-85 08:26:06-PDT,729;000000000000 Received: from LOTS-B by Score with Pup; Mon 13 May 85 08:25:57-PDT Date: Mon 13 May 85 08:22:13-PDT From: Sean L. Welsh Subject: Re: Warning: Don't use CFS!!!!! To: bassen@OSLO-VAX.ARPA cc: TOPS-20%Score@LOTS-B In-Reply-To: Message from "bassen@oslo-vax (T S Lande)" of Mon 13 May 85 14:36:00-PDT LOTS has had no such problems with three (soon to be four) 2060s sharing the same filesystems on RA81s. We are running 6.1 Field Test tape 5. I might point out that release 6.0 *does not* support CFS.... it only supports one CPU on the CI. To use CFS you MUST be running release 6.1; perhaps this is your problem. Sean L. Welsh Manager, LOTS Computer Facility ------- 13-May-85 09:00:02-PDT,1570;000000000000 Return-Path: <@COLUMBIA-20.ARPA:GINGELL@CWR20B> Received: from COLUMBIA-20.ARPA by SU-SCORE.ARPA with TCP; Mon 13 May 85 08:57:26-PDT Received: from CWR20B by CUCS20 with DECnet; 13 May 85 11:57:02 EDT Date: Mon 13 May 85 11:56:07-EDT From: Rob Gingell Subject: Re: support levels To: COWER%COLUMBIA-20@CUCS20 cc: tops-20%SU-SCORE@CUCS20 In-Reply-To: Message from "Rich Cower " of Mon 13 May 85 10:16:45-EDT We also get (almost) those maintenance items (we get QT102-4M which includes the RSX20F sources). This is what I think we get from these part numbers. QT101-4M is only the Monitor, and EXEC sources -- i.e., it entitles you to tapes with those things on it. Because you have this, you should have recently received the AP#9 5.1 sources for the monitor and EXEC. Because you get QT101-4M, QT023-3M is partially unnecessary for you, since QT101-4M gives you what you need for the monitor and EXEC. However, QT023-3M is the only part which gives you GALAXY, all the Utilities, and all the bundled TOPS-20 software. Now -- a new question. If I understood the announcements at the last DECUS correctly, to get TCP/IP in the normal 6.1 distribution, we must either change our QT023 number to something new, or else get an additional QT number for the TCP/IP stuff. Does anyone know which of these we are actually supposed to do, and if a new QT number is involved what that number is? We are not now a "TOPS-20AN" site, though we want to use TCP/IP over the NI's we've ordered. ------- 13-May-85 09:25:32-PDT,684;000000000000 Return-Path: Received: from CU20B.ARPA by SU-SCORE.ARPA with TCP; Mon 13 May 85 09:24:38-PDT Date: Mon 13 May 85 12:23:37-EDT From: Ken Rossman Subject: Re: Warning: Don't use CFS!!!!! To: bassen@OSLO-VAX.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "Sean L. Welsh " of Mon 13 May 85 11:29:11-EDT Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 We're running a 2-system (soon to be 3, followed by 4) CFS configuration here at Columbia, and have not seen anything like the problems you described. Maybe you have an HDA or two that are deteriorating? /Ken ------- 13-May-85 11:05:21-PDT,592;000000000000 Return-Path: Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Mon 13 May 85 11:05:08-PDT Date: Mon 13 May 85 12:04:23-MDT From: Mark Crispin Subject: Re: support levels To: COWER@COLUMBIA-20.ARPA cc: tops-20@SU-SCORE.ARPA In-Reply-To: Message from "Rich Cower " of Mon 13 May 85 10:49:49-MDT My understanding is that the QT023 is the entire TOPS-20 distribution including the utilities, while QT101 is just monitor (and EXEC?) sources. So without QT023, you wouldn't get any of the system software. ------- 13-May-85 11:56:19-PDT,1476;000000000000 Return-Path: Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Mon 13 May 85 11:55:37-PDT Date: Mon 13 May 85 14:57:22-EDT From: Kevin Paetzold Subject: Re: Warning: Don't use CFS!!!!! To: bassen@OSLO-VAX.ARPA cc: TOPS-20@SU-SCORE.ARPA In-Reply-To: Message from "bassen@oslo-vax (T S Lande)" of Mon 13 May 85 17:36:00-EDT Telephone: 617-467-7430 (DTN: 231-7430) Mail-stop: MRO1-2/L10 First off you are using unsupported functionality of release 6.0. CFS is not supported in release 6.0 at other than the initial field test sites. We can not help you if you attempt to cross the ocean in a rowboat either. However I can assure you that any problem you might have is not as straightforward as you believe. I assure you that many development systems (and multiple clusters) have been running CFS in house for years (yes i mean multiple years) and it works. As for your specific problem I would first try to eliminate local problems. Is your hardware working? Are the systems in the clusters (specifically the disk drives) at the proper ground with respect to eachother (i suspect not)? Are your HSCs and RA81s up to rev? did you turn on any bits in the home blocks (specifically in the flags word)? Certain bits in the home blocks mark the disk as a don't care disk and cause the monitor not to do any CFS negotiation. ------- 13-May-85 14:26:54-PDT,3231;000000000000 Mail-From: BILLW created at 13-May-85 14:26:29 Date: 13 May 1985 14:26-PDT Sender: BILLW@SU-SCORE.ARPA Subject: Re: FTP spool From: William "Chops" Westfield Cc: tops-20@SU-SCORE.ARPA Message-ID: <[SU-SCORE.ARPA]13-May-85 14:26:27.BILLW> In-Reply-To: The message of Mon 13 May 85 09:38:04-CDT from CC.KASSEBAUM@UTEXAS-20.ARPA I have an FTP spooler based on a somewhat out of date version of the VAF@CMU tops-20 user FTP program. It seems to work pretty well, assuming that the systems that you are sending to dont hang... Sources/etc are in SRI-KL:QFTP.* Here is QFTP.HLP: Run the program QFTP.EXE. It will look like an ordinary FTP (in fact, It will work as an ordinary FTP). There is one new command called SPOOL which takes as its argument the name of a control file (the default is QFTP.CTL). The Control File can contain any of the following commands: LOGFILE local-filename This is the name of the file that will get typeout from the program, and is optional. If provided, QFTP will continue in the background, writing its progress to the specified file. If this command is omitted, QFTP will not transfer to background, and will write reports to the terminal (this mode is suitable for running as a batch job, for example). HOSTINFO hostname username password The remote host and account. LOCALFILES wildcard-filespec The files to send. FOREIGNFILES wildcard-filespec What the sent files will be called on the remote system. If a wildcard is used in a field, then that field will be replaced with the corresponding field from the source file. A directory may be specified, in which case it will be sent tops20 style (enclosed in <>). For example if the file currently being sent is TEST.OUTPUT, and the FORIEGNFILES argument is *.RESULTS, then FTP will attempt to send the file to TEST.RESULTS. DELIVEREDFILES local-filename This is what the file should be renamed to on the local system after it has been successfully sent. It follows the same rules as FORIEGNFILES in terms of wildcards. Files should be deleted if no DELIVEREDFILES entry exists in the CTL file. (untested) SLEEPTIME