1-Jan-81 15:58:54-EST,540;000000000000 Mail from SU-SCORE rcvd at 1-Jan-81 1558-EST Mail-from: ARPANET site DEC-2136 rcvd at 31-Dec-80 1451-PST Date: 31 Dec 1980 1749-EST From: Dave Lyons To: admin.mrc at SCORE Subject: Did you know about Message-ID: 11692920292.4.16.35268 at DEC-2136 Remailed-date: 1 Jan 1981 1302-PST Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]Tops-20.DIS.60: ; The bug in the special queue stuff? At SNDIM1-3, the MOVE 3,3(2) DPB 3,junk should be MOVEM 4,3(2) JFCL 12-Jan-81 21:14:36-EST,739;000000000000 Mail from SU-SCORE rcvd at 12-Jan-81 2114-EST Mail-from: ARPANET site USC-ECL rcvd at 7-Jan-81 2235-PST Date: 7 JAN 1981 2234-PST From: THOMPSON at USC-ECL Subject: oversigt in PHYSIO To: smith at ISIB, Admin.MRC at SU-SCORE Remailed-date: 12 Jan 1981 1808-PST Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]Tops-20.DIS.60: ; While adding a new data mode to the magtapes, i discovered a little goof in physio. There is a table called MODTAB that purports to give bytes per word for I/O requests. It should have an EXP 1 at the end for the tu70 hi-density data mode. As it turns out, the next word IS a 1, but if you add another data type, you will lose big. mark ------- 14-Jan-81 21:15:47-EST,1667;000000000000 Mail from SU-SCORE rcvd at 14-Jan-81 2115-EST Mail-from: ARPANET site MIT-AI rcvd at 14-Jan-81 1628-PST Date: Wednesday, 14 January 1981 19:21-EST From: Chris Ryland To: admin.MRC at SU-SCORE Subject: can you ask people if they've seen this? Tnx. Remailed-date: 14 Jan 1981 1804-PST Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]Tops-20.DIS.60: ; Date: Wednesday, 14 January 1981 18:52-EST From: EBM at MIT-XX To: bug-twenex at MIT-XX Re: Magtape problem I have encountered a bug in the magnetic tape code (MTA not MT), which appears to be very obscure: Bad behavior: I have a tape with data on it and am at EOT (i.e., in between the two file marks), but with no jfn to the tape drive. I open a jfn (normal, not dump mode) and then issue a .MOEOT MTOPR, which should get me to the end of the tape. Indeed, it eventually does, but it does so by backspacing, record by record, to the start of the file, and then spacing to the end of the file. If I write a program to do essentially what the call does, then my program works correctly. Here is the algorithm: backspace 1 file label: forward 1 file forward 1 record if MT%EOF set, then we are after the second file mark, and are done; otherwise, loop back to "label". I suspect that the problem has something to do with the way MOEOT steps through its various states, and particularly the handling of the bit MTOWT. However, detailed examination of the code has not revealed the bug to me. It was moderately repeatable, but could be timing dependent. Sounds like something that DEC should fix .... 15-Jan-81 16:11:17-EST,4071;000000000000 Mail from SU-SCORE rcvd at 15-Jan-81 1610-EST Mail-from: ARPANET site RUTGERS rcvd at 15-Jan-81 1151-PST Date: 15 Jan 1981 1452-EST From: HEDRICK at RUTGERS Subject: Re: can you ask people if they've seen this? Tnx. To: cpr at MIT-MC cc: admin.MRC at SU-SCORE In-Reply-To: Your message of 14-Jan-81 2116-EST Remailed-date: 15 Jan 1981 1253-PST Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]Tops-20.DIS.60: ; We have seen behavior that looks like this from DUMPER. I am not sure we can repeat it. Indeed the SAVE/ARC command may even be doing this. One would think SAVE/ARC would simply go to the end of the tape and then start saving. But in fact it seems to go to the end, back to the beginning, and again to the end. I conjecture (but have not looked at the code) that this is what is going on. However the person who has been looking at rel. 4 tape problems for us is Don Watrous, who is currently on vacation. He will answer you with more authority than I when he gets back. In general, tape handling has taken a large leap back at our site since we brought up rel. 4. We are considering setting all drives unavailable and going back to our interim archiver. The problems we are having are: - tapes are very sensitive to problems in the label area. It is fairly common for tapes that we know are labelled to somehow magically become unlabelled (i.e. when you mount them, MOUNTR no longer sees them as having valid labels). We are considering setting all our drives unavailable, and only using the new tape system if a user needs to deal with labelled tapes. - the rel. 4 archiver is about an order or magnitude too complex. Our local interim archiver had users mark files for archiving by setting a bit in the FDB (same bits as used by BSYS), and also setting a bit corresponding to the directory number in a file on system: (like the bit file used by NMAILR). Then the archiver did for each marked directory do for each marked file do add file to command file The archiver simply made up a command file to dumper. (We added a TAKE command to DUMPER. very easy to do.) There was a second command file (a TAKE file to the EXEC) that deleted the files. All of this meant that everything was under the control of the operator. If anything went wrong, he could back up the tape and rewrite the save set. Or if he lost one of the two archive tapes, he could simply copy the other one. DUMPER was modified to have an ARCHIVE command. ARCHIVE foo was like LIST foo, i.e. it put a listing to file foo. But it also caused the dump to be done in "archive mode". This meant that the names of all files being dumped were appended to the file 20-ARCHIVE.DIR in the directory from which the files came, long with the tape name. ARCHIVE was set only for the second of the two archive tapes. Since we maintained pairs of identical tapes, the tape name refers to the pair, and we only need one name for each file. The only disadvantage of this system is that restoration was manual. (This would be easy to fix. One could add a RESTORE command to the archiver which would look in 20-ARCHIVE.DIR to validate file names, and make up a command file for the restoration.) The disadvantages of the DEC archiver are: - the whole archive/virtual disk system has so many states, modes, and flags that no one understands all of it. - if anything goes wrong during an archive save, the system is so automated that there is nothing you can do about it. You can't position the tape and rewrite a save set, nor can you usefully copy one of two copies of an archive set if you lose one, since they aren't guaranteed to be identical. We are currently working on a program to undo any possible state that archiving can leave you in and allow us to redo it. However I suspect that it might be better just to go back to our old system, possibly with automated retrieval added. ------- 16-Jan-81 15:48:10-EST,931;000000000000 Mail from SU-SCORE rcvd at 16-Jan-81 1547-EST Mail-from: ARPANET site USC-ISID rcvd at 15-Jan-81 2306-PST Date: 15 Jan 1981 1508-PST From: KODA at USC-ISID (Jim Koda) Subject: Re: Magtape problem To: Admin.MRC at SU-SCORE Remailed-date: 16 Jan 1981 1239-PST Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]Tops-20.DIS.61: ; I just want to point out that there is a serious performance deficiency in the way Tops-20 handles magtape skip files. Currently it skip files by skipping 5 records at a time and looking for a tape mark. The newer tape controllers have this function built in. We have modified our system to do this and the speed increase is tremendous. Of course there are systems which do not have skip file controller (e.g. TU45s) but Tops-20 should use the hardware function if its available. I have also sent a SPR suggestion to DEC. /Jim Koda ------- 19-Jan-81 21:16:11-EST,515;000000000000 Mail from SU-SCORE rcvd at 19-Jan-81 2116-EST Date: 19 Jan 1981 1810-PST From: Mark Crispin Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022 Stanford-Phone: (415) 497-1407 Subject: bug in DIRECTORY command To: [SU-SCORE]Tops-20.DIS.61: ; @DIRECTORY, @@NO SEPARATE requires two confirmations and acts like SEPARATE. In EXEC3.MAC, the $$NO table entry for SEPARATE T SEPARATE,ONEWRD,.SEPAR should be T SEPARATE,ONEWRD,.NSEPA instead. ------- 24-Jan-81 17:38:04-EST,972;000000000000 Mail from MIT-MC rcvd at 24-Jan-81 1737-EST Date: 24 Jan 1981 1727-EST From: Roy Marantz Subject: Ethernet protocols To: local-nets at MIT-MC Can anyone tell me (or point me) about the "higher level" protocols being used/developed for use with ethernet? I'd like to know what the availability, advantages, disadvantages, relative cost, relative throughput, development stage, availability of source,.... for these different protocols (and of course their implementations). I've only heard of PUP and CHAOSNET, if there are others I'd like to know. Also since we (read that I) will be implementing one in the near future (as soon as it can be decided which one to do), we (I) are willing to share/cooperate our results with others. At present I am planning to connect 2 DEC-20s (possibly with a single DN-20 with 2 DTEs and no Ethernet), but we have need for PDP-11, IBM, and microcomputer software eventually. Roy ------- 24-Jan-81 22:30:20-EST,6610;000000000000 Mail from MIT-MC rcvd at 24-Jan-81 2229-EST Date: Saturday, 24 January 1981 21:58-EST From: Chris Ryland To: Roy Marantz Reply-to: CPR at MIT-MC Cc: local-nets at MIT-MC Subject: Ethernets, et alia Date: Saturday, 24 January 1981 17:27-EST From: Roy Marantz Re: Ethernet protocols Someone like Dave Clark or Noel Chiappa is probably better suited to reply to parts of this message, but here are my comments for what they're worth. Can anyone tell me (or point me) about the "higher level" protocols being used/developed for use with ethernet? Do you mean old Ethernet itself? These protocols are well-publicized by now, and are nothing more than PARC's various internal protocols; they are only used outside of Xerox at the three grant universities (most heavily at Stanford and CMU), and only as utility protocols (to get to the Dover and IFS, mostly). Not much of interest there; I don't think anyone considers these protocols worth worrying about except as existing workhorses. No word is officially out yet on the plans that various places have for the protocols based on the new Xerox/DEC/Intel (XDI) hardware. Xerox is being pretty closed-mouthed about it (somoene from MIT is going to find out more this week), and the word from DEC is that the hope of actually standardizing (among Xerox, DEC and Intel) on any higher-level protocols is pretty slim, given the incredible difficulty they had agreeing on the hardware level as recently released. What will probably happen is that every manufacturer will have her own protocols based on the new Ethernet hardware, but at least we'll be at first base: the hardware will be (hopefully) standard and various protocols can live peacefully with each other on the hardware base. As far as MIT goes, people generally agree that the Chaosnet hardware will be replaced by the XDI hardware when and if it matures, though the higher-level protocols will probably remain those of Chaos. However, Chaos packets will probably soon be encapsulated in Internet-format packets so Internet and Chaosnet protocols can co:exist on the same cable (this is hardware-independent, really). I'd like to know what the availability, advantages, disadvantages, relative cost, relative throughput, development stage, availability of source,.... for these different protocols (and of course their implementations). I've only heard of PUP and CHAOSNET, if there are others I'd like to know. Well, PUP is actually a family of protocols (EFTP, BSP, etc), based on Xerox's idea of an internet packet format. Chaosnet is also a software packet format, with higher-level protocols not necessarily implied; it turns out that the Chaosnet protocols are not much more than those required to support the Lisp Machines, since they are its raison d'etre (though this doesn't imply any lack of generality, or impossibility of other protocols; currently, (a form of) FTP, ARPA Telnet, SUPDUP and other smaller protocols are supported by the various Chaosnet hosts). The Chaos protocols and supporting software for nearly any machine (the Chaosnet support for VAX/VMS is not in a clear state) are of course totally available to you (they're all publically readable, etc). As mentioned in early Local-Nets mail, the Yale folks are importing the Chaosnet hardware and software for -20's, and eventually for Unices (they have the -20-to-20 hardware and software working). Also since we (read that I) will be implementing one in the near future (as soon as it can be decided which one to do), we (I) are willing to share/cooperate our results with others. At present I am planning to connect 2 DEC-20s (possibly with a single DN-20 with 2 DTEs and no Ethernet), but we have need for PDP-11, IBM, and microcomputer software eventually. If you are just looking for a quick and dirty way for your -20's and Unices to talk to each other, while you (most wisely) wait for the XDI hardware and associated protocols to show up and mature a bit, I would heartily recommend just connecting up your -20's with a null Chaosnet (an 11/34 with two DTE's, which will only run you about $15K if you get a used 11/34 for around $10K (that's what American Used is selling them for in Boston) and the DTEs from Field Circus for about $2.5K each). The software installation probably wouldn't be more than a matter of a week, and you'd end up with full Telnet, mail and file transfer, which is what you probably need to get started. Furthermore, it would be a nice throw-away network to tide you over, since you be wouldn't investing any real effort in it. In the longer run, while you're still (wisely) waiting to see what happens to XDI Ethernet, you could start gearing up for Internet/TCP and its associated protocols. Since some of your machines are ARPA hosts, it makes sense to start worrying about this now anyway, and since the world seems to be going this route, you might as well head in that direction (note that the (IN/TCP-based) CSNet approval pretty much ices the cake, since the DoD has already given notice that the ARPAnet is going IN/TCP by '83). Any IN-based software you build or import (and we have reason to expect growing amounts of this kind of software) is going to have a lengthy life, regardless of the hardware set(s) it runs on. And, the -20 IN/TCP software, as poor as it may be (comes from BBN), does exist, though it needs to be beaten into submission (something which XX is facing right now). Just FYI, DEC has its own in-house effort to implement IN/TCP on the -20; don't know about any higher-level protocols based on it, but I presume they'd supply the standard mail, Telnet, FTP, etc. 3COM, Bob Metcalfe's (Mr. Packet Networks') company, is now selling a Unix implementation of TCP, and BBN has had one for some time. As for your micros, they're probably doomed to be second-class citizens on nearly any of these networks, since you can't expect the interfaces to cost less than $2-4K each for some time to come. Hopefully, someday, somewhere, someone will design a super-cheap interface for the XDI net, but until then... (BTW, there is an effort here at MIT to do something like that for a currently unspecified local network medium so all the students' micros can talk to each other and the larger machines around campus; it's called the campus-net effort; Campus-Net@MIT-MC gets mail to that group.) 25-Jan-81 18:24:10-EST,735;000000000000 Mail from MIT-MC rcvd at 25-Jan-81 1824-EST Date: 25 Jan 1981 1514-PST From: Keith A. Lantz Subject: Re: Ethernet protocols To: MARANTZ at RUTGERS, local-nets at MIT-MC cc: CSL.LANTZ at SU-SCORE In-Reply-To: Your message of 24-Jan-81 1427-PST Rochester and CMU have been working on internetwork IPC protocols. Rochester's is PUP-based, CMU's is INTERNET-based (but running on the Ether). You should request a copy of the respective documents from Feldman@SUMEX-AIM (Attn: Liudvikas Bukys) and Rashid@CMUB. Rochester also had their own homegrown Ethernet protocols (as they had Altos long before Pup was distributed), which might or might not (most probably) be of interest. Keith ------- 26-Jan-81 00:42:41-EST,4568;000000000000 Mail from MIT-MC rcvd at 26-Jan-81 0042-EST Date: 26 Jan 1981 0022-EST From: J. Noel Chiappa Subject: Re: Ethernet protocols To: MARANTZ at RUTGERS, local-nets at MIT-MC cc: JNC at MIT-XX In-Reply-To: Your message of 24-Jan-81 1727-EST CPR already said most everything worth saying, but I'll elaborate a few things he missed. The new XEROX protocols are still XEROX proprietary, and are under tight security. MIT has up to now had no luck prying them out of XEROX for review. It's not certain that we will be told about them. If we get a preview, it is possible we may not be able to spread the info. They will probably be released in a few months, though. Note that the existing XEROX protocols (PUP) (as released to the universities) are incompatible and will be obsoleted. Note also that since DEC and XEROX aren't cooperating, there won't be any one tremendously wide-spread protocol. I'd probably order them (in decreasing strength) X25/IN/SNA/XEROX/DEC... You must be aware that asking questions about the advantages, disadvantages, relative cost and relative throughput of any internetwork protocol is not too useful for anything except the short term at this point, as none have been in service long enough or in enough different environments for any real (as apposed to toy, lab) results. Most aren't even on their second implementation yet. Complete network software is typically larger and almost as sophisticated as the kernel of a system. There is also no operating system that really uses networks, especially the very high bandwidth local networks not coming into service. It interests me that you did not mention the two most wide-spread internet protocols; the X25 family and InterNet. The former, at least, was discussed in this mailing list at some length. People still seem to be missing a vital point; IN and PUP are a FAMILY of protocols based on a common transport layer. Some are datagram based, and there is usually a reliable stream protocol, but all share common addressing and transport layers (gateways and links). However, they provide much more flexibilty to the users than X25, old NCP (HHP) or old CHAOS, which offer (essentially) only streams. Thus, to restate what CPR said, there is a proposal afoot to change CHAOS to run on IN; i.e. to make it one of the family of IN protocols. This is being held up more by manpower considerations than anything else; the technical and political battles are (for a large part) over. CHAOS offers a fairly wide spectrum of protocols, most based on the existing old NCP based ones, and quite general. The only protocol I know of that is LISPM oriented at all is the File Access protocol. Since I am hearing that it will be sometime in '82 before DEC comes up with ETHERNet, you might be interested in a local network interface for PDP11's and other that is about to become commercially available from a small company in Boston called Proteon. I have flamed about this before; to restate what I said then, it was developed by LCS at MIT. It has a 10MBd network interface on a dual DEC board with an 8-bit parallel out, start/end of packet and next byte sort of interface to the second board, a PDP-11 full duplex DMA board with two 2K byte packet buffers. It comes in two pieces to ease construction of other host interfaces; ones for the NuBus and S100 bus are in debug, and others are planned. We have gone through the protoype stage now, and multi-wire versions exist. The manufacturer isn't being stellar, but you ought to be able to convert cash into a working one before the start of the summer (slightly pessimistic). They are accepting PO's now, but unless you're masochistic wait a bit. The current multi-wire has known mis-features (none very bad). Note that the ETEHRNet hardware that 3COM is selling consists of TRANSCEIVERS only. I heard rumors of host interfaces; this, as far as I know, is not so. It's not clear how this relates to small machines. The network interface Proteon is selling is listed at $700 (if I remember right), but the guy who built it claims $1500 for a commercial host interface, $300 for a home-rolled one (you wire the board, etc). MIT will probably hand out the prints for that gratis to non-profit use, but I can't say for sure. Both prices may come down as volume increases. Please people, a lot of this is redundant. Please read the archives (available as CPR;LCLNET MAIL on MC) so that we don't have to repeat ourselves at length. ------- 27-Jan-81 23:33:50-EST,801;000000000000 Mail from SU-SCORE rcvd at 27-Jan-81 2333-EST Date: 27 Jan 1981 2025-PST From: Mark Crispin Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022 Stanford-Phone: (415) 497-1407 Subject: ARPANET access from TIPs To: [SU-SCORE]Tops-20.DIS.62: ; I have had a number of complaints from my users about the unreliability of accessing SCORE from a TIP, and a couple from users at SRI-KL. It has been rumored that the problem happens with other hosts, at least from the SU-TIP and AMES-TIP. Has anybody else had similar difficulties with network access or similar complaints from users? I personally have had no difficulties, although from the console log the network itself does seem to be randomly dropping messages. -- Mark -- ------- 29-Jan-81 23:50:25-EST,1506;000000000000 Mail from SU-SCORE rcvd at 29-Jan-81 2349-EST Date: 29 Jan 1981 2043-PST From: Mark Crispin Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022 Stanford-Phone: (415) 497-1407 Subject: execute-only evasion bug To: [SU-SCORE]Tops-20.DIS.63: ; The following program will let you get a copy of the system EXEC, even if it is protected EXECUTE-ONLY. I am SPR'ing it to DEC. Isn't it amazing what students will discover? -- Mark -- TITLE BUG SEARCH MONSYM A=1 ; AC definitions B=2 C=3 BYTES=10 ; size of EXEC in bytes PAGES=11 ; size of EXEC in pages JFN=12 ; save of output JFN EXJFN==1 ; EXEC's JFN FRSPAG==11 ; first page to map EXEC into BUG: RESET% MOVSI A,(GJ%SHT) ; open out output file MOVE B,[POINT 7,[ASCIZ/COPY-OF-EXEC.EXE/]] GTJFN% 0 MOVEM A,JFN MOVE B,[440000,,OF%WR!OF%RD] OPENF% 0 MOVEI A,EXJFN ; get size of SYSTEM:EXEC.EXE SIZEF% 0 DMOVE BYTES,B ; stash size away MOVSI A,EXJFN ; map EXEC into our address space MOVE B,[.FHSLF,,FRSPAG] HRLI C,(PM%PLD!PM%CPY!PM%CNT!PM%RD) PMAP% IFN 0,< ; This was once thought to be necessary, but isn't MOVEI B,FRSPAG*1000 LOOP: MOVES (B) ; touch all pages for write ADDI B,1000 CAIG B,FRSPAG*1000(BYTES) JRST LOOP >;IFN 0 MOVE A,JFN ; now dump EXEC out MOVE B,[POINT 36,FRSPAG*1000] MOVN C,BYTES SOUT% CLOSF% 0 HRROI A,[ASCIZ/Done /] PSOUT% DONE: HALTF% JRST DONE END BUG ------- 30-Jan-81 18:20:25-EST,684;000000000000 Mail from SU-SCORE rcvd at 30-Jan-81 1820-EST Date: 30 Jan 1981 1511-PST From: Mark Crispin Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022 Stanford-Phone: (415) 497-1407 Subject: NVTs hung in CLZW wait To: [SU-SCORE]Tops-20.DIS.63: ; According to Dale@USC-ISIB, a way around the problem of hung NVT's is to periodically ASND (then RELD if successful) all possible NVTs. SCORE is doing this now and it seems to be effective in sweeping the symptoms under the rug. Of course, this does nothing to cure the disease, but the fact that this works seems to indicate what probably needs to be changed in NVTDET. ------- 2-Feb-81 22:12:40-EST,467;000000000000 Mail from SU-SCORE rcvd at 2-Feb-81 2212-EST Date: 2 Feb 1981 1906-PST From: Mark Crispin Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022 Stanford-Phone: (415) 497-1407 Subject: NVT handling bug To: [SU-SCORE]Tops-20.DIS.66: ; The HRR T2,P1 at IMPTS1 should be a HRRZ T2,P1. This doesn't affect most systems, but systems which have the STDDET paranoia bug check will get upset. -- Mark -- ------- 3-Feb-81 23:14:13-EST,638;000000000000 Mail from SU-SCORE rcvd at 3-Feb-81 2314-EST Mail-from: ARPANET site RAND-AI rcvd at 3-Feb-81 0944-PST Date: 3 Feb 1981 0931-PST From: Geoffrey C Mulligan (at The Pentagon) Subject: Autospeed To: Admin.MRC at SU-SCORE In-Reply-To: Your message of 2-Feb-81 1906-PST Remailed-date: 3 Feb 1981 2005-PST Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]Tops-20.DIS.68: ; I was wondering if anyone has tried to get a 20200 to do auto-speed searching like the 40 50 and 60s seem to do. It seems as though it should be possible to do. Would you know? geoff ------- 5-Feb-81 03:05:20-EST,876;000000000000 Mail from MIT-MC rcvd at 5-Feb-81 0305-EST Date: 5 Feb 1981 0257-EST From: WAGGONER at RUTGERS Subject: Local-Nets mailing list To: local-nets at MIT-MC cc: WAGGONER at RUTGERS Hi, This account represents the OSU DEC-20 site. We are workings on a few projects that are dealing with just that kind of netting. We would be very interested in joining your mailing list. Current projects here are: a loop network (PDP11's and our 20) a database machine (Dr. Hsiao Very Large Databases) which is VAX and PDP11/44's (also the 20 to some degree) and a project just starting that is to run all our terminals into a 'switch' and allow us to connect to any of a number of system. Thsi project is currently just in the planning stages however. Thanks very much. -- Mark -- -- DEC-20 / Database Staff -- -- Ohio State University-- ------- 7-Feb-81 21:38:47-EST,930;000000000000 Mail from SU-SCORE rcvd at 7-Feb-81 2138-EST Mail-from: ARPANET site UTEXAS-20 rcvd at 7-Feb-81 1825-PST Date: 7 Feb 1981 2017-CST From: Clive Dawson Subject: Renaming archived files To: admin.mrc at SU-SCORE Remailed-date: 7 Feb 1981 1833-PST Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]Tops-20.DIS.69: ; Mark, please forward to your hackers list: I discovered a few days ago that it is possible to rename files which have been archived. Does anybody see any rationale for allowing this? If a file is renamed, retrieval will lose unless it is first renamed back to its original name. If the user forgets what the old name is, he loses completely. I will probably get around to fixing (i.e. prohibiting) this, but just wanted to find out if anybody has already done so, or if someone thinks this should be a feature. Clive ------- 8-Feb-81 00:14:02-EST,618;000000000000 Mail from SU-SCORE rcvd at 8-Feb-81 0013-EST Date: 7 Feb 1981 2110-PST From: Mark Crispin Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022 Stanford-Phone: (415) 497-1407 Subject: bug in edit 474 of TV To: [SU-SCORE]Tops-20.DIS.69: ; EDIT 474 to TV, published in the October '80, completely breaks the N command. It causes the first N to do a P, and after that N is just like S. The proper fix is to remove all of edit 474, and at NOFND1+5 after the JRST NOFND2 insert: TXNE FF,FINF ;AT END OF FILE? JRST NOFND2 ;STRING NOT FOUND, PUNT ------- 8-Feb-81 04:34:37-EST,783;000000000000 Mail from MIT-MC rcvd at 8-Feb-81 0434-EST Date: 8 Feb 1981 0125-PST From: Keith A. Lantz Subject: Re: Ethernets, et alia To: CPR at MIT-MC, MARANTZ at RUTGERS cc: local-nets at MIT-MC, CSL.LANTZ at SU-SCORE In-Reply-To: Your message of 24-Jan-81 1918-PST As per "cheap ethernet interfaces" Andy Bechtolsheim and Forest Baskett have (with some assistance) designed a nice Multibus compatible board for the SUN workstations. Parts cost for the board is < $2K. It works with the experimental 3 Mbaud Ethernet, however, but it does work! Send mail to AVB@SU-AI if you're interested. Beyond the interface you can bet that Stanford will have some reasonable networking software for the 68000's before the end of the year. Keith ------- 8-Feb-81 04:45:30-EST,748;000000000000 Mail from MIT-MC rcvd at 8-Feb-81 0445-EST Date: 8 Feb 1981 0138-PST From: Keith A. Lantz Subject: Re: Ethernet protocols To: JNC at MIT-XX, MARANTZ at RUTGERS, local-nets at MIT-MC cc: CSL.LANTZ at SU-SCORE In-Reply-To: Your message of 25-Jan-81 2122-PST Re the comment that "no operating system currently uses networks", RIG has used the Ethernet in particular for years. It is fully integrated and works just fine. You wouldn't want to buy the software, just the ideas. Also, GUARDIAN/EXPAND is the operating system for Tandem and it works just fine too -- ask all of Tandem's customers. If a 26Mbaud "local" bus + network extensions means "using networks" I think they've got it! Keith ------- 9-Feb-81 09:25:31-EST,736;000000000000 Mail from SU-SCORE rcvd at 9-Feb-81 0925-EST Date: 9 Feb 1981 0619-PST From: Mark Crispin Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022 Stanford-Phone: (415) 497-1407 Subject: [SU-SCORE]MRC:MAILBX.MAC.15 To: [SU-SCORE]Tops-20.DIS.69: ; The file [SU-SCORE]MRC:MAILBX.MAC.15 is a version of the MAILBOX program with a couple of TOPS-20 bug fixes and also the capability to recognize long-leader network addresses. Boy is that program ever cretinous!! Would anybody care to rewrite it? In case you don't know what MAILBOX is, it implements mail forwarding of sorts for ARPANET systems. It's an old BBN Tenex special. -- Mark -- ------- 12-Feb-81 03:55:14-EST,930;000000000000 Mail from SU-SCORE rcvd at 12-Feb-81 0355-EST Mail-from: ARPANET site RUTGERS rcvd at 11-Feb-81 1303-PST Date: 11 Feb 1981 1553-EST From: WATROUS at RUTGERS Subject: Erroneous FB%LNG To: Admin.MRC at SU-SCORE Remailed-date: 12 Feb 1981 0047-PST Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]Tops-20.DIS.70: ; Remember the bug in the EXEC's COPY command whereby files which had an even multiple of 512 pages got garbage copied to the next section (and a free FB%LNG)? Well, we have a good suspicion that DUMPER (ugh!) has the same problem (setting FB%LNG after trying to PMAP non-existent pages beyond the end of the real file). Has anyone else found that bug and/or (hopefully) fixed it? If not, I should have a fix for it out soon as we have to get it fixed before we do a disk refresh 2/13/81 0000. Thanks in advance if anyone's beat me to the fix, Don ------- 14-Feb-81 14:00:26-EST,958;000000000000 Mail from MIT-MC rcvd at 14-Feb-81 1400-EST Date: Saturday, 14 February 1981 13:48-EST From: Chris Ryland To: local-nets at MIT-MC Subject: Ethernets, et alia Date: Sunday, 8 February 1981 04:25-EST From: Keith A. Lantz Re: Ethernets, et alia As per "cheap ethernet interfaces" Andy Bechtolsheim and Forest Baskett have (with some assistance) designed a nice Multibus compatible board for the SUN workstations. Parts cost for the board is < $2K. It works with the experimental 3 Mbaud Ethernet, however, but it does work! Send mail to AVB@SU-AI if you're interested. Beyond the interface you can bet that Stanford will have some reasonable networking software for the 68000's before the end of the year. That's great, but what protocols will it use? I presume it won't use TCP/IN, and therefore won't be very portable in a protocol sense. 15-Feb-81 14:54:41-EST,400;000000000000 Mail from MIT-MC rcvd at 15-Feb-81 1454-EST Date: 15 February 1981 14:50-EST From: Earl A. Killian Subject: Ethernets, et alia To: CSL.LANTZ at SU-SCORE cc: LOCAL-NETS at MIT-MC Parts cost is around $2K? That's pretty high. I believe the parts cost of a chaosnet board is fair bit less than $1K. If you mean that the finished cost is less than $2K, that's different. 16-Feb-81 00:23:24-EST,310;000000000000 Mail from MIT-MC rcvd at 16-Feb-81 0023-EST Date: 15 Feb 1981 2219-MST From: Randy Frank Subject: Ampex memory To: twenex-wizards at MIT-MC Has anyone put Ampex MOS memory on their KL processor?? I'd be interested in experience (or the names of people with experience). ------- 16-Feb-81 22:15:35-EST,2814;000000000001 Mail from MIT-MC rcvd at 16-Feb-81 2215-EST Date: 15 Feb 1981 2118-PST From: Vaughan Pratt Subject: SUN Ethernet interface To: local-nets at MIT-MC A more accurate figure for the parts cost of the SUN (Stanford University Network) Ethernet interface is $800. The following three paragraphs come from a writeup of the board, available from AVB@SAIL. This is an Intel Multibus compatible board for a 3 Mb Ethernet supplying all functions of the Ethernet data link and physical layer, namely: - data encapsulation (framing, addressing, checksum) - link management (channel allocation and contention resolution) - channel access (bit transmission, carrier sense, collision detection) - packet buffering (storing packets being sent or received) - exception reporting (failure to send a message, receipt of bad messages) - address recognition (can specify any subset of 256 addresses) - data encoding (preamble generation, phase encoding) In addition it offers: - back-to-back packets (no refractory period) - loopback (can receive packets it transmits) - 32-Mbaud bus rate (16 bits per 0.5 usec, so needing only 10% of an 8MHz 68k) - 4 kbyte buffer (tolerates host latency of 2 kbyte, i.e. 5 msecs) In short, you supply/receive unencapsulated packets at your reasonable convenience and at your speed, it does the rest. This board is one of the (currently) seven board types used in the implementation of the various nodes of the SUN network, all of which are Intel Multibus boards, physically, electrically, and logically. The other board types are: CPU (M68k, 2-level map, 256 kbyte onboard memory, full 8 MHz, 2xUART, timer) Offboard Memory Graphics Controller (novel design permits blt'ing in x OR y direction!) Graphics Memory (128 kbyte) Communications Interface (commercial 8-uart board) Disk Controller (commercial) These boards assemble in various combinations to produce the following SUN nodes: Ethertip EI+CPU+4xCI Gateway 2xEI+CPU File Server EI+CPU+DC Small Personal Computer EI+CPU Large Personal Computer EI+CPU+OM+GC+GM Home Computer CPU+DC (linked to network via CPU.UART2 + telco) etc. Only prototypes of the non-commercial boards presently exist. The Ethernet to which the above will be initially attached carries mainly Pup traffic between a KL-10 (Sail), 3 Vaxes running Berkeley Unix, a Dover printer, a file server, and something like a dozen and a half Altos, plus a pending connection to a 20/60 (Score). There are also other networks at Stanford, as observed in an earlier message, which will hopefully all be connected with gateways when the hardware and software are available. Once things have settled down IP/TCP will be either imported if available or generated locally. ------- 16-Feb-81 22:27:02-EST,479;000000000000 Mail from MIT-MC rcvd at 16-Feb-81 2226-EST Date: 14 Feb 1981 1157-PST From: Keith A. Lantz Subject: Stanford Ethernet board To: local-nets at MIT-MC The Stanford Ethernet board implements the data link layer protocols. It couldn't care less what internet protocols you use. Hence, it is as portable as the Dec/Intel/Xerox chip will be and can be reconfigured eventually to support the 10MBaud Ethernet rather than 3MBaud. Keith ------- 16-Feb-81 22:38:04-EST,456;000000000000 Mail from MIT-MC rcvd at 16-Feb-81 2238-EST Date: 15 Feb 1981 1441-PST From: Keith A. Lantz Subject: Re: Ethernets, et alia To: EAK at MIT-MC cc: LOCAL-NETS at MIT-MC, CSL.LANTZ at SU-SCORE In-Reply-To: Your message of 15-Feb-81 1150-PST Look guys, if you care about the Ethernet board, talk with Andy Bechtolsheim (AVB@SU-AI). I have obviously got your interest, but I am not up on the figures. Keith ------- 18-Feb-81 13:20:15-EST,547;000000000000 Mail from MIT-MC rcvd at 18-Feb-81 1320-EST Date: 18 Feb 1981 0953-PST From: MIKE at RAND-AI Subject: Update on connecting to 20's To: local-nets at MIT-MC We at Rand have an urgent need to connect our 20 to some UNIX systems. I'd like an update from anyone out there with some knowledge on what currently exists to allow a high-bandwidth connection, and what is being worked on now for that purpose (ie, 3Mbit ethernet at Stanford, Chaosnet at Mit, etc). Anyone done a lot of work with DECNET? Thanks Michael Wahrman ------- 23-Feb-81 05:21:38-EST,1073;000000000000 Mail from SU-SCORE rcvd at 23-Feb-81 0521-EST Mail-from: ARPANET site RAND-AI rcvd at 18-Feb-81 0943-PST Date: 18 Feb 1981 0942-PST From: MIKE at RAND-AI Subject: 20 to 10 Mailing (phone line) mailing systems To: admin.mrc at SU-SCORE cc: mike at RAND-AI Remailed-date: 23 Feb 1981 0217-PST Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]Tops-20.DIS.70: ; Mark, Please pass this on to your list, if appropriate. Problem: We want to pass mail daily from our tops-20 to a tops-10 in the LA area. The only connection is via telephone lines. Now, were this a UNIX system, a mere minicomputer operating system, we would have UUCP which could automatically call any other UNIX system daily and transfer mail. Is there such a system for the 10's and 20's? (PS. This system should make use of an autodialer, the phone lines will not be dedicated to this purpose). (PPS. Another possibility is UUCP for a 10, in which case our UNIX system could call the 10.) Many thanks, Michael Wahrman ------- 23-Feb-81 12:58:33-EST,354;000000000000 Mail from MIT-MC rcvd at 23-Feb-81 1258-EST Date: 23 Feb 1981 1046-MST From: Randy Frank Subject: COMNDizing FTP To: twenex-wizards at MIT-MC We're considering biting the bullet and COMNDizing user FTP. Before we dive in, we want to make sure no one else has started such a project. If you have, plz let me know. ------- 23-Feb-81 14:03:35-EST,1381;000000000000 Mail from MIT-MC rcvd at 23-Feb-81 1403-EST Date: 23 Feb 1981 1356-EST From: TAPPAN at BBND (Dan Tappan) Subject: User FTP Feature To: Twenex-Wizards at MC Description: When making a connection to a machine running TOPS20, FTP Defaults to 8 bit bytes (rather than 36 bit paged) Cause: The latest Host tables now describe 20x hosts as TOPS20 instead of TENEX, FTP doesn't know about this system type so defaults to the default, screwing things up Fix: Make FTP know about TOPS20 and treat as 10x. Comparision follows: (Note that anyone running TENEX needs this fix also) ; FTP.MAC.13 & FTP.MAC.12 23-Feb-81 1318 PAGE 1 LINE 1, PAGE 1 1) ;FTP.MAC.13, 26-Nov-80 15:43:18, Edit by TAPPAN 1) ; Recognize TOPS20 as a system type 1) TITLE FTP - USER HALF OF THE FILE TRANSFER PROTOCOL LINE 1, PAGE 1 2) 2) TITLE FTP - USER HALF OF THE FILE TRANSFER PROTOCOL LINE 30, PAGE 2 1) OPST20==11B8 ; Site runs tops20 1) LINE 30, PAGE 2 2) LINE 37, PAGE 16 1) CAIE A,(OPST20) ; Same for Tops20's 1) CAIN A,(OPST10) ;SAME FOR TOPS10 SYSTEMS LINE 37, PAGE 16 2) CAIN A,(OPST10) ;SAME FOR TOPS10 SYSTEMS LINE 42, PAGE 16 1) CAIE A,(OPST20) ; TOPS20 PAGED 1) CAIN A,(OPS10X) ;IMAGE IF 36 UNLESS 10X, THEN PAGED. LINE 41, PAGE 16 2) CAIN A,(OPS10X) ;IMAGE IF 36 UNLESS 10X, THEN PAGED.  ------- 23-Feb-81 18:13:05-EST,1548;000000000000 Mail from SU-SCORE rcvd at 23-Feb-81 1812-EST Date: 23 Feb 1981 1502-PST From: Mark Crispin Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022 Stanford-Phone: (415) 497-1407 Subject: [Chris Ryland : Can you forward this to people to see if anyone has fixed these?] To: [SU-SCORE]Tops-20.DIS.70: ; I am not convinced that the first complaint is a bug; isn't TTY: translated into the appropriate TTYnn:? At least the behavior isn't totally unexpected or unreasonable. The second complaint is obviously specific to MIT. --------------- Mail-from: ARPANET site MIT-AI rcvd at 23-Feb-81 1148-PST Date: Monday, 23 February 1981 14:45-EST From: Chris Ryland To: Admin.MRC at SU-SCORE Subject: Can you forward this to people to see if anyone has fixed these? Date: Monday, 23 February 1981 11:39-EST From: RWS at MIT-XX To: bug-twenex at MIT-XX Re: longstanding Rel. 4 terminal jfn bugs If you have an explicit jfn to TTY: and you attach to a different terminal, RFMOD and SFMOD (and possibly others) give "line is not active" errors. This was not true under Release 3. If you open two jfns to a terminal without assigning it, when you close one of the jfns, IDLSRV prematurely gets the terminal back, and it becomes impossible to close or release the other jfn. Resetting the fork fails to get rid of itt, as does EXEC's CLOSE command; you have to log out. --------------- ------- 23-Feb-81 18:14:41-EST,936;000000000000 Mail from MIT-MC rcvd at 23-Feb-81 1814-EST Date: 23 Feb 1981 1456-PST From: Mark Crispin Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022 Stanford-Phone: (415) 497-1407 Subject: Re: COMNDizing FTP To: FRANK at UTAH-20, twenex-wizards at MIT-MC In-Reply-To: Your message of 23-Feb-81 0946-PST I have started on a complete rewrite of user FTP (ala my TELNET) which will have the multiple network support, etc. In other notes about TELNET, coming up soon are: TCP/IN TELNET support (BBN style, DEC style too as soon as there is a system running it to debug on) SU-NET support (essentially Ethernet + Chaosnet routing) Local host padding option (Ann Arbors, VT100's, etc.) Option to use the DECnet TTY/DCN tie-in facility VAX DECnet TELNET support There is a possibility that DEC will distribute TELNET in a forthcoming release of TOPS-20. -- Mark -- ------- 23-Feb-81 22:04:37-EST,597;000000000000 Mail from MIT-MC rcvd at 23-Feb-81 2204-EST Date: 23 Feb 1981 2056-CST From: Edward C. Pattermann Subject: Autobaud To: twenex-wizards at MIT-MC Has anyone written a autobaud program for a 20. I'm talking about one that autobauds up to 9600 baud. What I am thinking of is a daemon that grabs the line you want to autobaud on, waits for a character, reads the character and then decides what baud rate you are on and sets your line appropriately. Anyone heard of such a beast? If not, I'm embarking on it soon ... Thanks for considering, Ed ------- 24-Feb-81 12:41:48-EST,444;000000000000 Mail from MIT-MC rcvd at 24-Feb-81 1241-EST Date: 24 Feb 1981 0925-PST From: LARSON at SRI-KL Subject: Re: Autobaud To: G.ECP at UTEXAS-20, twenex-wizards at MIT-MC In-Reply-To: Your message of 23-Feb-81 1856-PST Yes, I heard about it at the last DECUS. It works only with ^C as the recognition character, and had to be done in the front end. The system had to be quite restrictive to get the wide speed range. Alan ------- 24-Feb-81 15:10:05-EST,1640;000000000000 Mail from MIT-MC rcvd at 24-Feb-81 1509-EST Date: 24 Feb 1981 1451-EST From: David Richard Lyons To: LARSON at SRI-KL, G.ECP at UTEXAS-20, twenex-wizards at MIT-MC Subject: Re: Autobaud Message-ID: In-reply-to: Message from LARSON at SRI-KL of 24-Feb-81 1225-EST The decision to only recognize on ^C had nothing to do with getting the larger range. That crock was done to save room by not having the Autobaud tables large and containing many different chars. The extra space buys more thruput for those who have 128 lines and 2 lpts and a card (what are cards) reader. The code was a direct steal from the DN87 (ANF10) code, and that will work on , <^c>, <,>, and a few others. It is true that ^c is a particularly bad choice for an autobaud char, and <,> have much better bit patterns. The speed range is not all that great, but I believe it is the most one can get from a single byte and still cover 110, 150, 300 and 1200 baud. ANF also get 134 for those of you who just love your 2741. If two bytes were allowed, there would be no reason not to cover all the way up to 9600 baud, but again, that would cost about 200-300 bytes of buffer space. The problem with 9600 baud is that open (and ringing) lines will kill you. Any noise on the line (i.e. from the last send all) will look like a 9600 ^C on the input side. This is only a problem with long lines running at 9600/9600 and unterminated. When the system types the greeting, that will cause more false input, and things get worse from there. -------- 25-Feb-81 18:40:04-EST,524;000000000000 Mail from MIT-MC rcvd at 25-Feb-81 1839-EST Date: 25 Feb 1981 1524-PST Sender: CERF at USC-ISI Subject: Re: COMNDizing FTP From: CERF at USC-ISI To: Admin.MRC at SU-SCORE Cc: FRANK at UTAH-20, twenex-wizards at MIT-MC Message-ID: <[USC-ISI]25-Feb-81 15:24:43.CERF> In-Reply-To: Your message of 23 Feb 1981 1456-PST Mark, thanks for the update on TCP/IP - DEC says they will support their version in release 5 of TOPS-20; BBN will help verify correct operation of the TCP and IP peer protocols. Vint Cerf 25-Feb-81 18:48:35-EST,361;000000000000 Mail from MIT-MC rcvd at 25-Feb-81 1848-EST Date: 25 Feb 1981 1542-PST From: Harris A. Meyers Subject: Re: COMNDizing FTP To: CERF at USC-ISI, Admin.MRC at SU-SCORE cc: FRANK at UTAH-20, twenex-wizards at MIT-MC In-Reply-To: Your message of 25-Feb-81 1524-PST Did DEC say when the expect Release 5 to come out? harris ------- 25-Feb-81 19:37:25-EST,933;000000000000 Mail from MIT-MC rcvd at 25-Feb-81 1937-EST Date: 25 Feb 1981 1624-PST Sender: CERF at USC-ISI Subject: Re: COMNDizing FTP From: CERF at USC-ISI To: Meyers at SRI-KL Cc: CERF, Admin.MRC at SU-SCORE, FRANK at UTAH-20, Cc: twenex-wizards at MIT-MC Message-ID: <[USC-ISI]25-Feb-81 16:24:07.CERF> In-Reply-To: Your message of 25 Feb 1981 1542-PST Roughly in early 1982. Vint Date: 25 Feb 1981 1606-PST From: CERF at USC-ISI To: Popek at UCLA-SECURITY Cc: Cerf Subject: Re: LOCUS performance update In-Reply-To: Your message of 24 Feb 1981 1945-PST (Tuesday) Message-ID: <[USC-ISI]25-Feb-81 16:06:07.CERF> Sender: CERF at USC-ISI Jerry, what kind of data rate do your results correspond to? Vint -------------------- P.S. Early release to alpha test sites could probably happen sooner. Have you seen the DEC proposal - ISI had many comments on its merits and deficiencies. vint 25-Feb-81 20:00:39-EST,2078;000000000000 Mail from SU-SCORE rcvd at 25-Feb-81 2000-EST Mail-from: ARPANET site UTAH-20 rcvd at 24-Feb-81 1401-PST Date: 24 Feb 1981 1419-MST From: Randy Frank Subject: Scheduler patch to fix NBSWP problem To: admin.mrc at SU-SCORE Remailed-date: 25 Feb 1981 1647-PST Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.71: ; The following patch is from Dan Murphy at DEC: Under very heavy load, NBSWP (scheduler variable counting number of processes in balset wait) is not properly decremented. In therefore become permanently non-zero, causing all future idle time to be billed to balset wait time. This appears to the naive user as very large WAIT times and very low IDLE times in monitor statistics. In SCHED.MAC: ; SCHED.MAC.3 & SCHED.MAC.2 18-Feb-81 2134 PAGE 1 LINE 1, PAGE 1 1) ;PS:<4.MONITOR-SOURCES>SCHED.MAC.3 18-Feb-81 21:32:59, Edit by FRANK 1) ;FIX NBSWP NOT BEING DECREMENTED PROPERLY (TCO 5.1198) 1) ;PS:<4-MONITOR-SOURCES>SCHED.MAC.2, 16-Feb-80 18:17:08, Edit by FRANK LINE 1, PAGE 1 2) ;PS:<4-MONITOR-SOURCES>SCHED.MAC.2, 16-Feb-80 18:17:08, Edit by FRANK LINE 10, PAGE 38 1) JRST SKDJS2 ;AND WAIT SOME MORE 1) CAIE 1,SWPINT ;WAS BEING LOADED? LINE 10, PAGE 38 2) JRST [ SOS NBSWP ;YES. ONE LESS IN SWAP WAIT 2) JRST SKDJS2] ;AND WAIT SOME MORE 2) CAIE 1,SWPINT ;WAS BEING LOADED? LINE 9, PAGE 39 1) CAIN T2,PRELWT ;PRELOAD WAIT?? 1) JRST DISAC2 ;YES, HANDLE LIKE SWAP WAITS 1) CAIE 2,SWPINT ;SWAPIN? 1) CAIN 2,SWPRT ;OR SWAP? 1) DISAC2: JRST [ ADDM T1,DRMWT ;YES, CHARGE TO DRUM 1) SOS NBSWP ;REDUCE COUNT OF SWAP WAITS LINE 9, PAGE 39 2) CAIE 2,SWPINT ;SWAPIN? 2) CAIN 2,SWPRT ;OR SWAP? 2) JRST [ ADDM T1,DRMWT ;YES, CHARGE TO DRUM 2) SOS NBSWP ;REDUCE COUNT OF SWAP WAITS (P.S. AS I SAID ABOVE, THIS PATCH IS DUE TO DAN MURPHY'S WIZARDRY. I DON'T TOTALLY UNDERSTAND WHY IT WORKS AND THE PREVIOUS METHOD SCREWS UP, BUT IT LOOKS LIKE IT FIXES SOME SORT OF RACE CONDITION IN THE SCHEDULER) ------- 25-Feb-81 22:38:41-EST,5286;000000000000 Mail from MIT-MC rcvd at 25-Feb-81 2238-EST Date: 25 Feb 1981 2011-MST From: Randy Frank Subject: Building an Erector Set DN20 To: twenex-wizards at MIT-MC, b-smith at USC-ISIB Building an Erector Set DN20 We have just finished putting together our second "erector set" DN20. Several people have asked for the "recipe", so here it goes: A DN20, for those who don't know, is a secondary front-end PDP 11/34 for a DEC 20. (One can have up to three DN20 secondary front-ends on a KL, in addition to the 11/40 primary front-end). At Utah, we have one DN20 running X.25 connecting us to Telenet, and another driving a Versatec plotter and a Mergenthaler photocomposer (it also acts as the "rasterizer" for the Versatec, thus off-loading that CPU-intensive activity from the KL). The current price for a DN20 from DEC (including a "pretty" orange cabinet) is about $35K. One can cut the price at least in half by putting one together from the component pieces (assuming one is willing to give up the pretty orange cabinet! -- we install ours in standard "short" PDP-11 cabinets, which look fine). The following list gives the component pieces of a DN20, our normal sources, and price estimates. There are a few pieces that are difficult to get from DEC; our field service organization has been helpful in acquiring them (for a price). Component suggested sources price estimate PDP 11/34A CPU (no memory) (used) Newman Computer, other $8K-$10K (1) user vendors 128KW PDP-11 memory favorite memory vendor $2.5K Data Ten Eleven Boards (DTE) DEC Customer spares $2.5K M873-YJ bootstrap DEC Customer spares $1K (2) M9306 terminator DEC Customer spares $150 (2) M9310 terminator-remote power DEC Customer spares $250 (2) BC-11A 25foot Unibus cable DEC $200 PDP 11 short cabinet $1.5K Remote power/doorbell cable build yourself (3) total apx.$16K-$18K Notes: (1) you may be able to save some money by getting the 11/34 without the standard M9301 or M9312 bootstrap, both of which are useless for a DN20. You should pay the extra money for an 11/34 with the programmer panel (lights and push-button switches). Among other things, it lowers maintenance costs! (2) Bootstraping/termination is very funny on a DN20. Normal CPU end termination is usually done by a M9301 or M9312 bootstrap (a dual-high A/B card). On a DN20, you need a M873-JY bootstrap, a quad high SPC card. This mean you need to get a CPU-end "terminator minus bootstrap", which is what the M9306 is. At the end of the Unibus, you normally terminate with a M9302 terminator; on a DN20, this termination occurs inside the DTE Unibus block in the KL. Unfortunately, there is no +5 volts, so you must use a special version of the M9302 called the M9310 (Unibus terminator-Remote power). This terminator has faston tabs for supplying +5 Volts, which must be cabled over from the PDP 11/34 power supply! We have had great difficulty in getting some of these funny terminators and bootstraps (in particular the M9306). We finally got our local field service organization to help. Without the help of your field service organization, doing an erector set DN20 may be difficult. If you have trouble getting the M9306, we believe that one can convert a standard M930 (old style) terminator (the little short ones) by cutting a few traces. If you have to do this I can give you more info (we almost had to do this, but our M9306 finally arrived!) As an aside, once together, the local field service organization considers this unit as a garden variety DN20 for maintenance contract purposes (it is, except for the lack of an orange cabinet!) (3) There is one cable we have been unable to buy from DEC, and we've had no problem building ourself. It is the (combined) cable from the 11/34 to the KL which provide remote power to the terminator (above) and also acts as the "doorbell" cable from the KL to the M873-YJ bootstrap (telling the bootstrap to boot); this is the way that the KL starts a front-end. If you decide to go this erector set approach, I can send you a drawing of this cable. Summary: Building an erector set DN20 can save substantial bucks, but you must be prepared to play scavenger. Don't assume that you can get some of the component pieces overnight -- allow yourself months to get some of them. However, even with the difficulty of getting some of these parts, delivery is often better than an assembled DN20 from DEC. You might also want to determine if your DEC field service will consider your "kit" acceptable for field service -- that might affect your decision as to which way to go. ------- 26-Feb-81 03:34:22-EST,3070;000000000000 Mail from SU-SCORE rcvd at 26-Feb-81 0333-EST Mail-from: ARPANET site RUTGERS rcvd at 12-Feb-81 1749-PST Date: 12 Feb 1981 2038-EST From: WATROUS at RUTGERS Subject: DUMPER bug which creates long files To: Admin.MRC at SU-SCORE Remailed-date: 26 Feb 1981 0027-PST Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.72: ; Problem: Files which are not long files but contain page 511 become long files when restored to disk with DUMPER. Diagnosis: DUMPER relies on a SKIP on a non-existent page mapped from the file failing in order to determine that the page does not exist in that file. This works when the process page is in fact mapped to a non-existent page in the file. When the PMAP passes page 511 for a file without FB%LNG set, the PMAP fails with LNGFX1 and pages beyond 511 do not get mapped. The SKIP in this case creates a private page which DUMPER thinks is page 512 and saves it. These pages get restored when the file is restored to disk, thus creating long files. Solution: Trap this failure in PMAP and temporarily shrink the buffer so DUMPER won't look at the non-mapped buffer pages. File 1) N:DUMPER.MAC created: 1758 12-Feb-1981 File 2) O:DUMPER.MAC created: 2023 27-Jan-1981 1)13 bufsiz==10 ; number of pages in window 1) NBUF: bufsiz ;SIZE OF FILE WINDOW AT BUF0 1) INIPDL: IOWD NPDL,PDL ;INITIAL PUSH DOWN LIST **** 2)13 NBUF: 10 ;SIZE OF FILE WINDOW AT BUF0 2) INIPDL: IOWD NPDL,PDL ;INITIAL PUSH DOWN LIST ************** 1)46 movx c,pm%rd!pm%pld!pm%cnt+bufsiz ; bits and buffer size 1) hrrzm c,nbuf ; reset window size here, too 1) PMAP 1) erjmp dmpl4a ; handle PMAP failures 1) ;MAKE SURE THE PAGE WE ARE ABOUT TO DUMP EXISTS **** 2)46 MOVX C,PM%RD!PM%PLD!PM%CNT 2) HRR C,NBUF ;NUMBER OF PAGES TO MAP 2) PMAP 2) ERJMP DMPL4 ;IN CASE NON-EX PT 2) ;MAKE SURE THE PAGE WE ARE ABOUT TO DUMP EXISTS ************** 1)46 ; here when PMAP fails 1) dmpl4a: movei a,.fhslf ; get our last error 1) geter 1) hrrz a,b ; just error in a 1) caie a,lngfx1 ; Page table does not exist? 1) jrst dmpl4b ; no 1) hrrz a,lastid ; yes, get next section boundary 1) trz a,777 1) addi a,1000 1) hrrz c,lastid ; subtract starting page 1) sub a,c 1) movem a,nbuf ; save mapped buffer size 1) caie a,1000 ; if whole section 1) jrst dmpl2 ; not, go continue dumping 1) jrst dmpl4 ; yes, go do FFUFP 1) ;dmpl4 won't handle PMAP failure right under all circumstances anyway 1) dmpl4b: btmsgc 1) hrroi b,nambuf 1) call btmsgq ; filespec 1) btmsg < 1) > 1) jrst dmplux ; punt 1) ;HERE WHEN CURRENT PAGE CANNOT BE ACCESSED (SKIP ERJMP'ED) **** 2)46 ;HERE WHEN CURRENT PAGE CANNOT BE ACCESSED (SKIP ERJMP'ED) ************** 1)50 move c,[pm%cnt+bufsiz] ; set number of pages 1) hrrzm c,nbuf ; and reinitialize it here 1) PMAP ;REMOVE THEM **** 2)50 MOVX C,PM%CNT ;SET NUMBER OF PAGES 2) HRR C,NBUF 2) PMAP ;REMOVE THEM ************** ------- 26-Feb-81 19:29:26-EST,6662;000000000000 Mail from MIT-MC rcvd at 26-Feb-81 1928-EST Date: 26 Feb 1981 1602-PST From: Frank da Cruz Subject: DECnet vs ARPAnet vs CSnet vs local nets (a long flame) To: Local-Nets at MIT-MC cc: G.DACRUZ at SU-SCORE I've been following the local nets mail with some dismay; the overwhelming impression is that there are dozens of sites out there, all investing prodigious amounts of hacker power - & thus presumably money - in home-grown, mutually incompatible local nets. Some of them work, some "almost" work. All of them seem to depend on a small cadre of hackers. If your local net hacker disappears, you're likely to be stuck with a horribly complicated mess that "almost" works, thatis most likely totally undocumented, and probably impossible to modify or debug. The CS sites that were lucky enough to be the beneficiaries of Xerox's largesse - Ethernet, Altos, Dovers - seem to have fared best (despite having a heck of a time getting their own computers to cooperate), and this is most likely because a large (greedy?) corporation had a vital interest in testing these things out. One "local"network that has worked very nicely for some time is ARPAnet. Local (intra-site) communication has been a happy by-product of the general design of the network. I don't know a lot about these things, but I'll bet some high proportion of an IMP's work - especially at some universities - is sending packets around between local hosts. In any case, ARPAnet is fine for those who can get on it, but it may have stalled the progress in the area of local networking because the sites that may have been most likely to do research in that area always had the ARPAnet to provide for their local communication needs. At Columbia, where we have mostly DEC & IBM computers, we have hankered after local networks for years, but have been reluctant to grow our own because of the Ephemeral Hacker syndrome (though if we had ever received funding for such a venture, I'm sure we would have plunged into it happily). When we bought our first -20 in 1977, we also got DECnet in hopes that it might allow us to tie some of the PDP-11's on campus to the central facility. It was 2 1/2 years before the first packet was successfully transfered. We have been laughing up our sleeves at DECnet for so long that it's hard to break the habit. Our record was so abysmal that we were never able to get a single campus lab or department to join us, even though there are hundreds of -11's out there, and a growing number of VAXes. But we didn't give up; when we got our second -20, we DECnetted it to the first one, and imagine our surprise when - after some initial screwups - it worked like a dream. It does file transfer, mail, virtual terminal service, finger, most of what you want (many of these are hacks but what network isn't full of hacks?). The only major drawback is that only adjacent nodes can communicate, but this restriction will be lifted in the next release (due for field test in a month or two). At Columbia, and at some other sites, DECnet is serving very nicely as a local network. I recently read the plans for CSnet. I understand that CSnet has grown out of frustration in the CS community at the exclusiveness of ARPAnet. The CSnet folks want to reimplement ARPAnet nearly from the ground up, piggybacking on a public commercial packet network like TELENET, and opening it up to all PhD-granting CS departments. This is a fine idea. But the initial plan calls for support only for DEC computers: DEC-20's, VAXes, and big -11's - the very machines that DECnet runs on! (Note - no -10's.) Of course, they're not interested in DEC's operating systems for the -11's & VAXes, sticking strictly to UNIX. I suppose that makes good sense for -11's (name a good DEC operating system that runs on -11's). But can't you run UNIX "under" VMS (Eunice?). It might be worth considering when you get DECnet as a bonus. The real catch here is the cost. Not only is DECnet expensive to use locally (DN20's are running over $35,000; a TOPS-20 DECnet license is $5800). But what's the alternative? A hacked-up, homegrown, incompatible, almost-working arrangement that probably costs more in the long than the ransom you pay for DECnet, and that may not work as well. And what if you want to connect your local net to someone else's? Build a gateway? If both nets happen to be DECnet, you probably just need a wire. The phone company can provide you with a 9600 baud leased line in about 30 days, and the monthly cost is not bad for moderate distances (like across a state or two) - several hundred dollars. For longer distances - well, within a year or so, DECnet will support X.25 communication and will be able to use TELENET as a backbone: 9600 baud access to the entire network for $1100/month, 56Kb for $2100/month. Seems like this does everything CSnet would have done, at about the same cost (maybe less - depends on who's paying), and provides for local communications at the same time. And it's all supported. And most of it's available right now or in the very near future; no need to wait 3-5 years for CSnet. By the way, CSnet would probably be much nicer than DECnet, since it's built on internet protocols, possibly allowing interconnection with all sorts of other nets, but I wonder if it will survive the budget axe?... Anyway, as we all know from the trade papers, DEC & Xerox are cooperating on Ethernet. DEC fully intends to make Ethernet a part of DECnet, so that local high bandwidth communication, complete with typesetters, personal computers, etc, will be taken care of too. What about non-DEC hosts? Well, every day you hear of another vendor who has succumbed to Ethernet mania - HP, Zilog, Nixdorf (who?)- not to mention Xerox itself (did you hear about the Executive Workstation?) - let's hope that all sorts of gadgets will fit on the local DEC/Ethernet. And for IBM, well, there's always RJE (and what's this I hear about Stanford CIT having a DECnet/IBM channel interface running in a little -11?). Sure DECnet is ugly & yucchhy & expensive. But it works, and it's all supported. Wouldn't you rather holler at DEC when things are broken than have your users yelling at you (just when your hacker - bored with the mundane details of "finishing touches", documentation, etc - has left you with an almost working local net to work on something more fulfilling)? Sorry for the extended flame. This all came to me in a dream. Am I crazy? - Frank da Cruz, Columbia U. ------- 26-Feb-81 21:36:43-EST,2518;000000000000 Mail from MIT-MC rcvd at 26-Feb-81 2136-EST Date: 26 Feb 1981 2120-EST From: J. Noel Chiappa Subject: Re: DECnet vs ARPAnet vs CSnet vs local nets (a long flame) To: G.DACRUZ at SU-SCORE, Local-Nets at MIT-MC cc: JNC at MIT-XX In-Reply-To: Your message of 26-Feb-81 1923-EST Flame on: Yes, probably. DECNet is not supported by anybody that I know of except DEC. If you have an 11, and don't want to run a crappy DEC OS, you get to implement DECNet all over. Of course, no other manufacturer supports it. DECNet also has significant problems in terms of long haul usage since all traffic must flow through intervening computers, unless you regenerate the ARPANet with special forwarding nodes. I won't go into the rest of the technical details. The Xerox grant stuff wasn't as wonderful as it seems. At Stanford and Rochester, they simply adopted PUPs as their local protocol. At MIT, where there is significant competition from other protocols (NCP, CHAOS, IN, etc....) PUPs have been more or less confined to the EtherNet and the original Xerox software. We got the the Altos to talk to the rest of the world by implemeting IN on Altos. CSNet is a Mom, God & Apple Pie number. It will do good things for everyone easily. Can I interest you in the Brooklyn Bridge? Also, "gateways" are the Finagle's Constants of networking. A magic box that magicaly appears that will connect ANYTHING to ANYTHING. Right. And if you think the fact that your Xerox printer (running OIS) and you DEC20 (running DECNet) both plug into the same wire means anything, I've got some great land in Florida for you. This is all true for a whole slew of reasons that I don't want to get into. If you want to find out why, spend a few years building network conglomerations. If that seems like a cheap elitist weasel out, sorry, but it's true. Most of what I learned about networks I learned by doing it wrong at least once, which unfortunately seems like the only way. Flame off: As always, the main problem is that no one protocol will let you talk to EVERYBODY, and providing the right magic so that the users don't have to get into the grubby details of "well, foo implements a, and bar implements b, but zap implements both a and b and you can go through him" is almost impossible except on a case by case basis, which rapidly gets into a n^2 problem. Standardising on a single protocol is a good idea, but I don't think DECNet is the one. Noel ------- 26-Feb-81 21:48:43-EST,3045;000000000000 Mail from MIT-MC rcvd at 26-Feb-81 2148-EST Date: Thursday, 26 February 1981 21:22-EST From: Chris Ryland To: twenex-wizards at MIT-MC Reply-to: CPR at MIT-MC Cc: b-smith at USC-ISIB Subject: Building an Erector Set DN20 Some comments on Randy's notes, from our experience. We have had great difficulty in getting some of these funny terminators and bootstraps (in particular the M9306). We finally got our local field service organization to help. Without the help of your field service organization, doing an erector set DN20 may be difficult. If you have trouble getting the M9306, we believe that one can convert a standard M930 (old style) terminator (the little short ones) by cutting a few traces. If you have to do this I can give you more info (we almost had to do this, but our M9306 finally arrived!) Well, if your local field circus is helpful, you should have NO trouble getting any of these parts, including the more obscure ones, since they (obviously) have full access to a complete spares set for real DN20s. We got our parts in two days (except for the -11) by simply having our FE deliver them as "replacement parts". (Of course, they've learned their lesson now, and want a P.O. before they'll give us the parts...) (3) There is one cable we have been unable to buy from DEC, and we've had no problem building ourself. It is the (combined) cable from the 11/34 to the KL which provide remote power to the terminator (above) and also acts as the "doorbell" cable from the KL to the M873-YJ bootstrap (telling the bootstrap to boot); this is the way that the KL starts a front-end. If you decide to go this erector set approach, I can send you a drawing of this cable. Gee, we had no trouble getting this---it's part of the standard DN20 piece kit. I forget the number, and could get it, if anyone cares. One thing: don't let them sell you a "ruggedized Unibus": it's just a heavy-duty Unibus cable, but it costs $1K. Totally useless unless you like running hydrochloric acid under your raised floors. You should, of course, plan to put the DN20 box reasonably near the I/O bay, where the DTEs are. If you have two front-end expansion boxes (the usual), then it could go next to those. We're going to try to move our DH in the third expansion box to the second, and put the 11/34 in the place of the third box. Also, if you're wondering what kind of 11 to get, make sure it's a /34A, not a plain /34 (lots of the latter around). It doesn't really matter, but the closer you stick to vanilla DN20's, the better off you are for maintenance reasons and peace of mind. And, depending on your backplane requirements, you might get away with just the CPU backplane, so you don't need to buy another system unit (this is true only if you have a single quad-high or hex-high board you want to put in the -11, I guess). 26-Feb-81 23:36:29-EST,1534;000000000000 Mail from MIT-MC rcvd at 26-Feb-81 2336-EST Date: 26 Feb 1981 2124-MST From: Randy Frank Subject: Re: Building an Erector Set DN20 To: CPR at MIT-MC, twenex-wizards at MIT-MC cc: b-smith at USC-ISIB In-Reply-To: Your message of 26-Feb-81 1938-MST Reply to Chris's comments: Even with the help on your field service organization (and our was VERY helpful), some of the parts are difficult to get. Field Service had the M9306 on order for over a month, and then finally had to priority-1 order it. Even then, it still took over 3 additional weeks to get. Moral: Plan ahead. Some of the parts (such as the M9306) aren't even on the recommended spares lists for the DN20 (after all, what can you do to a terminator...), so they might not have them in the local office even if they wanted to loan them to you in the meantime. Regarding 11/34 vs. 11/34A: One of our DN20 has an 11/34, the other an 11/34A. We've been unable to observe any difference between them. Both function perfectly normally. If you can save substantial money getting a 34 over a 34A, I'd get it, assuming your local field service doesn't care (and assuming you don't need 34A only options such as the DEC cache or floating point). If you need a cache, I'd recommend the ABLE cache over the DEC one anyway, and it'll work on a 34. The 34A also has a heftier power supply, so you might want to take that into consideration if you're planning on loading your DN20 with a lot of bus devices. Randy ------- 27-Feb-81 05:02:02-EST,4038;000000000000 Mail from MIT-MC rcvd at 27-Feb-81 0501-EST Date: 27 Feb 1981 0138-PST From: Mark Crispin Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022 Stanford-Phone: (415) 497-1407 Subject: DECnet vs ARPANET vs CSnet vs... (flaming message) To: Local-Nets at MIT-MC {Begin Flame} I don't think that the relative technical merits of a solution are important, at least "important" in the sense of "how likely it is to succeed." The following true story illustrates my point: About a year ago, I sent several messages around to the Stanford local network discussion list about the inadequacy of Pup protocol and urged that thought be given to another protocol. My arguments were mostly based upon the limited address space of Pup, but I presented software issues as well. I urged that thought be given either to a new protocol (ala MIT's Chaosnet protocol) or TCP/Internet. My argument for the latter was that while TCP/Internet is both more complicated than is necessary and deficient in some ways it is at least close to a "standard" and that a TCP/Internet development effort would be looked on favorably by ARPA. I also wrote a paper about the addressing problem and expressed my belief that the proper solution was not to use a numeric address but a heirarchical string structure. ARPANET ran out of address space not because there were 255 hosts, but because it ran out of bits in the individual fields. Internet will suffer the same fate very soon, even though there will be far from 4,294,967,303 connected hosts. I was told by the Computer-Science "experts" here that I didn't know what I was talking about. You see, various people with PhD's who worked at Xerox thought that Pup's were the greatest thing in the world. I won't embarass the people involved by telling the outside world how they proposed solving the addressing problem. So what has happened? All of a sudden, everybody thinks that TCP/Internet is the greatest thing in the world and want it implemented...yesterday. Yeah, but what about all this Pup code I'm debugging that I didn't want to waste my time on in the first place? And why the turnaround? ARPA is starting to put pressure for TCP/Internet... The point is, it doesn't matter what the technical merits of a solution are. It's all local politics. If local politics favor a completely idiotic technical solution, that is what will get implemented, irregardless of how much it costs or what the technical people feel or whether it is even technically feasible. It's worse if you are at a university site, because all the practical experience in the world is considered worthless if your opinion disagrees with somebody with a PhD who has used a distributed network elsewhere. No site seems to be free of the problem. Certainly the "big three" -- MIT, CMU, and Stanford -- aren't. {End flame} I feel that in the long run TCP/Internet with an X.25 line protocol is probably everybody's best bet. It's redundant (X.25 provides services duplicated by TCP/Internet), but it will make the most people happy. We also know that they work, although the present implementations of TCP/Internet are wretched. I should add that I don't believe that the user program or the local system itself should have any knowledge whatsoever that it is talking TCP/Internet, X.25, or DECnet, or voodoo. DEC is coming to realize that, and so are other people in the network design business. Who knows? Perhaps in 50 years we'll be freed from the monstrosities we're stuck with today. -- Mark -- PS: Does anybody want to get together and form a company to design hardware/software for a true universal network (in other words, with the primary goal of allowing everybody to talk to everybody)? We'll make a mint selling to all these universities and research sites which are too busy in internal quarrels to do any real work. ------- 27-Feb-81 10:25:47-EST,1153;000000000000 Mail from MIT-MC rcvd at 27-Feb-81 1025-EST Date: 27 Feb 1981 1011-EST From: Roy Marantz Subject: Re: DECnet vs ARPANET vs CSnet vs... (flaming message) To: Admin.MRC at SU-SCORE, Local-Nets at MIT-MC In-Reply-To: Your message of 27-Feb-81 0438-EST Flame on: Well Mark (and all others), why don't ***WE*** do something about it? Many (most?) of us are implementing local nets, and from my impressions of talking to people TCP/IN seems to be the way to go, why don't we make a serious effort to do this right. I don't care if we form a company or not. We will be the ones stuck with maintaining the software (and maybe the hardware). Does anyone else think it is possible for us to cooperate and develop good software. I think it is possible, especially if each of us doesn't have to duplicate the others work. Comments. :Flame off By the way I am serious about distributing the work around, if anyone else can do this (I think I can), please let me know. One thing I don't want is to have to put up some bad kludgy software because I don't have time to do the whole thing myself. Roy ------- 27-Feb-81 17:40:15-EST,1895;000000000000 Mail from MIT-MC rcvd at 27-Feb-81 1739-EST Date: Friday, 27 February 1981 17:28-EST From: Chris Ryland To: twenex-wizards at mc, b-smith at isib Reply-to: CPR at MIT-MC Subject: addendum, clarification on DN20 homebrewing Re the /34 vs /34A question: yes, my recommendation of the 34A was just that your local field service MIGHT care and thus you'd be better of with a vanilla DN20 (as far as they're concerned). As Randy says, the /34 works, in any case (and that's what we have). Also, Randy forgot to mention that you'll need another DL-11 in your primary front-end (don't know what they cost), to talk to your /34's console line; DEC claims this is necessary for them to consider it a real DN20 since some of their diagnostics use it for booting. BTW, once you plug in a DL and configure it at the appropriate address and interrupt vector, it will magically work as DLn: (1, 2, or 3) on the back-end. You can dig the configuration info off your field service fiche (DN20 installation manual; actually, I'm not sure if the entire manuals are there in fiche; you might have to buy the two-volume set from DEC, or, if you're going to have them maintained by DEC, they'll supply them, I presume). Here's the complete list of components you'll need from DEC once you have the 11, memory, and the extra DL. M9306 special passive terminator $ 200.00 (yes: 25 resistors) M8552 10/11 data patch \ 1010.00 M8553 10/11 bus & data control > DTE 910.00 M8554 10/11 b & d control ext. / 330.00 70-13912 Unibus boostrap cable 215.85 * M9310 active Unibus terminator 140.14 DM873-YJ DN20 bootstrap module 292.50 (* This is the wierdo cable which Randy fabricated in-house; your local DEC folks may not be able to find it in their catalogs; it took a lot of trouble to find it, but they eventually did.) 2-Mar-81 17:39:32-EST,1026;000000000000 Mail from SU-SCORE rcvd at 2-Mar-81 1739-EST Date: 2 Mar 1981 1434-PST From: Frank da Cruz Subject: Using Printronix via DN65 To: [SU-SCORE]TOPS-20.DIS.72: ; Does anybody out there run DN65 IBM RJE software in a DN20? We do, and we have a few extra ports on it. There's apparently a 3780-talking interface for the Printronix printer available from QMS. Why tie up another TTY line with a printer when there's a whole PDP-11/34 sitting there with next to nothing to do? The question is - can the Printronix be driven in this way without translating all the ASCII characters to EBCDIC in the wrong way (square brackets becoming cent-signs, etc), e.g. by running in transparency mode, and if so, can this be done alongside the normal RJE communications, which in our case is HASP multileaving? I tried to get one of these boards to try it out, but they make you buy it without trying it. Has anybody ever tried this kind of thing? - Frank da Cruz (Columbia U.) ------- 6-Mar-81 15:08:35-EST,2253;000000000000 Mail from SU-SCORE rcvd at 6-Mar-81 1508-EST Date: 5 Mar 1981 1848-EST From: Dan Tappan Subject: Fix to TIPs losing network connection To: Admin.MRC at SU-SCORE Remailed-date: 6 Mar 1981 1157-PST Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.73: ; [The original message has been edited and abridged prior to redistribution to the list. -- MRC] Our sources have an edit by John Borchek about a year ago "FIX TIPS LOSING NETWORK CONNECTION". I don't know what the bug was, from the fix it looks like something to do with non-existant, of half open connections. I haven't gotten any reports about that particular problem with TIPS's though. I'm including a SRCCOM of the relevant parts below. ; NETWRK.MAC.4003 & <4-MONITOR>NETWRK.MAC.1 5-Mar-81 1540 PAGE 1 LINE 1, PAGE 1 1) ;NETWRK.MAC.6, 24-Jan-80 16:57:36, EDIT BY JBORCHEK 1) ;NETWRK.MAC.6, 19-Nov-79 21:16:36, EDIT BY JBORCHEK 1) ;FIX TIPS LOSING NETWORK CONNECTIONS 1) ;<4.MONITOR>NETWRK.MAC.51, 29-May-79 17:27:39, Edit by LCAMPBELL LINE 1, PAGE 1 2) ;<4.MONITOR>NETWRK.MAC.51, 29-May-79 17:27:39, Edit by LCAMPBELL LINE 46, PAGE 2 1) ;FLAGS IN NETSTS 1) LINE 46, PAGE 2 2) ;FLAGS IN LH OF NETSTS 2) LINE 56, PAGE 2 1) 1) FLG(LINKF,R,IOS,400000) ;LINK TABLE INDEX VALID 1) ^L 1) ; BBN socket numbers description 1) ; A socket number is a 32-bit number which in conjunction with LINE 56, PAGE 2 2) ^L 2) ; Bbn socket numbers description 2) ; A socket number is a 32-bit number which in conjunction with LINE 89, PAGE 35 1) NETCLL: LOAD T1,LTIDX,(UNIT) ; Get link table index 1) TQZE ; Link setup? 1) CALL IMPCLL 1) MOVEM IOS,NETSTS(UNIT) ; Store status 1) RET 1) LINE 89, PAGE 36 2) NETCLL: LOAD T1,LTIDX,(UNIT) ;GET LINK TABLE INDEX 2) CALLRET IMPCLL 2) LINE 13, PAGE 36 (NETOPS+2) 1) MOVX IOS,LINKF ; Mark valid link table index 1) IORB IOS,NETSTS(UNIT) 1) RET LINE 13, PAGE 37 2) RET LINE 28, PAGE 37 1) MOVE IOS,NETSTS(UNIT) ; Get current status 1) CALL @ACTAB(T2) ; Call action routine LINE 28, PAGE 38 2) CALL @ACTAB(T2) ; Call action routine ------- 10-Mar-81 19:29:17-EST,2703;000000000000 Mail from MIT-MC rcvd at 10-Mar-81 1928-EST Mail-from: ARPAnet host PARC-MAXC rcvd at 10-Mar-81 1504-PST Date: 10 Mar 1981 15:03 PST From: GWilliams at PARC-MAXC Subject: 3Com takes on DEC To: "@Gang.dl" Remailed-date: 10 Mar 1981 1609-PST Remailed-from: Harris A. Meyers Remailed-to: local-nets at MIT-MC --------------------------- Date: 10 March 1981 11:46 am PST (Tuesday) From: Weissman.PA Subject: 3Com takes on DEC To: AllJunk^ From "Information Systems News" of 3/10/81: 3Com To Build Ethernet Transceiver 3Com Corp. will build 10-megabit-per-second Ethernet Transceivers designed to meet the specifications for the Ethernet office network published last September by Xerox Corp., Digital Equipment Corp. and Intel Corp. Each of the three companies are [sic] to provide different components to the Ethernet system, with DEC manufacturing the network transceivers. By introducing its transceiver now, 3Com is attempting to grab the inside track from the minicomputer manufacturer. Robert M. Metcalf [sic], president of 3Com, was one of the original developers of the Ethernet architecture while he was with the Xerox Palo Alto Research Center. The Menlo Park, Calif., manufacturer of computer communications products said it has already accepted orders from more than 20 customers for preproduction models of a local networking device. The first installations of Ethernet, a local computer networking system that uses coaxial cable to link computer and office equipment from multiple vendors, are currently being made. Currently the only Ethernet components available are from Xerox, which has produced a limited number of transceivers for the first Ethernet customers. But Xerox says it has no plans to mass produce the device. A modified version of the Ethernet specifications was recently adopted by the Institute of Electrical and Electronics Engineers (IEEE). Firms now known to be pursuing Ethernet as put forward by its three developers are: 3Com, Hewlett-Packard Co., Nixdorf Computer Corp., Olivetti Computers, Thomson-CSF and Zilog Inc. The 3Com Ethernet Transceiver will, when combined with other hardware and software products, enable manufacturers and users to be compatible with Xerox, DEC and Intel Ethernet systems. Each transceiver has standard N-series connectors for coupling to the coaxial cable and comes with a 50-foot transceiver cable. The transceivers will cost $550 each for the first 10 units, and $365 each for additional units. They are available now, and delivery will begin in two to three weeks. ------------------------------------------------------------ 11-Mar-81 17:37:38-EST,2433;000000000000 Mail from RADC-TOPS20 rcvd at 11-Mar-81 1737-EST Date: 11 Mar 1981 1655-EST From: Kevin Paetzold To: TOPS-20: G.Cower at SU-SCORE, Baker at AFSC-HQ, Pace at AFSC-HQ, Perilli at AFSC-HQ, Allen at BBND, EONeil at BBND, JBorchek at BBNG, Tappan at BBNG, CSD.Milligan at SU-SCORE, Lindblad at CIT-20, King at CMU-20C, G.daCruz at SU-SCORE, G.SLogin at SU-SCORE, G.TJM at SU-SCORE, Kincl at UTAH-20, G.LCampbell at SU-SCORE, Lyons at DEC-MARLBORO, G.Miller at SU-SCORE, RGSmith at RUTGERS, G.Eldre at SU-SCORE, CPR at MIT-XX, JIS at MIT-XX, Wallace at MIT-XX, NCP.Pine at SU-SCORE, Rowe at NBS-10, Mittal at RUTGERS, Waggoner at RUTGERS, GeoffM at RAND-AI, Paetzold at RADC-TOPS20, Pratt at RADC-TOPS20, Mike at RAND-AI, Hedrick at RUTGERS, TOPS-20 at RUTGERS, Admin.MRC at SU-SCORE, Admin.Bosack at SU-SCORE, Admin.JQJ at SU-SCORE, Admin.Lougheed at SU-SCORE, Gilmurray at SUMEX-AIM, Rindfleisch at SUMEX-AIM, Schoen at SUMEX-AIM, Sweer at SUMEX-AIM, Larson at SRI-KL, Meyers at SRI-KL, CC.Clive at UTEXAS-20, CC.David at UTEXAS-20, CC.Loomis at UTEXAS-20, G.ECP at SU-SCORE, Thompson at USC-ECLB-IPI, CTaylor at USC-ISIF, Dale at USC-ISIB, Koda at USC-ISID, LSims at USC-ISIE, Frank at UTAH-20, C-Griss at UTAH-20, Crossland at UTAH-20; Reply-to: Paetzold at RADC-TOPS20 Telephone: 315-330-4013 AV-587 Subject: Changing of the guard Message-ID: 11711260450.17.240.65054 at RADC-TOPS20 As some of you know I am leaving RADC-TOPS20 for bigger and better things. I have been transferred by DEC to Marlboro. I am being replaced by Mark Pratt (PRATT@RADC-TOPS20). I would appreciate all of you adding Mark to your mail lists. I will still receive mail at RADC-TOPS20 (the preferred address) as well as DEC-MARLBORO and DEC-2136. This mail list (first began by MRC I believe) has saved me countless hours of aggravation and pain by seeing some bugs and the fixes for them before they occured on my system. It has also given me some amused moments (eg Mr. Bill buys a 20). I wish you all luck in the future. Please do not hesitate to contact me if you think I can ever be of any help to you. My address is (I do not know my new phone number): Kevin W. Paetzold MR1-2/E37 Digital Equipment Corporation Large Systems Engineering 200 Forest Street Marlboro, Mass 01752 -------- 12-Mar-81 22:21:33-EST,788;000000000000 Mail from SU-SCORE rcvd at 12-Mar-81 2221-EST Mail-from: ARPANET site MIT-AI rcvd at 12-Mar-81 1226-PST Date: Thursday, 12 March 1981 15:08-EST From: Chris Ryland To: Admin.MRC at score Subject: scheduler bug Remailed-date: 12 Mar 1981 1910-PST Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.75: ; At MIT we often see a problem when loads get fairly high (10 or greater) where the scheduler "forgets about" some jobs and gives them essentially no time. This often clears up by itself, but sometimes degenerates to the point where we have to reload. I haven't had a chance to look at it closely, but wondered if other people had ever seen it. (It's entirely possible that it's a local problem.) 14-Mar-81 19:51:06-EST,1089;000000000000 Mail from SU-SCORE rcvd at 14-Mar-81 1950-EST Mail-from: ARPANET site MIT-MC rcvd at 14-Mar-81 0612-PST Date: Saturday, 14 March 1981 09:12-EST From: Chris Ryland To: Admin.MRC at Score Subject: Tops-20 people: scheduler problems Remailed-date: 14 Mar 1981 1642-PST Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.76: ; Re my last query about the scheduler "forgetting about" certain jobs when the load gets high: I remembered that this is a feature of the R4 scheduler---when it thinks things are in tough shape due to a high load, it will first put all batch jobs to sleep, then it will quiesce forks in the higher (ie, less interactive) queues. I'm almost sure this is what's happening, since interrupting the fork and contininuing it (which gets it into an interactive queue for a while) buys some time for it. I don't think this is a good idea, especially when the loads are only 10 that we're talking about. Is there some way to set this quiescing parameter, or turn it off entirely? 16-Mar-81 04:58:53-EST,1170;000000000000 Mail from SU-SCORE rcvd at 16-Mar-81 0458-EST Mail-from: ARPANET site UTAH-20 rcvd at 14-Mar-81 1912-PST Date: 14 Mar 1981 2002-MST From: Randy Frank Subject: Re: Tops-20 people: scheduler problems To: Admin.MRC at SU-SCORE, cpr at MIT-AI In-Reply-To: Your message of 14-Mar-81 1753-MST Remailed-date: 16 Mar 1981 0154-PST Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.76: ; My recollection is that this is controlled by the bias control knob. The particular parameter of the scheduler which controls it is the "disaster avoidance" facility as it is called. We set our bias knob at 9, which I'm pretty sure disables disaster avoidance. I'm note sure how much lower you can set bias without turning disaster avoidance on. We did have it on for a while and found it to be a disaster! Disaster avoidance works something like this: at a certain high queue load avg (4 or something like that) no low q processes are added to the balset. At another high q load avg (6?? 8??) low q processes are forceably removed from the balance set, even if they reserve time left. ------- 16-Mar-81 05:08:58-EST,1312;000000000000 Mail from SU-SCORE rcvd at 16-Mar-81 0508-EST Mail-from: ARPANET site RUTGERS rcvd at 14-Mar-81 1917-PST Date: 14 Mar 1981 2212-EST From: HEDRICK at RUTGERS Subject: Re: Tops-20 people: scheduler problems To: cpr at MIT-MC cc: Admin.MRC at SU-SCORE In-Reply-To: Your message of 14-Mar-81 1951-EST Remailed-date: 16 Mar 1981 0154-PST Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.76: ; I assumed you knew the way the scheduler worked, and had some other problem. Actually it depends upon the setting of the bias control. With the bias control at 11, it does not forget processes under high load. With the control anywhere under 11, it does. We find that what we want is the behavior of 6, but without the forgetting of processes. Therefore, we make even bias control numbers turn off the bit that controls this feature. Odd numbers retain the original DEC functions. We find that with this definition 6 gives us significantly better results than 11 (the default), whereas with the original DEC definitions, 6 was a disaster, because our serious research jobs (e.g. Lisp) got turned off. Also, we find that background batch is a bit too background. Apparently the jobs get so frozen that you can't even log them off. ------- 18-Mar-81 01:22:02-EST,1304;000000000001 Mail from SU-SCORE rcvd at 18-Mar-81 0121-EST Mail-from: ARPANET site MIT-AI rcvd at 16-Mar-81 1119-PST Date: Monday, 16 March 1981 13:45-EST From: Chris Ryland To: Admin.MRC at SCORE Reply-to: CPR at MIT-MC Subject: RSX20F serious problem Remailed-date: 17 Mar 1981 2215-PST Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.76: ; Here's a simple C program, whose purpose and method should be clear. It's not totally artificial; there's a hacker on XX who does the same thing in a Muddle graphics program, and consequently trashes 20F. It appears (if it's not obvious) that lots of negotiations about page-mode causes buffer-overflows in the front-end (doing this 100 times really keeps the front-end down for a long time). Is there any hope that DEC can fix this? We surely don't want to hack 20F. main () {while (TRUE) {int n, tmp; char buf[100]; setprompt ("Number of times to thrash front end: "); gets (buf); tmp = copen (buf, 'r', "s"); if (scanf (tmp, "%d", &n) != 1) break; cclose (tmp); while (--n >= 0) {int omode; omode = _RFMOD (PRIOU); _STPAR (PRIOU, omode & ~PAGE_MODE); SYSBOUT (PRIOU, 'x'); _STPAR (PRIOU, omode | PAGE_MODE); } } } 18-Mar-81 23:51:42-EST,1360;000000000000 Mail from SU-SCORE rcvd at 18-Mar-81 2351-EST Mail-from: ARPANET site SRI-KL rcvd at 18-Mar-81 2037-PST Date: 18 Mar 1981 2031-PST From: LARSON at SRI-KL Subject: FTPSER bug To: Admin.MRC at SU-SCORE Remailed-date: 18 Mar 1981 2044-PST Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.77: ; [Note from MRC: Systems running an XMAILR FTPSER (e.g. Stanford and MIT) should not put this change in. It is unnecessary since the XMAILR FTPSER handles this differently.] PROBLEM: If FTPSER receives a message to forward to a user for whom it already has a message waiting to be remailed, it will append it to the same file; resulting in the user recieving two messages with one length header. This will confuse all mail readers known to the author. Normally this is not noticed, since most mailers respond to the "will forward" message by aborting and sending directly to the new destination. SOLUTION: When forwarding, insist on the creation of a new file. LINE 7, PAGE 43 1) ;8 TLZ A,101000 ;YES. ALLOW NEW FILE 1) movsi a,(gj%fou!gj%new!gj%sht) ;8 yes, require new output file 1) MAIL2C: GTJFN LINE 7, PAGE 43 2) TLZ A,101000 ;YES. ALLOW NEW FILE 2) MAIL2C: GTJFN I am running with this in, and it seems to work. The complaints stopped. Alan ------- 19-Mar-81 16:09:43-EST,2620;000000000000 Mail from SU-SCORE rcvd at 19-Mar-81 1609-EST Date: 19 Mar 1981 1255-PST From: Mark Crispin Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022 Stanford-Phone: (415) 497-1407 Subject: COMND% bugfix, from Columbia To: [SU-SCORE]TOPS-20.DIS.77: ; Submitted by Jeff Damens (212-280-3754) & Andy Lowry (212-280-3704) Problem: If a carriage return is typed when using the COMND jsys to parse a noise word, and if none of the buffer contents have yet been processed (words .cmbfp and .cmptr in the CSB point to the same character), COMND will reissue the prompt and wait for futher input, without ever returning to the user program. This situation might naturally arise if the noise word is preceded by one or more fields all of which are supplied with defaults, and the user simply types a carriage return expecting to accept all the defaults and move on. Diagnosis: In almost all parsing situations when none of the buffer has been processed and the user types a carriage return, the correct action is to reissue the prompt and wait for further input. Exceptions to this rule are in these situations: - The function code was .CMCFM (parsing a confirm) - A default was supplied for the field (use it & continue) - The function code was .CMFIL (arbitrary filespec) and the GTJFN block contains a default name - The function code was .CMNOI (Parsing a noise word) All but the last of these cases is checked for in the literal that begins two lines past NLINE (the literal is jumped to as soon as it has been determined that the next input in the buffer is a carriage return). The ommission of the test for the last case is what causes the problem. Cure: Make the following changes inside the literal: Old code: NLINE: CALL RDCRLF ;END OF LINE FIRST THING ON IT CAIA ;NO JRST [ TXNE F,CMPS1F ;JUST SCANNING? . . CAIN T1,.CMFIL ; PARSE ARBITRARY FILE? JRST CHKDEF ; YES. CHECK GTJFN BLOCK... CALL CHKCFM ;NO, SEE IF THERE IS A CONFIRM... JRST CHKDF1 ; NONE, REISSUE PROMPT JRST XCOM0] ;YES, PROCESS IT New code: NLINE: CALL RDCRLF ;END OF LINE FIRST THING ON IT CAIA ;NO JRST [ TXNE F,CMPS1F ;JUST SCANNING? . . CAIN T1,.CMFIL ; PARSE ARBITRARY FILE? JRST CHKDEF ; YES. CHECK GTJFN BLOCK... (insert) CAIN T1,.CMNOI ;NO, NOISE WORD? (insert) JRST XCOM0 ;YES, PROCESS IT CALL CHKCFM ;NO, SEE IF THERE IS A CONFIRM... JRST CHKDF1 ; NONE, REISSUE PROMPT JRST XCOM0] ;YES, PROCESS IT ------- 19-Mar-81 16:28:45-EST,1458;000000000000 Mail from SU-SCORE rcvd at 19-Mar-81 1628-EST Date: 19 Mar 1981 1256-PST From: Mark Crispin Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022 Stanford-Phone: (415) 497-1407 Subject: CRDIR leaving JFN open, from Columbia To: [SU-SCORE]TOPS-20.DIS.77: ; Andre Lowry Columbia University Center for Computing Activities Problem: If CRDIR% fails to delete a directory because someone had the directory file mapped, the process doing the CRDIR% is left with a jfn on the firectory file. Diagnosis: Approximately halfway between DELDI6 and DELDI2, CRDIR% calls CHKOFN to make sure that the directory file is not open anywhere. If the file is open, CRDIR% RETBAD's immediately with error code CRDIX6. At this point, the process has a JFN on the directory file, which should have neen released before the RETBAD. Cure: The code at DELDI3 was written to handle the jfn release followed by a RETBAD. Just use it instead of the bare RETBAD. Make the following code chages: Old Code: DELDI6: LOAD A,DRLIQ,(Q1) ;GET LIQ : : CALL CHKOFN ;SEE IF THIS FILE IS OPEN (DIRECTORY IS MAPPED) RETBAD(CRDIX6) ;YES. CAN'T DELETE THE FILE, THEN New Code: DELDI6: LOAD A,DRLIQ,(Q1) ;GET LIQ : : CALL CHKOFN ;SEE IF THIS FILE IS OPEN (DIRECTORY IS MAPPED) JRST [ MOVEI D,CRDIX6 ;YES. CAN'T DELET THE FILE, THEN JRST DELDI3] ------- 19-Mar-81 16:52:45-EST,3952;000000000000 Mail from SU-SCORE rcvd at 19-Mar-81 1651-EST Date: 19 Mar 1981 1257-PST From: Mark Crispin Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022 Stanford-Phone: (415) 497-1407 Subject: ILMNRF crash in GET%, from Columbia To: [SU-SCORE]TOPS-20.DIS.77: ; Andrew Lowry & Bill Schilit Columbia Computer Center Problem: Any user can crash the monitor with a ILMNRF bughlt by issuing a GET% jsys under certain conditions Diagnosis: The problem occurs when GET% makes an internal call to SIN% in such a way that the XCTBUU [IDPB B,2] instruction at SIN1+7 causes an illegal memory write. This instruction is executed only after filling the file's input buffer. Thus in particular if the input buffer is empty at the start of the SIN% call the instruction will be executed. All the other data transfer in SIN% when called by GET% is handled by the BYTBLT routine which is protected against memory protect failures by setting a trap dispatch address in TRPDSP on entry to the routine and restoring the previous value upon exiting. Since GET% will ask for no more than 1000 (octal) words to be transferred at a time, and the input buffer size for a disk file is 1000 words, this condition can only occur when the input buffer is empty at the time of the SIN% call. In addition, this SIN% must be the first reference to the write-protected page; otherwise the trap would already have occured in BYTBLT and would have caused an interrupt in the process executing the GET%. Note that this bug only manifests itself with nonsharable save files, since SIN% is not used by GET% for sharable files. Example: The following sequence of commands will create a bogus csave file and then issue a GET% on that file in a way that will crash the system. We have given a rather long procedure here since it clearly demonstrates all the conditions that must be present for the crash to occur. @; First make the file exist so we can FILDDT it @ @cop nul: dont-get-me.exe NUL: => DONT-GET-ME.EXE.1 [OK] @ @; Now we'll build a bogus csave file inside it @ @filddt FILDDT>get dont-get-me.exe/patch % Not in .EXE format -- Data file assumed [Looking at file DONT-GET-ME.EXE.1] 0! -776,,777 ! Load 776 words starting at loc 1000 ! (the contents are unimportant) 777! -1,,1777 ! Then load one more word at loc 2000. ! Note that when SIN% is called to ! process this block, the file's input ! buffer will be empty since we just ! read 1000 words, and the word will ! be stored in a new core page. 1000! 0 ! Make this file page exist. ^Z @ @; Now we have to fix the file's byte count or GET% will hit @; eof before getting to the danger spot. @ @sddt 1! gj%sht 2! -1,,1000 100! ""dont-get-me.exe" gtjfn%$x 1/ 13 .fbsiz,,13 2! -1 3! 200 ; Make it big enough to read past the ; trouble spot. chfdb%$x 2000! 0 ; Make the page exist so we can set ; it to be write-protected ^Z @ @; Now we'll use the EXEC to make process page 2 write-protected. @; (Note we'll do our GET% right into the SDDT fork we've been @; using, just for convenience's sake.) @ @set page-access (of pages) 2 (access) no write - @ no copy-on-write @ @; Finally, we're read to do our killer GET% @ @ddt DDT 1! .fhslf,,13 ; Use our old jfn, no flags set get%$x ; Oh nooooooooooo! %DECSYSTEM-20 NOT RUNNING^G^G^Gx~~~'&^x Cure: The XCTBUU [IDPB B,2] instruction must be protected against illegal memory references either by setting up a dispatch address (and possibly requesting a psi interrupt for the user fork) in TRPDSP, or by inserting and ERJMP or ERCAL instruction immediately afterwards. These are the two conditions that will cauise the code at ILWR in the PAGEN module to avoid BUGHLT'ing. ------- 21-Mar-81 03:56:28-EST,655;000000000001 Mail from SU-SCORE rcvd at 21-Mar-81 0356-EST Date: 20 Mar 1981 2130-PST From: Mark Crispin Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022 Stanford-Phone: (415) 497-1407 Subject: SPR 20-15152 To: [SU-SCORE]TOPS-20.DIS.80: ; I am unable to install SPR 20-15152, as printed in the 1 March 1981 Software Dispatch. I get a T04 11-HALT right after doing the DEPOSIT 35006:000137. Thinking that it might be because my system has the KLINIK enabled by default, I did a CLEAR KLINIK in a fresh RSX and tried again, but I still got the T04. Does anybody have any clues? -- Mark -- ------- 24-Mar-81 16:55:23-EST,3539;000000000001 Mail from SU-SCORE rcvd at 24-Mar-81 1654-EST Mail-from: ARPANET site DEC-MARLBORO rcvd at 22-Mar-81 2114-PST Date: 23 Mar 1981 0013-EST From: DEUFEL at DEC-MARLBORO To: ADMIN.MRC at SU-SCORE Subject: RSX20F Patch for Split Speed KLINIK/CTY Message-ID: Remailed-date: 24 Mar 1981 0930-PST Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.83: ; Hi Mark, I got your message concerning edit G to RSX20F VB1341. Sorry for the inconvenience but I discovered the typo to late to prevent it from being published. The corrected answer is due to be published soon. Here is the corrected answer::: --------------------------------------------------------------------- Aux file: Thank you for your SPR on RSX20F. The following will allow you to run your CTY and KLINIK at different speeds. [SYMPTOMS] The CTY and KLINIK hang when logically connected together in REMOTE mode and the two lines are running at different speeds. [DIAGNOSIS] The routines which acknowledge the processing of output data for the KLINIK/CTY assume that they will both be running at the same speed. [CURE] Deallocate and acknowledge output nodes when the slower of the two lines is done with it and let the faster of the two lines wait on the slower. Note that this patch makes the assumption that the CTY is always running at the same speed or faster than the KLINIK line is running when the two are logically connected. This is edit G to RSX20F VB13-41. To apply this patch do the following: 1) Shut down the system by typing the following: ^\ ! Control-\ to invoke the PARSER -- PAR>SHUT ! Causes TOPS20 to stop running 2) Now reboot the Console Front End by setting the switches on the PDP-11 to 203 and pressing the ENABLE and SWITCHES load switches on the KL10 front panel. 3) Type ^\ (Control-\) to invoke the PARSER. 4) Type the following to the PARSER: SET CONSOLE MAINTENANCE SET MEMORY ELEVEN ! CMP R5,KLNPTR DEPOSIT 144:020537 DEPOSIT 146:002636 ! BNE #166 DEPOSIT 150:001006 ! MOV R5,-(SP) DEPOSIT 152:010546 ! MOV CTYPTR,R5 DEPOSIT 154:013705 DEPOSIT 156:002634 ! JSR PC,.TTCAK DEPOSIT 160:004737 DEPOSIT 162:034522 ! MOV (SP)+,R5 DEPOSIT 164:012605 ! RTS PC DEPOSIT 166:000207 ! JMP #144 DEPOSIT 34514:000137 DEPOSIT 34516:000144 ! .ASCII /1G/ DEPOSIT 1044:043461 ! WHAT VERSION ! SET CONSOLE OPERATOR 5) NOW TYPE "MCR SAV" IN RESPONSE TO THE PROMPT SAV> TYPE "SY0:/WB" This will save the patched RSX20F immage on the front end file system. If you have any questions about applying this patch please contact your local software specialist before proceeding. -------------------------------------------------------------------------- BEWARE: There is a problem with this patch in that the KLINIK line cannot be used as regular timesharing line. If you try to use the KLINIK line as a timesharing line (e.g. USER mode) the KLINIK line will hang after printing about 12 characters of the system header when someone dials in... We are working on this problem and hope to have it fixed shortly. The patch was published because VB1341 hung if you tried to run the CTY at a speed greater than the KLINIK line ant the KLINIK line was used as a REMOTE console. If you have any questions let me know... -Abdul- -------- 25-Mar-81 20:40:57-EST,438;000000000000 Mail from MIT-MC rcvd at 25-Mar-81 2040-EST Date: 25 Mar 1981 1835-MST From: Randy Frank Subject: tape copy program To: twenex-wizards at MIT-MC Does anyone have a general program that just copies (duplicate) tapes, with the source and destination tapes as possible different densisites. I want something that will copy the entire contents of a tape (e.g., it may have multiple files). Randy ------- 25-Mar-81 21:38:54-EST,376;000000000000 Mail from MIT-MC rcvd at 25-Mar-81 2138-EST Date: 25 Mar 1981 1934-MST From: Randy Frank Subject: Re: tape copy program To: C-GRISS at UTAH-20, twenex-wizards at MIT-MC In-Reply-To: Your message of 25-Mar-81 1928-MST I got a program called MTU from SCORE, which also does tape copying. It looks pretty powerfull. Itps over here now. ------- 25-Mar-81 21:43:32-EST,474;000000000000 Mail from MIT-MC rcvd at 25-Mar-81 2143-EST Date: 25 Mar 1981 1928-MST From: C-GRISS at UTAH-20 Subject: Re: tape copy program To: FRANK at UTAH-20, twenex-wizards at MIT-MC In-Reply-To: Your message of 25-Mar-81 1835-MST Randy, I have a program that copies tapes bit for bit and can change densities. As it doesnt double buffer, it runs a little slower in real time than it has to -- but weve used it for distributions and it works fine. Ced. ------- 25-Mar-81 23:21:44-EST,499;000000000000 Mail from MIT-MC rcvd at 25-Mar-81 2321-EST Date: 25 Mar 1981 2308-EST From: HEDRICK at RUTGERS Subject: Re: tape copy program To: FRANK at UTAH-20 cc: twenex-wizards at MIT-MC In-Reply-To: Your message of 25-Mar-81 2035-EST MTU will do it, I think. At least it always has worked for me. I have always used it with unlabelled tapes, however. It should also work with labelled tapes if set unavailable or mounted bypass. It does let source and dest be different densities. ------- 31-Mar-81 19:09:43-EST,770;000000000000 Mail from SU-SCORE rcvd at 31-Mar-81 1909-EST Date: 27 Mar 1981 1936-PST From: Patrick Milligan Subject: Desired: TOPS-20 BCPL To: Admin.MRC Remailed-date: 31 Mar 1981 1600-PST Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.83: ; You might be able to help me with this, or perhaps the TOPS-20 distribution list is the right thing. I would like to get a recent version of BCPL which works with TOPS-20. I have an old TENEX version. I believe that BBN, SRI, and USC-ISI have BCPL, but I don't know who maintains BCPL at those sites. I would like to get everything associated with BCPL, including sources for the compiler and utilities. I hope you can help... -- Patrick ------- 22-Mar-81 5:15:48,783;000000000000 Mail-From: ADMIN.MRC created at 22-Mar-81 04:01:04 Mail-from: ARPANET site AFSC-HQ rcvd at 22-Mar-82 1444-PST Date: 22 Mar 1982 1756-EST From: Chuck Perilli Postal-address: HQ AFSC/ACDPS, Andrews AFB, DC 20334 Phone: (301)981-4002; AUTOVON: 858-4002 Subject: Free DBMS Remailed-date: 22 Mar 1981 0401-PST Remailed-from: Mark Crispin Remailed-Sender: ADMIN.MRC at SU-SCORE Remailed-to: TOPS-20 at SU-SCORE Software House of Cambridge, MA has announced that through June 1, they will issue a limited number of FREE licenses for their 1022 data base management system to non-profit, tax-exempt universities or colleges. They are even offering to throw in a week-long seminar to go with it. Might be a good deal for anyone qualified. ------- 10-Apr-81 20:43:32-EST,647;000000000000 Mail from MIT-MC rcvd at 10-Apr-81 2043-EST Date: 10 Apr 1981 1833-MST From: Randy Frank Subject: Program counter sampler program To: twenex-wizards at MIT-MC cc: lepreau at UTAH-20 Does anyone know a a program that samples the PC of another program (perferably running as an inferior fork), adn then prints out a histogram or the like of the pc. Ideally it would look the PC up against the symbol table and give the histogram in a usable form (i.e., not just PC address). I'm aware of PCHIST. I'm looking for something with a little more smarts, and which can be used by a non-priv user. Randy ------- 10-Apr-81 20:54:54-EST,484;000000000000 Mail from MIT-MC rcvd at 10-Apr-81 2054-EST Date: 10 Apr 1981 1748-PST From: LARSON at SRI-KL Subject: Re: Program counter sampler program To: FRANK at UTAH-20, twenex-wizards at MIT-MC cc: lepreau at UTAH-20 In-Reply-To: Your message of 10-Apr-81 1733-PST There is an old TENEX program called PCSAMP. It does what you want. I think later versions may even have looked through the symbol table, but I am sure it is very close to what you want. Alan Larson ------- 10-Apr-81 21:15:53-EST,2619;000000000000 Mail from MIT-MC rcvd at 10-Apr-81 2115-EST Date: 10 Apr 1981 1902-MST From: Randy Frank Subject: Availability of Portable C Compiler for the 20 - PRELIMINARY NOTICE To: twenex-wizards at MIT-MC THIS IS A PRELIMINARY ANNOUNCEMENT OF A FORTHCOMING RELEASE OF PCC/20. PLEASE DO NOT DISTRIBUTE FURTHER WITHOUT OUR PERMISSION. THANKS. The Univ. of Utah will be releasing (hopefully by June) the Unix Portable C Compiler (PCC) ported to the DECSystem 20, along with a mostly-Unix compatable library for the 20. The purpose of this announcement is to let interested parties initiate the Western Electric licensing procedure, which is necessary since PCC is part of Unix V7. As silly as it sounds, before we can send you PCC/20, you will have to get your 20 licensed for Unix V7 or Vax Unix. If you already have V7 Unix or Vax Unix licensed to your institution, usually all it takes is a letter to Bell Labs asking that your 20s be added to your V7 or Vax Unix license (along with $$$ if you are not an educational site - I don't know how much is involved for a second system license for commercial sites). If you don't have either a V7 or Vax Unix license, you must get one from Bell Labs/Western Electric. Licenses (or modifications to licenses) from Bell have been running about 8-10 weeks, so this is one reason why we are pre-announcing this program. We will require a copy of your Unix license, as well as a signed Univ. of Utah license agreement (available from me). Once released, it will be available free of charge to universities and non-profit institutions that have had a policy of free distribution of similar software. (I think most of you are in this category!). Policy for commercial organizations and universities who are in the "software house" business has not been decided, yet. Technical considerations: The main advantage to PCC/20 is that it is source code compatable with both v7 Unix C and Vax C (the Vax C compiler also uses PCC as a basis; V7 C is a non-portable compiler, but is nevertheless compatable with PCC). Jay Lepreau (LEPREAU@UTAH-20) has been responsible for the implementation of PCC/20, and should be contacted for technical questions. Our goal here (and the reason we undertook the project) was so that we could have a common source language for programming our 20s, Vax Unixs, and 11 Unixs. IF INTERESTED YOU MUST INITIATE THE LICENSING WITH BELL. Please don't ask us to forward you a copy until this is done, as we expose ourselves legal action if we do, and therefore we won't! Randy ------- 13-Apr-81 22:46:37-EST,933;000000000000 Mail from SU-SCORE rcvd at 13-Apr-81 2246-EST Mail-from: ARPANET site DEC-MARLBORO rcvd at 3-Apr-81 0753-PST Date: 3 Apr 1981 1053-EST From: MILLER at DEC-MARLBORO To: admin.mrc at SCORE Subject: For distribution Message-ID: Remailed-date: 13 Apr 1981 1626-PST Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.84: ; I have been asked to solicit extended programs that people have written. The request has come from the MBOX designers so that they can do some cache simulations. Ideally, the examples should be working programs that use multiple sections (i.e. not just a single section program that happens to run in any section). We would prefer not to have any proprietary stuff since we don't want the hassle of legal agreements. If anyone has such an application, contact Mike Uhler or me. -------- 13-Apr-81 22:57:30-EST,834;000000000000 Mail from SU-SCORE rcvd at 13-Apr-81 2257-EST Mail-from: ARPANET site MIT-XX rcvd at 9-Apr-81 1144-PST Date: Thursday, 9 April 1981 14:40-EST From: Chris Ryland To: Admin.MRC at SU-SCORE Reply-to: CPR at MIT-MC Subject: SFTAD fatal bug Remailed-date: 13 Apr 1981 1716-PST Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.84: ; Someone at CMU pointed out that giving a -1 in T2 to SFTAD% would crash the system (clearly, at SFTAD3, in JSYSF, the XCTU is going to fail with an invalid section reference). I'm afraid that there are lots and lots of JSi that would do the same. Probably, someone will have go through and add calls to routines to validate all addresses given (usually a range of addresses), especially with multiple section support. 13-Apr-81 23:01:32-EST,1420;000000000000 Mail from SU-SCORE rcvd at 13-Apr-81 2301-EST Mail-from: ARPANET site MIT-AI rcvd at 9-Apr-81 1020-PST Date: Thursday, 9 April 1981 13:17-EST From: Chris Ryland To: Admin.MRC at SU-SCORE Subject: [JONL: Queries about logical names] Remailed-date: 13 Apr 1981 1715-PST Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.84: ; Has anyone seen the first problem? The second seems like a real bug. --CPR ---Begin forwarded message--- Date: Tuesday, 17 March 1981 11:22-EST From: JONL at MIT-MC (Jon L White) Re: Queries about logical names 1) The first usage of the .NULIO designator as the destination argument to LNMST causes an ilgl memry trap; subbsequent usages in the same fork seem to win. 2) A name with multiple alternates is not correctly searched by JFNS -- for example, the current SYS: defintion on MIT-XX has PS: first, PS: second, and etc. the file PS:RNMVRN.EXE exists, but no other RNMVRN file exists on SYS:. If one gets a JFN with the long form of GTJFN, using the string "SYS:RNMVRN.EXE" then he has a valid JFN which can be opened, etc, but if he queries it with JFNS, it will say that the directory field (from the JS%DIR specification) is SUBSYS rather than UNSUPPORTED; all other fields are correctly reported. 15-Apr-81 03:24:41-EST,1749;000000000001 Mail from SU-SCORE rcvd at 15-Apr-81 0324-EST Date: 15 Apr 1981 0018-PST From: Patrick Milligan Subject: Release 4 and XON/XOFF To: Admin.MRC Remailed-date: 15 Apr 1981 0019-PST Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.86: ; This is a request for information about the way that Release 4 of TOPS-20 and/or RSX20F handles XON/XOFF on terminal input. I have been debugging a DEC-20 program that needs to handle very high volume input (256 bytes at a time, 8 bit bytes, at 9600 baud). I have done everything I could think of with the various terminal JSYS calls, but I still have XOFFs being set to my "Rogue terminal" that doesn't handle XON/XOFF... I suspect that the culprit is the Front-End. I vaguely remember something said at DECUS a couple of sessions ago about changes in RSX20F for terminal input (seems like the silo buffer size was reduced to 1 so that the backend would see XOFF's coming from a VT100 fast enough to shut up so the VT100's buffer wouldn't overflow). I am working on making my "Rogue terminal" (actually, a Three Rivers PERQ) understand XON/XOFF, but I would appreciate information about how to get around the problem on the DEC-20/Front-End side of things. (I realize I may be asking for framing errors if I do manage to stop the flow control). Recommended parameters for OPENF/MTOPR/SFMOD/STPAR and friends and/or Front-End/Back-End patches would be appreciated (or simply information about the way that terminal input flow control works...) If appropriate, please forward this message to the TOPS-20 Distribution list and/or people at DEC who might be able to enlighten me. Thanks... -- Patrick ------- 15-Apr-81 22:44:18-EST,818;000000000000 Mail from SU-SCORE rcvd at 15-Apr-81 2244-EST Mail-from: ARPANET site DEC-MARLBORO rcvd at 15-Apr-81 1838-PST Date: 15 Apr 1981 2136-EST From: MILLER at DEC-MARLBORO To: admin.mrc at SCORE Subject: reported logical name bug Message-ID: Remailed-date: 15 Apr 1981 1937-PST Remailed-from: Mark Crispin Remailed-to: CPR at MIT-EECS at MIT-AI, [SU-SCORE]TOPS-20.DIS.86: ; I am sending this to you because the author's address is unknown here. The second bug appears to be the problem that the program has write access to SUBSYS and is doing the GTJFN without specifying GJ%OFL. COnsequently, GTJFN is creating a new file in SUBSYS. As such it is not a bug, just a very poorly thought out feature. -------- 16-Apr-81 23:36:08-EST,1016;000000000000 Mail from MIT-MC rcvd at 16-Apr-81 2336-EST Date: Thursday, 16 April 1981 23:31-EST From: Chris Ryland To: Admin.MRC at Score, Local-Nets at MIT-MC Reply-to: CPR at MIT-MC Subject: DEC-20 sites: building your own DN20, revisited (Mark, please forward this to your Twenex mailing list; forgive duplications.) This is to announce a revised edition of Randy Frank's "Building your own DN20" document, which I have put together from our little message exchange. If you have a -20 and are interested in putting a front-end on it for any number of reasons (most of us just want to get Unibus devices interfaced to the KL), this may be interesting to you. The document is at MIT-MC, file spec CPR;DN20 ERECTR (it's FTP'able without logging in, of course). This may be updated as time goes by and we think of new things to put in it; other sites that suffer the slings and arrows of similar ventures are invited to send me mail about their experiences so we can all benefit. 17-Apr-81 00:33:41-EST,1239;000000000000 Mail from SU-SCORE rcvd at 17-Apr-81 0033-EST Mail-from: ARPANET site MIT-AI rcvd at 16-Apr-81 2027-PST Date: Thursday, 16 April 1981 23:31-EST From: Chris Ryland To: Admin.MRC at Score, Local-Nets at MIT-MC Reply-to: CPR at MIT-MC Subject: DEC-20 sites: building your own DN20, revisited Remailed-date: 16 Apr 1981 2127-PST Remailed-from: Mark Crispin Remailed-to: REG at SU-AI, [SU-SCORE]TOPS-20.DIS.86: ; (Mark, please forward this to your Twenex mailing list; forgive duplications.) This is to announce a revised edition of Randy Frank's "Building your own DN20" document, which I have put together from our little message exchange. If you have a -20 and are interested in putting a front-end on it for any number of reasons (most of us just want to get Unibus devices interfaced to the KL), this may be interesting to you. The document is at MIT-MC, file spec CPR;DN20 ERECTR (it's FTP'able without logging in, of course). This may be updated as time goes by and we think of new things to put in it; other sites that suffer the slings and arrows of similar ventures are invited to send me mail about their experiences so we can all benefit. 17-Apr-81 00:39:53-EST,1239;000000000000 Mail from SU-SCORE rcvd at 17-Apr-81 0039-EST Mail-from: ARPANET site MIT-AI rcvd at 16-Apr-81 2027-PST Date: Thursday, 16 April 1981 23:31-EST From: Chris Ryland To: Admin.MRC at Score, Local-Nets at MIT-MC Reply-to: CPR at MIT-MC Subject: DEC-20 sites: building your own DN20, revisited Remailed-date: 16 Apr 1981 2127-PST Remailed-from: Mark Crispin Remailed-to: REG at SU-AI, [SU-SCORE]TOPS-20.DIS.86: ; (Mark, please forward this to your Twenex mailing list; forgive duplications.) This is to announce a revised edition of Randy Frank's "Building your own DN20" document, which I have put together from our little message exchange. If you have a -20 and are interested in putting a front-end on it for any number of reasons (most of us just want to get Unibus devices interfaced to the KL), this may be interesting to you. The document is at MIT-MC, file spec CPR;DN20 ERECTR (it's FTP'able without logging in, of course). This may be updated as time goes by and we think of new things to put in it; other sites that suffer the slings and arrows of similar ventures are invited to send me mail about their experiences so we can all benefit. 18-Apr-81 10:29:14-EST,468;000000000001 Mail from SU-SCORE rcvd at 18-Apr-81 1029-EST Date: 18 Apr 1981 0726-PST From: Mark Crispin Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022 Stanford-Phone: (415) 497-1407 Subject: fork 1 To: [SU-SCORE]TOPS-20.DIS.87: ; Does anybody know what fork 1 of job 0 is? It has zero runtime, all zeroes in its UPDL, and is halted. It seems to have last run a second or two after the system was loaded. ------- 23-Apr-81 00:06:08-EST,1146;000000000000 Mail from SU-SCORE rcvd at 23-Apr-81 0005-EST Date: 22 Apr 1981 2101-PST From: Mark Crispin Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022 Stanford-Phone: (415) 497-1407 Subject: [MILLER at DEC-MARLBORO: Re: fork 1] To: [SU-SCORE]TOPS-20.DIS.88: ; Thanks goes to everybody who responded to my message about what fork 1 is. There were lots of guesses (TGHA, SYSERR, HSYS, expunge) but this seems to be the right answer: --------------- Mail-from: ARPANET site DEC-MARLBORO rcvd at 21-Apr-81 1343-PST Date: 21 Apr 1981 1641-EST From: MILLER at DEC-MARLBORO To: Admin.MRC at SU-SCORE Subject: Re: fork 1 Message-ID: In-reply-to: Message from Mark Crispin of 18-Apr-81 1026-EST I believe that it is the IPCF page mode fork. The system creates a fork simply to ravage its address space in order to hold pages of IPCF messages waiting to be recieved. The fork never runs beyond its inititialization code. -------- --------------- ------- 23-Apr-81 20:44:09-EST,1969;000000000000 Mail from SU-SCORE rcvd at 23-Apr-81 2043-EST Mail-from: ARPANET site RUTGERS rcvd at 23-Apr-81 1317-PST Date: 23 Apr 1981 1608-EST From: WATROUS at RUTGERS Subject: DUMPER bug causes problems during archive retrieval To: Admin.MRC at SU-SCORE Remailed-date: 23 Apr 1981 1734-PST Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.88: ; We have discovered that DUMPER has a bug in it which causes it to create savesets which have different saveset numbers in the records from the saveset number indicated by the character string in the header record. This caused the the problem that restore requests from archive tapes were not being found on the tapes which had the errors. Following is a patch which will enable DUMPER to use the tapes with these errors. (We didn't find the bug, but suspect there is something wrong in the recovery from a catastrophe during an archive run.) ======================== Just before LODFIL insert: jrst lodfil ;skip this code lodfia: move a,buff+bfmsgp ;get offset of header text hrroi a,buff+2(a) ;point directly to saveset# movei c,^d10 ;get it in decimal movei d,xbuff nin ;read it from header load b,ssno,(d) ;use this if fails load c,ssno,(d) ;compare it with binary info skipn arctsn ;if no previous problems came b,c ;and if they match, skipa jrst lodfil ;no problem push p,b ;tuck away right info hrroi b,[asciz \%Saveset info in headers disagrees with that in records. Using info from headers. \] ;complain skipn arctsn ;if this is first time call tmsgqc pop p,arctsn ;save correct information Change the JRST LODFIL in the literal at LODHX2+5 to JRST LODFIA At LODRET+15(octal), just before the CAIE A,0(B) insert: skipe arctsn ;have better info? move b,arctsn ;yes - use that At RETTAP+1, insert: setzm arctsn ;no alternate saveset# yet ======================== ------- 26-Apr-81 23:04:44-EDT,754;000000000000 Mail from SU-SCORE rcvd at 26-Apr-81 2304-EDT Mail-from: ARPANET site MIT-XX rcvd at 26-Apr-81 1336-PDT Date: 26 Apr 1981 1635-EDT From: Nat Mishkin Subject: DUMPER To: admin.mrc at SU-SCORE Remailed-date: 26 Apr 1981 1943-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.88: ; That message about the DUMPER bug reminded me of a DUMPER problem which I've experienced a few times. Namely, after retrieving a set of archived files DUMPER seems to hang up: I think this happens before the last "[OK]". The tape doesn't move and DUMPER is SLEEPing. The last file has in fact been retrieved. Any comments? Could you disseminate this as you deem appropriate? ------- 27-Apr-81 12:59:22-EDT,243;000000000000 Mail from MIT-MC rcvd at 27-Apr-81 1259-EDT Date: 27 Apr 1981 1153-CDT From: Edward C. Pattermann Subject: VTTREK To: twenex-wizards at MIT-MC Anyone know where I can get a copy of VTTREK? Thanks, Ed ------- 27-Apr-81 14:25:01-EDT,490;000000000000 Mail from MIT-MC rcvd at 27-Apr-81 1424-EDT Date: 27 April 1981 14:16-EST From: Christopher P. Ryland Subject: VTTREK To: G.ECP at UTEXAS-20 cc: TWENEX-WIZARDS at MIT-MC Date: 27 Apr 1981 1153-CDT From: Edward C. Pattermann To: twenex-wizards Re: VTTREK Anyone know where I can get a copy of VTTREK? Thanks, Ed Sorry, Eric never got back to me on this. I'm in CA now, by the way; started work here today. 28-Apr-81 22:06:07-EDT,1418;000000000001 Mail from SU-SCORE rcvd at 28-Apr-81 2205-EDT Date: 28 Apr 1981 1900-PDT From: Mark Crispin Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022 Stanford-Phone: (415) 497-1407 Subject: RSX-20F field test To: [SU-SCORE]TOPS-20.DIS.88: ; [TOPS-20.DIS was protected by accident. I've unprotected it again. -- MRC] --------------- Date: 28 Apr 1981 1200-PDT From: Frank da Cruz Subject: For distribution (TOPS-20.DIS is read protected?) To: Admin.MRC Perhaps foolishly, I've agreed to field-test RSX20F version 14. DEC says it has: 1. Improved buffer management. 2. Improved flow control when buffer space low. 3. Removal of BF1, B01, B02, SAI and SAQ stopcodes. 4. Echoing of BELLs when buffer space not available (after sending XOFF I presume. By the way, did you know that TOPS-20 already does this when the FE attempts to give the KL some characters and the KL can't find any place to put them?). 5. Optional running of CHK11 in the primary FE. 6. Bugs fixed in modem control code. 7. Automatic execution of PARSER.CMD when the KL crashes. Also, I hear DEC is sending out feelers to find field testers for TOPS-20 release 5, "Pascal 36" (U. of Washington Pascal, same as on VAX), and "Common APL". - Frank da Cruz, Columbia U. ------- --------------- ------- 28-Apr-81 22:16:33-EDT,2621;000000000001 Mail from SU-SCORE rcvd at 28-Apr-81 2216-EDT Date: 28 Apr 1981 1234-PDT From: Frank da Cruz Subject: Re: [CSD.Milligan: Release 4 and XON/XOFF] (for forwarding) To: Admin.MRC In-Reply-To: Your message of 15-Apr-81 0020-PST Remailed-date: 28 Apr 1981 1904-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.88: ; Don't know if you've already had some replies already, but yes, you're right about what DEC had to do to RSX20F in Release 4 in order to accommodate VT100's - in fact, they changed the silo interrupt level from 16 to 1! When we first installed the R4 FE software, the FE was crashing like crazy because it couldn't shuffle its little buffers fast enough. You could almost always make this happen by doing a page transmit from a batch-mode terminal, or by reading data from a floppy (in either case, the culprit was not doing XON/XOFF, of course). DEC's solution to the problem was to have the FE always send an XOFF to a line it deemed "obnoxious" and if, within x character times, the line does not quiet down, the speed is set to zero for y amount of time. X and Y can be varied by changing monitor code as follows: TTQAD1/ movei t1, 5670 {the immediate quantity is the amount of time to set the speed to zero} BIGST2+2/ cail c, 50 {the immediate quantity is the number of chars seen since XOFF was sent before turning off the line} There are optimum values for these two numbers, depending very much on what goes on at your particular site. It's probably not a very good idea to monkey with them too much. The real problem is that a PDP-11/40 running RSX20F just can't be expected to handle high speed input from non XON/XOFFing lines because it's just too small and slow. The next release of RSX20F alleges to have improved its capabilities in this area, but we'll have to wait & see. By the way, even if you get your high speed input past the front end, there's still the back end to worry about, as we discovered when we were fooling with file transfer between the -20 and micros over TTY lines. The only reliable way of getting data through the front end is to have a protocol, and somebody checking things on both ends. This holds even when both sides are doing XON/XOFF. Another by the way - I've heard of people hooking up high speed terminals to a -20 in other ways that on ordinary TTY lines. Maybe that's what you really want to do. I understand that CMU has PERQ's and a -20; maybe they have them talking already. - Frank da Cruz, Columbia U. ------- 29-Apr-81 20:11:00-EDT,745;000000000000 Mail from SU-SCORE rcvd at 29-Apr-81 2010-EDT Date: 29 Apr 1981 1703-PDT From: g.eldre at SU-SCORE (Tim Eldredge) Subject: Request for information To: [SU-SCORE]TOPS-20.DIS.88: I have an autodialer on my 20 which needs DTR to be raised before it will dial. When I was running Rel3A all seemed to be well, but now that I am running Rel4 it no longer works. I have observed that DTR is not on. Can anyone tell me if it is on in Rel3A (when the line is not in use of course, it does come up if the phone rings)? Further, do any of you know how I might convince the front-end to raise DTR at my bidding. I'm quite willing and able to change the monitor, but hacking at the -11 is out of bounds. Thanks Tim ------- 30-Apr-81 02:48:07-EDT,888;000000000000 Mail from SU-SCORE rcvd at 30-Apr-81 0248-EDT Date: 29 Apr 1981 1703-PDT From: g.eldre at SU-SCORE (Tim Eldredge) Subject: Request for information To: [SU-SCORE]TOPS-20.DIS.88: Remailed-date: 29 Apr 1981 2346-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.88: ; I have an autodialer on my 20 which needs DTR to be raised before it will dial. When I was running Rel3A all seemed to be well, but now that I am running Rel4 it no longer works. I have observed that DTR is not on. Can anyone tell me if it is on in Rel3A (when the line is not in use of course, it does come up if the phone rings)? Further, do any of you know how I might convince the front-end to raise DTR at my bidding. I'm quite willing and able to change the monitor, but hacking at the -11 is out of bounds. Thanks Tim ------- 30-Apr-81 10:29:08-EDT,580;000000000000 Mail from SU-SCORE rcvd at 30-Apr-81 1029-EDT Date: 30 Apr 1981 0729-PDT From: Mark Crispin Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022 Stanford-Phone: (415) 497-1407 Subject: duplicate mail message To: [SU-SCORE]TOPS-20.DIS.88: ; My apologies for the duplicate message sent to the distribution list yesterday. My mail reader's profile is set up to suppress all header lines except for From: and Subject: by default. I remailed the message without thinking to check the To: list first. -- Mark -- ------- 30-Apr-81 23:51:43-EDT,591;000000000000 Mail from MIT-MC rcvd at 30-Apr-81 2351-EDT Date: 30 Apr 1981 2145-MDT From: Randy Frank Subject: Sources to LOOK Program To: twenex-wizards at MIT-MC Does anyone have the sources to the LOOK program (it's a program counter histogram program that also gives output in terms of the symbol table). Unfortunately, it has several losses we want to fix (namely it picks bucket sizes in a strange and not very useful way). Pointers appreciated. (I think it came from DEC somewhere; I've already chased down a pointer to the SWSKIT tape with no luck). ------- 2-May-81 12:55:18-EDT,3206;000000000000 Mail from SU-SCORE rcvd at 2-May-81 1255-EDT Date: 1 May 1981 1746-PDT From: Bill Schilit Address: 715 Watson Labs, Columbia University, NYC 10027 Subject: Sysjob and the future To: admin.mrc cc: g.Mr-Bill Remailed-date: 2 May 1981 0954-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.90: ; Hi, the other night Andy and I wrote out a skeleton version of a new sysjob. We were motivated when all our local hacks to the program got "lost" in a source disaster... well I'm sending this along because I want to pick your brain a little, and to ask if you have heard of any like endeavors, or know of the history of this program (judging from the source it was written in one sitting when TOPS-20 was still a babe, no monsym, getting TTYJOB from SYSGT% instead of using .ttyjo etc.). Here are somethings we'd like to see in our version: System startup output to a file. This already seems to be standard at SCORE and CU with the quiet feature. OUTPUT filename - sends sysjob output to a file (or tty) Waiting for the 300 baud console when advising subjobs is a pain. Slowness when when starting up pty subjobs bypassed. We noticed that sysjob waits 30 seconds for each pty job to start up during initialization. This means about four minutes at CU (though I noticed you guys run only one pty job so you probably don't notice this as much. No more "to much input for line", we installed a dynamic memory allocator. Free format time and date input for the attime command. This allows for +time, monday + time, etc. Take notice if a subjob becomes detached from its pty. This has happened here when a bad guy got the operator password and attached. When this happens print a message on the console, and stop sending output to the pty until it comes back. Optionally log output to a file in addition to printing the stuff on the console. We want this one because the machine room is sooooo far away. Time stamp the output as you do. A TAKE command so we don't have to copy foo.cmd to system:sysjob.commands and wait around for it to get noticed. Inferior fork command parser uses comnd. This is one of the more esoteric mods since most people don't use it. Internal modifications include parsing with comnd and a neater format for the program, much of the original code remains intact. All the old command formats remain the same (for compatibilities sake - waaa). Also it might be nice to write a command parser called espeak which will make sure you are sending correct stuff (by using comnd) to the sysjob.commands file. Our favorite of these is something Andy and Jeff Damens came up with; the output command. We have had problems though of people outputting to their tty: and then detaching... this somethimes causes hanging. To avoid this checking is made and maybe an attime command will be generated for five minutes after the output command is given echoing first a warning, and then another attime command re-redirecting to the console. I'd be glad to hear comments, suggestions, or "what I hate about sysjob is..."s. /Bill ------- 4-May-81 13:14:58-EDT,627;000000000000 Mail from MIT-MC rcvd at 4-May-81 1314-EDT Date: 4 May 1981 13:08-EDT From: Christopher P. Ryland Subject: Twenex-Wizards mailing list now defunct To: Paetzold at RADC-TOPS20, Pratt at RADC-TOPS20, JGOLDBERGER at USC-ISIB cc: TWENEX-WIZARDS at MIT-MC I've decided to abandon this mailing list, since there's no sense in trying to keep it up to date with MRC's list of -20 systems types, and since some of the mail concerns security issues. Please send all future mail to Admin.MRC at SU-Score, whence Mark will forward it appropriately; if you want to be on his mailing list, contact him. 4-May-81 23:40:07-EDT,589;000000000001 Mail from SU-SCORE rcvd at 4-May-81 2340-EDT Mail-from: ARPANET site RUTGERS rcvd at 4-May-81 2033-PDT Date: 4 May 1981 2322-EDT From: HEDRICK at RUTGERS Subject: question about J0NRUN bughlt To: admin.mrc at SU-SCORE Remailed-date: 4 May 1981 2040-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.91: ; We have been getting J0NRUN's at the rate of about once a week, on two different systems. Fork 0 seems to be hung at DDMP waiting to get the structure lock STRLOK. Anybody have any idea what is going on? ------- 6-May-81 20:25:01-EDT,1121;000000000000 Mail from MIT-XX rcvd at 6-May-81 2024-EDT Date: 6 May 1981 2023-EDT From: Nat Mishkin Subject: Wonderful world of patching To: [SU-SCORE]TOPS-20.DIS.92: ; In case everyone hasn't heard about DEC's new software "product", I thought I'd mention their new object-level automatic patcher. Basically its a little data base maintainter that keeps track of all the patches you've applied. It "interfaces" with MAKLIB. Apparently DEC plans on distributing tapes for use by this tool. Presently they support patching the monitor, EXEC and APL. Unfortunately, this is all fairly useless if you've modified any stuff locally to any great degree. Now I know you'll say: "that's what you get for grubbing in system software" and I'd probably agree. It would be nice however, that as long as DEC is sending out these tapes if they'd supply some source-level patches. Presently, the only user interpretable stuff is an about 2000 line edit history. Some of the patches might be nice to apply if one had the source level change. Anyone think they might be convinced? ------- 9-May-81 16:51:33-EDT,839;000000000000 Mail from SU-SCORE rcvd at 9-May-81 1651-EDT Mail-from: ARPANET site USC-ECLB-IPI rcvd at 8-May-81 1742-PDT Date: 8 May 1981 1742-PDT From: Mark Thompson PHE 232; USC: (213) 743-7121 Subject: fix for low load averages To: Admin.MRC at SU-SCORE, Smith at USC-ISIB Remailed-date: 9 May 1981 1347-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.92: ; i remember there was a problem people noticed where if the load average got very, very low (below about .01), tops20 would start giving truly awful response (on the order of several seconds between action and response). I seem to have this problem, does either of you remember the fix? (My fix was to run SYSBIG to thrash the machine, but thats not really right...). mark ------- 11-May-81 13:57:24-EDT,390;000000000000 Mail from MIT-MC rcvd at 11-May-81 1357-EDT Date: Monday, 11 May 1981 10:47-PDT To: local-nets at MIT-MC Subject: DEC and Ethernet From: mike at RAND-UNIX According to MIS Week (which is often very, very wrong) DEC's David Rodgers announced at the NCC that DEC was one to two years from producing an Ethernet product. He claimed that they had only the rawest of prototypes. 11-May-81 14:39:27-EDT,1387;000000000000 Mail from MIT-MC rcvd at 11-May-81 1439-EDT Date: 11 May 1981 1201-MDT From: Randy Frank Subject: DEC and Ethernet To: local-nets at MIT-MC cc: griss at UTAH-20, lepreau at UTAH-20, crossland at UTAH-20, thomas at UTAH-20 Confirming what Mike said, I talked to Dave Rodgers at NCC. At the NCC DEC had a VERY prototype ethernet interface. It was bread boarded, was not a DMA (NPR) device, and was not even prototypical of the control register structure they eventually plan on using. The only real ethernet "product" at the show was an Intel multibus interface, which meets the full spec (does data link layer on the board). It is a two board set, and is designed to conform to the eventual architecture of the VLSI chip set (the current product is a MSI implementation using off the shelf communications controller chips). Delivery is scheduled for fourth quarter, with pricing about $4K. Dave Rodgers of DEC did say that it is DEC's policy to make available the print set for the current prototype (the one mentioned above) to universities who want to use it to design their own 10MB ethernet interfaces. How useful it would be, especially since it's not a NPR device, is questionable. There are, of course, the rumors about a 3-COM 10MB Unibus ethernet interface to be available in the not too distant future... Randy ------- 18-May-81 10:16:47-EDT,690;000000000000 Mail from MIT-MC rcvd at 18-May-81 1016-EDT Date: 18 May 1981 0639-EDT From: JIS at MIT-XX Subject: I am hacking with ORION To: Wallace at MIT-XX cc: Twenex-Wizards at MIT-MC To allow people with the CIA bit to run it. I am putting this change in so that we can give this bit out to TA's so they can unwedge our line printers. If I here any objections I will put this under an EE only conditional, but I would rather not put this site dependance in if it isn't truely necessary. I will probably be hacking with this stuff in the near future so as to get a workable version of the galaxy stuff working at EE, ours is really broken for the most part... -Jeff ------- 18-May-81 12:56:08-EDT,1164;000000000000 Mail from SU-SCORE rcvd at 18-May-81 1256-EDT Mail-from: ARPANET site MIT-XX rcvd at 17-May-81 1018-PDT Date: 17 May 1981 1300-EDT From: Nat Mishkin Subject: Power fail To: admin.mrc at SU-SCORE Remailed-date: 18 May 1981 0947-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.92: ; Remail as deemed appropriate: During the past few days we've been having thunder storms and power glitches. There are at least 2 problems with TOPS-20's power fail restart logic: - If the power goes off for anything more than a few seconds (I guess) it might as well not try to do the power fail restart logic if you have any MOS memory. Its really pitiful to see it grope its way back to consciousness only to find scrambled bits. I guess it makes it as far as its does only because we have 256K core. - When a power fail restart does succeed, the remote lines don't get reset right and you have to crash the FE to get things straightened out. Anyone got any quick fixes for such problems? -- Nat Mishkin Yale Computer Science Dept. ------- 26-May-81 20:36:43-EDT,582;000000000000 Mail from SU-SCORE rcvd at 26-May-81 2036-EDT Mail-from: ARPANET site RAND-AI rcvd at 26-May-81 1700-PDT Date: 26 May 1981 1658-PDT From: Jim Guyton Subject: Twenex RS232 Flow Control To: Admin.MRC at SU-SCORE cc: Guyton at RAND-AI Remailed-date: 26 May 1981 1731-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.92: ; Hi, Do you know offhand if the standard twenex tty drivers are set up to handle the Clear-To-Send lines on the RS232 connections for flow control? Thanks, Jim ------- 27-May-81 14:24:42-EDT,1380;000000000001 Mail from SU-SCORE rcvd at 27-May-81 1424-EDT Date: 27 May 1981 1118-PDT From: Frank da Cruz Subject: Short flame about RSX20F To: [SU-SCORE]TOPS-20.DIS.92: ; I understand that at DECUS, DEC said they would not consider letting sites configure RSX20F to provide more TTY buffer space at the expense of unnecessary device support, because buffer space is not a problem any more. Well, maybe that's true in Marlboro where everybody has XON/XOFFing terminals (like DEC wants us to have). Or maybe they figure that just because the front end doesn't crash with buffer allocation errors as much as it used to that everyone is happy. In fact, there have always been, and always will be, requirements for high speed - or at least continuous - input from TTY lines, and the present technique of periodically turning off such lines may well prevent crashes, but it doesn't let us get our data in. To my knowledge, most other DEC systems (PDP-11's and VAXes) don't have this problem -- nobody has ever noticed these machines crashing when you read from a floppy disk, or connect another computer, via TTY line. I don't think RSX20F would be setting our line speeds to 0 if buffers were not a problem. Maybe the problem will go away in version 14 (we still haven't received the field test). - Frank da Cruz, Columbia U. ------- 27-May-81 18:46:00-EDT,2461;000000000000 Mail from SU-SCORE rcvd at 27-May-81 1845-EDT Mail-from: ARPANET site RUTGERS rcvd at 15-May-81 1539-PDT Date: 15 May 1981 1300-EDT From: HEDRICK at RUTGERS Subject: distribution of mail outside the arpanet To: admin.mrc at SU-SCORE Remailed-date: 27 May 1981 1543-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.92: ; I am not quite sure who to send this to. What I would really like is to reach system managers on the net. But since I mostly deal with DEC-20 sites, this seems like a reasonable approximation. Apparently my communications have a way of propagating what I intended. It is unclear to me whether this is appropriate or not. I would like to be able to use our bulletin board to make somewhat editorial comments to my users. E.g. when I come back from a conference, they expect to find out what I thought about it. They also expect to hear what is going on with our hardware. It is fairly clear that the tone of these comments might be different in this case than if I were writing an article to be distributed in a national magazine. At the moment, however, I have gotten enough feedback from people concerned that I am having to write all messages to BBOARD as if the whole world was going to read them. QLt is more alarming, apparently the way to reach the top level management of a certain vendor (please don't make unwarranted assumptions - I am not talking about DEC) is to respond to a request for information about a product from a user elsewhere on the Arpanet. I would like to believe that I can respond to such requests without having to worry that I am going to find a marketing person calling on my boss to complain about what I said. (Yes, that actually happened.) I'm not sure what I expect all of you to do about this. Possibly just be a bit careful about redistributing messages. I would consider it polite to get the author's permission before distributing something, even if it was made public on the author's system. Certainly private communication should not be distributed without permission. However at the moment I guess I am going to have to write all BBOARD notices as if they were going to be published in Computerworld, and only give candid evaluations of products to people that I know. (Another alternative would be to request that the person involved call me, so there was nothing in writing.) ------- 27-May-81 18:51:53-EDT,1645;000000000000 Mail from SU-SCORE rcvd at 27-May-81 1851-EDT Mail-from: ARPANET site BBNG rcvd at 15-May-81 0427-PDT Date: 15 May 1981 0723-EDT From: Dan Tappan Subject: Possible Bug To: Admin.MRC at SU-SCORE Remailed-date: 27 May 1981 1549-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.92: ; Mark, I've noticed what looks to me like a fairly noxious bug, if fact it looks so bad that I can't really believe it's there. Would you check me on this? In the TTY and DTE code there are a lot of CHNOFF/CHNON DLSCHN pair. They seem to occur (at least a couple I traced all the way back) in normal process context, not NOSKED. It seems to me that this means that the process can get descheduled in between. a) That leaves the channel off for an arbitrarily long length of time and b) The channel probably gets turned back on by a different process (since CHNOFF's aren't additive, another process going through a CHNOFF/CHNON pair leaves the channel on) so the original process is unprotected when it finally resumes. Is this actually true? The worst thing is: DLSCHN happens to be channel 6, the same channel everything else (IMP's disks etc) is on. Dan ------- Mail-from: ARPANET site BBND rcvd at 15-May-81 0648-PDT Date: 15 May 1981 0948-EDT From: TAPPAN at BBND (Dan Tappan) Subject: Re: Possible Bug To: Admin.MRC at SCORE Hmmm, On second look the bug may not be as widespread as I thought, most of the instances do seem to go NOSKED. The one I saw first, however, (In TTYDEA) doesn't, so that may be an isolated bug. Dan ------- 27-May-81 19:12:58-EDT,723;000000000000 Mail from SU-SCORE rcvd at 27-May-81 1912-EDT Date: 27 May 1981 1607-PDT From: Mark Crispin Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022 Stanford-Phone: (415) 497-1407 Subject: a personal note To: [SU-SCORE]TOPS-20.DIS.92: ; Friends - I would like to take a moment away from bug fixing and folklore for a personal note. Yesterday afternoon at 3:14PM Lynn Gold and I were married in a private civil ceremony in San Jose. Lynn's a former English major who got hooked on DEC-20's about a year ago. We met, believe it or not, as a result of an MM bug report (don't ask). Some good things do happen on these 'puters! -- Mark -- ------- 28-May-81 14:03:21-EDT,1156;000000000001 Mail from SU-SCORE rcvd at 28-May-81 1403-EDT Date: 28 May 1981 1101-PDT From: Ted Markowitz Subject: Re: Short flame about RSX20F To: G.DACRUZ, admin.mrc cc: G.TJM In-Reply-To: Your message of 27-May-81 1121-PDT Remailed-date: 28 May 1981 1102-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.92: ; I would like to pour some gasoline on the RSX20F flame by Frank da Cruz. I'm in the process of hooking two -20's together via TTY lines for simple- minded FTPing (the cable is only ~ 10 feet long). It's inconceivable to me that I can't move the data throught this "CheapNet" at a speed of more than 300 baud with either front-end crashes or horrible data lossage. DEC never seemed to take into account anything hanging off the end of a TTY port other than a medium-speed typist. If they really have solved the buffering problem, then why is this still a reality? I can only hope that FDC's test RSX20F shows some improvement. Perhaps DEC doesn't really see this as a problem area or perhaps Marketing is currently pushing DN20's? I wonder... --Ted Markowitz ------- 29-May-81 14:37:13-EDT,1452;000000000000 Mail from SU-SCORE rcvd at 29-May-81 1437-EDT Date: 29 May 1981 1111-PDT From: Mark Crispin Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022 Stanford-Phone: (415) 497-1407 Subject: hung job folklore To: [SU-SCORE]TOPS-20.DIS.92: ; Have you ever had the bug where a job is looping through its address space with no pages mapped, getting lots of illegal instruction PSIs, chomping up the CPU, no JFNs, one fork, and impossible to log out? The job is trying to log out, but it is stuck in this losing state. LOTS and Columbia seem to have it happen a lot to them. It happened to SCORE just a few minutes ago. I successfully backed out of the state by doing the following: I modified ITR2+n (before the JRST MRETN) to see if the fork was the losing fork. If so, I replaced UPDL/UPDL+1 and UPDL+2/UPDL+3 with an exec mode PC/flags doubleword to go to FLOGO. I got an OPOPAC bug halt, which I backed out of by AOS CX,ACBAS and starting at MRETN1+12 (right before the XCT OPOPAC). I suspect that it would work to AOS ACBAS when you stomp on the UPDL return PC/flags doubleword; if you don't have EDDT loaded you'd probably have to do this! I still don't know why the bug happens, but having a way to back out of the losing state is sure helpful. Have any of the DEC folks seen this condition and/or have any idea why it has happened? -- Mark -- ------- 29-May-81 14:46:21-EDT,1394;000000000001 Mail from SU-SCORE rcvd at 29-May-81 1446-EDT Mail-from: ARPANET site RUTGERS rcvd at 29-May-81 1013-PDT Date: 29 May 1981 1312-EDT From: HEDRICK at RUTGERS Subject: DECUS menu items To: admin.mrc at SU-SCORE cc: ricart at RUTGERS Remailed-date: 29 May 1981 1112-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.92: ; Somehow we seem to have missed one possible MENU item at the last DECUS. At least I didn't hear it addressed. I conjecture this is because there was no session at which it would have been appropriate. That is making RSX-20F understand high-speed input. I propose to get a number of sites to petition DECUS to add that to the list of MENU items retroactively. If it is not possible, then I propose to issue a joint letter signed by as many system administrators as possible, to Rose Ann, with a copy to At Large. I am getting tired of DEC saying that they only support slow typists, and that all problems are solved in the next release. Would you please send this to the Tops-20 distribution list. I would appreciate hearing from any DECUS Installation Delegates who would be willing to endorse a letter asking that this be added retroactively to the MENU, and any system administrators who would be willing to sign such a letter directly to DEC. Please send me a U.S. Mail address. ------- 29-May-81 18:24:11-EDT,1308;000000000001 Mail from SU-SCORE rcvd at 29-May-81 1824-EDT Mail-from: ARPANET site RUTGERS rcvd at 29-May-81 1013-PDT Date: 29 May 1981 1302-EDT From: hemphill@rutgers Subject: Data transfer over async. Lines. To: ADMIN.MRC at SU-SCORE cc: RGSMITH.HEMPHILL at RUTGERS Remailed-date: 29 May 1981 1515-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.93: ; We at DREA are currently using a standard TTY line to communicate with an 11/60 running RSX11-M. The main clue seems to be to use the line in a half duplex fashion ie. each block of data requires a confirmation before the next is sent. We have developed a simple protocal for transfering 8-bit data in both directions (with the line speeds set to 9600 baud) and to date have not had any problems with front end crashes. The effective throughput rate depends (of course) on the 20 load but we find that under low load averages it is about 5600 baud dropping to about 500 baud at a load of 6 (we currently are running a 2050 with .5 M of memory). We will be happy to send a copy of the protocal to anyone interested but that is about the best we can do till we actually get on the net. By the way the 20 end of the program is written in SAIL. ------- 31-May-81 14:45:17-EDT,2416;000000000000 Mail from SU-SCORE rcvd at 31-May-81 1445-EDT Mail-from: ARPANET site MIT-XX rcvd at 31-May-81 0818-PDT Date: 31 May 1981 1120-EDT From: Nat Mishkin Subject: Re: hung job folklore To: Admin.MRC at SU-SCORE Remailed-date: 31 May 1981 1140-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.94: ; I've got an idea about your problem. I've had the same one several times. My theory is that the EXEC (or whoever happens to be at the top level) has somehow gotten trashed but it still has "illegal instr trap" enabled; unfortunately the illegal instr trap routine is also trashed. Maybe there's something preventing an infinite loop on this situation...but I'm not sure. In any case, the way I stop this kind of job is by patching in a HALTF instream in mon context which will get executed only by the offending fork. Recently, I've also used the following technique: - map the fork's PSB and JSB into a user context which has MONITR.EXE in it (this is a DEC hack written up in one of their SWSKIT documents; I can provide it if necessary). - Move a HALTF into UAC+1 (user context AC 1). - Change UPDL (base of mon context stk; user mode return addr) to contain 0; the next time the fork enters user context, it'll execute the HALTF. This step may have to be repeated a few times since the fork may have been in user context when you changed UPDL. Great hack, eh? Of course this only halts the fork...you still can't log it out...but at least it isn't swamping your machine. This technique is preferable to the instream patch since you don't have to go modifying monitor code on the fly (always a dangerous proposition). By the way...I'm in the process of writing up some of this folklore. The document will contain all this kind of junk one picks up from poking the monitor. It starts with a description of what user/mon context is and how JSYSes work. It will contain procatical info about E/MDDT and how you can tweak the monitor on the fly. Has anyone else ever worked on such a document? Unfortunately, the documentation is on my non-ARPA machine at Yale. If there is sufficient interest, I can mail a tape to someone on the net. Yale may be on the net in the fall anyway (don't hold your breath though). -- Nat Mishkin Yale CS Department ------- 1-Jun-81 12:45:07-EDT,2298;000000000001 Mail from SU-SCORE rcvd at 1-Jun-81 1245-EDT Mail-from: ARPANET site RUTGERS rcvd at 31-May-81 1253-PDT Date: Sunday, 31 May 1981 15:52-EDT From: Jonathan Alan Solomon To: Nat Mishkin Cc: Admin.MRC at SU-SCORE, Solomon at RUTGERS Subject: hung job folklore Remailed-date: 1 Jun 1981 0937-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.94: ; Hmm.. We have those types of jobs all the time. What I do is pretty simple and most of the time works (save one bugchk). Get into SYSDPY and find out what the monitor thinks the fork's number is. Then go into MDDT: FFF/CAIN FX,Fork-number FFF+1/RET FFF+2/JRST GOCONC and the clincher: RTG2+3/JRST FFF to crash the system or be fine... BUGCHK .... [Phew] Actually it works fine every time, though the monitor doesnt expect you to tell the scheduler not to schedule this fork in quite this way. Occasionally we get two or three of them, in which case we do the CAIN/CAIE jumps to stop both of them, *or* treat them specifically (if three or more, for example) (in other words, dont JRST GOCONC until you have stopped all the offending forks). Im sure there are better ways to do it, but We have left these hung jobs on the system for two weeks or so and it has not effected system performance in the least (though NBAL and NRUN are off by the number of hung forks we have). The biggest problem we have in doing this is if we leave the jobs detached our Exec offers them to unsuspecting users to attach to (when you log in we prefer you attach to your detached jobs so we made it convenient for you to do so). Therefore I usually put them on a PTY (its the not logged in jobs that are hardest to put on a pty). They look funny in the finger listing (Tee hee). Oh, a fairly reproducable way to hang yourself this way is to use MRC's TELNET to open a connection to your controlling terminal, then type a ^C or two and then a ^^C (control-uparrow C to close the connection). The fork gets stuck in CLOSF and then when you log the job out you get a single fork hung job chomping on the CPU (im sure thats not the only way to do it). Cheers, JSol 1-Jun-81 12:59:15-EDT,2467;000000000000 Mail from SU-SCORE rcvd at 1-Jun-81 1259-EDT Mail-from: ARPANET site CMU-20C rcvd at 31-May-81 1754-PDT Date: 31 May 1981 2048-EDT From: WOHL at CMU-20C Subject: Hung jobs. To: Admin.MRC at SU-SCORE Remailed-date: 1 Jun 1981 0951-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.95: ; How to nuke such a job: FFF/ SETO 1, / LGOUT% (or WAIT% to just make it quite down). / erjmp .+1 / jrst jtenqe+2 ILUUO+1/ JRST FFF You may wish to check the job or fork number. The reason the problem happens seems to be do to a combination of the following two problems: 1) When a job gets a carrior-off psi, in SCHED at PIRLG1+1 there is a MOVE T2,PIFL to pick up the current flags. But the new flags are not set so the carrior off psi (or remote logout psi!) is handled in the current mode. This causes the top fork to sometimes jump to the JOBCOF or FLOGO address in the USER context of the top fork... To fix the problem: Replace the MOVE T2,PIFL with SETZ T2, ;Handle in monitor mode please. EXCH T2,PIFL ;Get current, set new. To test the fix, go into PTYCON and log in a job, go into EDDT on its top fork and have it loop doing a JRST . (so it is running in user mode). Then push from ptycon and do a logout on the job. Before putting in the fix you will get a ?internal illegal instruction at PC=FLOGO+1, after the fix the job should logout (as soon as you let it type out its bye message). 2) The other problem is in LGOUT%. It clears out the address space of the top fork and then does a bunch of terminal IO to print the 'Killed usage mumble mumble' message. Most of the SOUT%'s, NOUT%'s and the final DOBE% for this IO don't have ERJMP's after them. So if you have a job on a NVT or PTY with an almost full output buffer, it will hang waiting at the DOBE% or a earler. Now if a carrier-off psi comes in due to the other end being closed, the DOBE% (or SOUT%) will generate an illegal instruction and try to go back to the user who, at this time doesn't have pages in his top fork anymore.... If after the DOBE% just before LOG2 (in MEXEC) you put a ERJMP LOG2 it helps alot as that is where the problem usualy happens. The printing of the 'Killed used mumble mumble' is spread all over the place and isn't so easy to fix. Aaron Wohl WOHL@CMU-20C ------- 2-Jun-81 23:05:17-EDT,1762;000000000000 Mail from SU-SCORE rcvd at 2-Jun-81 2305-EDT Mail-from: ARPANET site BBNG rcvd at 2-Jun-81 1441-PDT Date: 2 Jun 1981 1741-EDT From: Dan Tappan Subject: Ultra-Cheap DN20 To: Admin.MRC at SU-SCORE Remailed-date: 2 Jun 1981 1944-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.96: ; Mark, forward as you see fit. It is possible, if one is willing to do some extra software work, to do the Erector Set DN20 one better, and build an ultra-cheap front end for a KL. For host interfaces on our local network we've done this by using an LSI11 as the front end, and the result is surprisingly usable. The cost is approximately 1/2 - 2/3 that of even the cheapest DN20. LSI11/03, CPU, Backplane, memory,DLV11J ~5K (11/23 ~7K) Plessy QBUS->Unibus converter ~.5K DTE ~2.5K Total 8-10K (Plus, of course, the cost of whatever devices you put on the thing). In our case this is acting as a simple Internet gateway. I've done some throughput measurements, with as little KL participation as possible. With an 11/03 throughput ranges from 47KB (40 byte packets) to 155KB (512 byte packets). With an 11/23 that goes from 77KB (40 bytes) to 164KB (512 bytes). If the KL is required to do any processing then throughput drops precipitously (not surprisingly, since this was done on a memory bound 256K machine), so these speeds are easily sufficient to swamp it. All in all, if the application is such that the '11 isn't required to do a lot of work, then it isn't really necessary to go all the way to an 11/34 (it seems to me that this throughput would be easily enough to drive several LPT's or what-have-you). Dan ------- 3-Jun-81 18:23:59-EDT,1100;000000000000 Mail from SU-SCORE rcvd at 3-Jun-81 1823-EDT Mail-from: ARPANET site DEC-2136 rcvd at 3-Jun-81 1453-PDT Date: 3 Jun 1981 1753-EDT From: PAETZOLD at DEC-2136 To: admin.mrc at SU-SCORE Subject: DEC-2136 Release 5 ARPANET Test System Message-ID: Remailed-date: 3 Jun 1981 1518-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.96: ; Mark: Please forward this to the TOPS-20 list and any other lists that seem appropiate. We have built a test system for TOPS-20AN release five. This system will be running on arpanet host DEC-2136. We encourage all people involved with TOPS-20AN to login and help us test out the release 5 arpanet software. The guest account at DEC-2136 is "G" and the password is "G". The guest account has the ability to create subdirectories for personal use. We will try to have this system up for several hours a day starting at 5PM EDT. For other policy matters see the file [DEC-2136]POLICY.HLP. Kevin Paetzold -------- 5-Jun-81 03:44:28-EDT,1408;000000000000 Mail from SU-SCORE rcvd at 5-Jun-81 0344-EDT Date: 4 Jun 1981 2325-PDT From: Mark Crispin Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022 Stanford-Phone: (415) 497-1407 Subject: new MM/FINGER interaction To: [SU-SCORE]TOPS-20.DIS.96: ;, Admin.MDP at SU-SCORE, MMcM at MIT-AI I wish to enhance MM to obtain the personal name from the FINGER database if it was not supplied by the user in the PERSONAL-NAME field of her MM.INIT file. Since there are at least three implementations of FINGER for TOPS-20 (Cerberus in its many dialects, SCORE FINGER, and LOTS FINGER), I felt it advisable not to try to make MM read the database itself. I would therefore like to define a new entry point to FINGER. Entry vector offset 4 (right after the version) is defined to be the personal name server. MM will ignore a FINGER which doesn't have this entry point. If supplied, MM will pass FINGER the user name in the rescan buffer, and then will start FINGER at that point. When FINGER returns, it should leave the personal name in the rescan buffer. If the lookup fails for any reason FINGER should clear the rescan buffer. This change will not happen in MM immediately, but we'd like to do it here pretty soon; we have other applications which would like to use this functionality in FINGER. -- Mark -- ------- 5-Jun-81 04:17:46-EDT,3145;000000000000 Mail from SU-SCORE rcvd at 5-Jun-81 0417-EDT Mail-from: ARPANET site RUTGERS rcvd at 5-Jun-81 0107-PDT Date: 5 Jun 1981 0408-EDT From: HEDRICK at RUTGERS Subject: fun and games with FOO.DIRECTORY.2 To: admin.mrc at SU-SCORE cc: remarks at RUTGERS Remailed-date: 5 Jun 1981 0112-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.96: ; One of my staff decided to create a file FOO.DIRECTORY.2 on his directory. He already had a FOO.DIRECTORY.1, which was a real directory. .2 was a normal file. Suddenly CHECKD started failing mysteriously if you answered Run CHECKD? with Y in the startup dialog. By failing I mean that it didn't print the usual message about the number of pages before and after CHECKD. No error messages either. The system just went ahead and loaded. It turns out that this case has turned up 3 separate bugs: - CHECKD finds all the directories by doing a wild-card RCDIR. Given a directory number it does DIRST to get the directory name, and then manufactures the file name, e.g. BAR.DIRECTORY. It then does a GTJFN on this filename. The monitor has somewhat similar code for looking up directory files. However when they get around to the GTJFN, the monitor specifies version one in the right half of the flag word. CHECKD neglects this. Thus in the case mentioned above, CHECKD gets version 2 of the file. This causes two ill effects: (1) it fails to read the directory file, thus in principle causing all pages in it to be garbage-collected; (2) it reads a file that is not a directory, causing it to blow up. - CHECKD is not sufficiently paranoid about the format of directory files. If page 0 is missing, it gets an ill mem read trying to look at it, and blows up. - The monitor does not bother to see how CHECKD terminates. If CHECKD blows up, e.g. with an ill mem read, the monitor happily proceeds on its way, without even printing an error message. I have not looked at the code, but conjecture that it is the usual CFORK; GET; START; WFORK; proceed on merry way. The first two bugs are fixed in the following FILCOM. I have not fixed the monitor problem. I regard this as a fairly important fix, since users could corrupt the disk system by creating .DIRECTORY files, causing pages from active subdirectories to be returned to the free list. File 1) DSK:CHECKD.MAC[4,211] created: 0252 05-Jun-1981 File 2) DSK:CHECKD.DEC[4,211] created: 1524 03-Jan-1980 ************** 1)62 GTFIL3: MOVX T1,GJ%PHY!GJ%SHT!1 ;[2] PHYSICAL ONLY, SHORT BLOCK 1) GTJFN ;GET A JFN **** 2)62 GTFIL3: MOVX T1,GJ%PHY!GJ%SHT ;PHYSICAL ONLY, SHORT BLOCK 2) GTJFN ;GET A JFN ************** 1)85 DR0CHK: MOVE T4,DIRORA ;GET BASE ADR OF MAPPED DIR AREA 1) LOAD T2,DRNUM,(T4) ;GET DIR NUMBER 1) ERJMP DR0CHB ;[2] error if page missing 1) CAME T1,T2 ;DO THE DIRECTORY NUMBERS MATCH? **** 2)85 DR0CHK: MOVE T4,DIRORA ;GET BASE ADR OF MAPPED DIR AREA 2) LOAD T2,DRNUM,(T4) ;GET DIR NUMBER 2) CAME T1,T2 ;DO THE DIRECTORY NUMBERS MATCH? ************** ------- 5-Jun-81 15:36:42-EDT,1098;000000000000 Mail from SU-SCORE rcvd at 5-Jun-81 1536-EDT Mail-from: ARPANET site MIT-XX rcvd at 5-Jun-81 1213-PDT Date: 5 Jun 1981 1217-EDT From: Ted Markowitz Reply-To: g.tjm@score Subject: Lost MTA's To: admin.mrc at SU-SCORE Remailed-date: 5 Jun 1981 1228-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.96: ; Has anyone had the experience of losing control of a tape drive in the following situation? 1) Tapes are not allocated to the system, but can be assigned directly by the users. 2) A drive is controlled by Job 0 somehow, but not allocated to MOUNTR. 3) Turning the controller off and on (usually a brutal but effective way of getting the Monitor to notice the device) has no effect at all. I haven't been able to figure out how Job 0 has a hold on this device. Killing and restarting MOUNTR (even reloading SYSJOB entirely) has no effect. The drive has now become totally unusable. SYSDPY reports that no one has a handle on the device at all. Thanks for any help. --ted ------- 6-Jun-81 13:37:37-EDT,604;000000000000 Mail from SU-SCORE rcvd at 6-Jun-81 1337-EDT Mail-from: ARPANET site RUTGERS rcvd at 5-Jun-81 1513-PDT Date: 5 Jun 1981 1803-EDT From: HEDRICK at RUTGERS Subject: Re: Lost MTA's To: g.tjm at SU-SCORE cc: admin.mrc at SU-SCORE In-Reply-To: Your message of 5-Jun-81 1217-EDT Remailed-date: 6 Jun 1981 1029-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.96: ; Yes, this happens all the time. To fix it, write a short program that does the deassign JSYS on the tape drive. Save it as an .EXE file, and run it with ^E SPEAK. ------- 8-Jun-81 12:22:41-EDT,910;000000000000 Mail from SU-SCORE rcvd at 8-Jun-81 1222-EDT Date: 8 Jun 1981 0919-PDT From: Mark Crispin Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022 Stanford-Phone: (415) 497-1407 Subject: [Ted Markowitz : TTY "remoteness"] To: [SU-SCORE]TOPS-20.DIS.97: ; DEC says that it would be very hard to implement, and also has expressed surprise that anybody would want to do this. -- MRC --------------- Date: 8 Jun 1981 0846-PDT From: Ted Markowitz Subject: TTY "remoteness" To: admin.mrc Has anyone ever noticed that you can't "unremote" a line that's been set that way at boot time? There doesn't seem to be a JSYS function that can make it happen. Runnning SETSPD doesn't do the trick as you'd expect. Perhaps a MONITOR poker has some lore on the subject? --ted ------- --------------- ------- 12-Jun-81 17:45:08-EDT,1826;000000000000 Mail from SU-SCORE rcvd at 12-Jun-81 1745-EDT Mail-from: ARPANET site USC-ECLB-IPI rcvd at 10-Jun-81 1103-PDT Mail from USC-ECLB-IPI rcvd at 10-Jun-81 1007-PDT Date: 10 Jun 1981 0839-PDT From: BALLENTINE at USC-ECLB-IPI Subject: Extended addressing hardware bug To: mark at ECLB cc: belmont Remailed-date: 10 Jun 1981 1103-PDT Remailed-from: Mark Thompson Remailed-to: Admin.MRC at SU-SCORE Remailed-date: 11 Jun 1981 2022-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.97: ; An interesting microcode bug we've found that you may want to pass on to DEC. It's a combination of MOVSLJ and extended addressing (I'm sure you love to hear about these!). It appears that MOVSLJ doesn't respect the local byte pointer convention if running in other than section 1. If a byte pointer is not global, it uses section 0 regardless of the section it's running in. The example I found that doesn't work: AC7 has a global address. I want to move from that address to a local address within my section (I'm running in section 1) movei 1,10 ; size of source move 2,[point 36,(7)] ; source bp movei 4,10 ; destination size move 5,[point 7,fname] ; destination bp extend 1,[movslj 0 ] : : fname: block .. This picks up the correct information, but moves it to 0,,fname (rather that 1,,fname). The local bp [point 7,fname] should use the current section. We got around this problem by using a global bp there. I wish I had more time to test this a bit further, but the project I'm on (DARPA Ada) is keeping us all too busy. Call if you'd like. Mike Ballentine Intermetrics, Inc. (617) 661-1840 x2386 3 hours behind you in Massachusetts ------- 13-Jun-81 05:53:27-EDT,1595;000000000000 Mail from SU-SCORE rcvd at 13-Jun-81 0553-EDT Mail-from: ARPANET site RUTGERS rcvd at 12-Jun-81 1710-PDT Date: 12 Jun 1981 2000-EDT From: HEDRICK at RUTGERS Subject: FLKTIM/FLKNS problem due to extended addressing To: admin.mrc at SU-SCORE Remailed-date: 12 Jun 1981 2208-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.97: ; Problem: If you are using extended addressing, ^C out of the program, and do anything that would trigger a KFORK on the program, then do something else that would try to get a fork lock, your job will be hung until you get FLOCK time out. For example, ^C'ing and running another program triggers this, since running another program KFORK's the old and does a GET into a new fork. Diagnosis: Coding error in FLOCK causes an AC to be garbaged. Cure: FLOCK:: REPEAT 0,< ;NOT CHECKED NOW BECAUSE MLKBLK PROBLEM SKIPN FORKN ;TOP FORK? JRST FLOCK1 ;YES, INTERRUPTIBILITY NOT SIGNIFICANT SKIPL INTDF ;INTERRUPTABLE NOW? BUG(FLKINT) > ACVAR ;[163] SETZM W2 ;[163] INDICATE NESTING NOT ALLOWED JRST FLOCK1 ;HERE TO ALLOW NESTING OF THE LOCK FLOCKN::ACVAR ;[163] SETOM W2 ;[163] INDICATE NESTING ALLOWED FLOCK1: CSKED ;BE CRITICAL IF LOCK WORKS AOSN FKLOCK ;LOCK SUCCESSFUL? ;THE LOCK WAS PREVIOUSLY UNLOCKED. SAVE THIS FORK INDEX AND INCREMENT ;THE NEST COUNT JRST [ HRR W2,FORKN ;[163] GET OUR JOB-WIDE FORK HANDLE MOVEM W2,FLKOWN ;[163] SAVE IT AS THE OWNER SKIPE FLKCNT ;IF NOT ZERO, SOMETHING IS WRONG ------- 17-Jun-81 00:02:33-EDT,689;000000000000 Mail from SU-SCORE rcvd at 17-Jun-81 0002-EDT Mail-from: ARPANET site BBNG rcvd at 16-Jun-81 1900-PDT Date: 16 Jun 1981 2200-EDT From: Dan Tappan Subject: Update on Cheap DN20 (for list) To: Admin.MRC at SU-SCORE Remailed-date: 16 Jun 1981 2059-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.99: ; As it turns out, the real limiting factor on throughput through a DN20 is the DTE. By going to 16 bit transfers over the DTE (I had originaly used 8 to make things easier for the '11) I can get throughput through my cheap DN20's on the order of 250KB for an 11/03 or 350KB for an 11/23. Dan ------- 17-Jun-81 13:02:26-EDT,1162;000000000000 Mail from SU-SCORE rcvd at 17-Jun-81 1302-EDT Mail-from: ARPANET site UTEXAS-20 rcvd at 17-Jun-81 0141-PDT Date: 17 Jun 1981 0341-CDT From: Clive Dawson Subject: Net lossage To: admin.mrc at SU-SCORE Remailed-date: 17 Jun 1981 0954-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.99: ; Mark, please distribute to the wizards if appropriate (i.e. if you don't have an answer). For the second time in about 10 days we have experienced a problem in which IMPABF BUGINF's start pouring out of the CTY at the rate of one every couple of seconds. In both cases, the problem occured late at night, and a few thousand came out before the problem was discovered. All jobs doing anything with the net simply hang, and cannot be stopped or logged out. In each case I tried to flush relevant hosts, etc, but only succeeded in hanging my own job running TELNET. After trying various other things, I finally gave up, took a crash dump and reloaded. Everything came up fine. Has anybody seen this before, and diagnosed it perchance? Many thanks, Clive ------- 17-Jun-81 13:44:18-EDT,1645;000000000000 Mail from SU-SCORE rcvd at 17-Jun-81 1344-EDT Mail-from: ARPANET site SUMEX-AIM rcvd at 17-Jun-81 1032-PDT Date: 17 Jun 1981 1030-PDT From: Sweer at SUMEX-AIM Subject: Re: Net lossage To: CC.Clive at UTEXAS-20 cc: Admin.MRC at SU-SCORE, Sweer at SUMEX-AIM Remailed-date: 17 Jun 1981 1037-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.99: ; In response to your message sent 17 Jun 1981 1004-PDT It appears to me that the IMPABF bug messages in TOPS20 are a direct decendant of the ASNTBF Failure bug messages that have plagued Tenex over the years. I'm not sure exactly how TOPS20 handles this but I can offer some lore from Tenex. The problem starts because ASNTBF can't find a buffer for output, perhaps because they are all used up for input messages. Tenex has tried 2 approaches to this. First you can define a low water mark of a number of buffers below which no more buffers will be assigned for input. This requires isolating the calls to ASNTBF for input and output. Secondly, if it is not already there, you should put a check to see if the running fork owns NCPLCK, and if so allow it to assign the buffer anyway, assuming there are any. It is also possible that ASNTBF fails because the buffer linkage is screwed up somehow. If this is the case you're in deep yogurt. No ammount of MDDT'ing has ever allowed us to successfully back out of this condition. If you try to relink the buffers on a live system you inevitably run into another more serious BUGHLT due to the fact that some fork still thinks it owns a given buffer. Andy ------- 17-Jun-81 16:11:55-EDT,2107;000000000000 Mail from SU-SCORE rcvd at 17-Jun-81 1611-EDT Mail-from: ARPANET site SRI-KL rcvd at 17-Jun-81 1123-PDT Date: 17 Jun 1981 1109-PDT From: LARSON at SRI-KL Subject: re: Net lossage To: CC.Clive at UTEXAS-20, Admin.MRC at SU-SCORE Remailed-date: 17 Jun 1981 1304-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.99: ; Yes, I have seen it before. It is caused by the ASNTBF (assign net buffer) routine failing. This routine prints the buginf, then DISMS's for 5 seconds, then tries again (forever). Sadly, it is entered with one of the network locks set, and nobody can get in to release any of the used buffers, so you generally remain hung (again, forever). You can recover without crashing the system most of the time, with a little magic in MDDT. Here is how. 1. Turn the net off. Either with the ^Eset command, or by setting the monitor location NETON to 0. 2. Examine the cells (in octal) starting at NETFRE. NETFRE+2 will be the number of free words of net buffer space. The others are good to learn about (but not essential here). 3. Set the content of ASNTHR to 1/2 it's present value, but not below 2000. (If it is already below 4000, you are configured very wrong.) Note: ASNTHR is normally the first word after the NETFRE array (NETFRE+5). 4. Look at NETFRE+2 again, as soon as it starts to rise again, reset ASNTHR. Do not leave the changed value in ASNTHR, the extra buffer space gained will not prevent the problem happening again. If you do not reset ASNTHR, when you have the same problem happen again, you will not have enough free buffer space reserved to unwedge yourself. 5. When all seems to be normal again, turn the net back on. I have not discovered why the net seems to run out of net buffers so often. Increasing the size of the buffer area helped a little, but did not really fix the problem. I suspect that something is going wild and grabbing them up, but have not proved it yet. Alan Larson ------- 17-Jun-81 16:20:52-EDT,1856;000000000000 Mail from SU-SCORE rcvd at 17-Jun-81 1620-EDT Mail-from: ARPANET site BBNG rcvd at 17-Jun-81 1136-PDT Date: 17 Jun 1981 1433-EDT From: Dan Tappan Subject: Re: Net lossage To: Sweer at SUMEX-AIM cc: CC.Clive at UTEXAS-20, Admin.MRC at SU-SCORE, Tappan at BBNG In-Reply-To: Your message of 17-Jun-81 1330-EDT Remailed-date: 17 Jun 1981 1308-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.99: ; Both approaches help somewhat, (except that you DON'T want to limit input buffers, that'll make things worse, the problem is that the IMP has been holding you off for some reason, so there are a lot of output buffers queued, stopping input will just stop your RFNMs from coming in and the problem will get worse, you want to limit OUTPUT). A major problem is that when the NCP fork processes an input buffer, it is likely to go ahead and immediately send out a reply, which causes it to hit the 0 buffer condition, hang up waiting for a buffer, and make the problem worse since there is then nothing cleaning things up. Unfortunately there isn't any way to prevent this without totaly re-writing the code. The best way I've found to prevent the problem is simply to double the number of buffers. On another note, Another reason I've seen for this sort of thing is that the NCP fork got hung for some other reason. Occasionally I've seen the NCP fork hung up on either a dynamic data lock or a SNDALL lock while trying to close down an NVT. To find out if thats the problem look in NCPFRK for the fork number, then at FKSTAT+N. if the test is a DISMS (BLOCKW) then its probably in the buffer deadlock, is its something else (like TSACT3) you may be able to fix things just by clearing what it's waiting for and letting it do it's thing. Dan ------- 17-Jun-81 16:28:43-EDT,1510;000000000000 Mail from SU-SCORE rcvd at 17-Jun-81 1628-EDT Mail-from: ARPANET site SRI-KL rcvd at 17-Jun-81 1124-PDT Date: 17 Jun 1981 1121-PDT From: Harris A. Meyers Subject: Re: Net lossage To: CC.Clive at UTEXAS-20, admin.mrc at SU-SCORE In-Reply-To: Your message of 17-Jun-81 0141-PDT Remailed-date: 17 Jun 1981 1315-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.99: ; Andy's analsis is correct, by the way his check on NCPLCK is not in TOP-20, but here is some more lore that may be useful. 1) Turn the net off - this avoids hanging more jobs & is nessary for the one possible fix i know of. 2) Wait for the net to come all the way down. 3) Get into MDDT and check the following values: a) NETFRE + 2 - the number of free buffers. b) ASNTBF (=NETFRE + 5) - the limit below which not to allocate new buffers. 4) If NETFRE + 2 <= ASNTBF then continue , else giveup your buffers are munged. 5) Reduce the value of ASNTBF (try cutting it in half) this will allow the hung processes to get buffers then fail because the net is off. 6) Wait a min. or so for the hung jobs to free up. 7) Restore ASNTBF to its original value. 8) Turn the net back on. 9) If this is happening offen, consider building a new moitor with a larger value of NNTBFS (the number of net buffers, defined if STG). We are currently using NNTBFS =100000, and it seems to work well. good luck harris ------- 18-Jun-81 19:19:26-EDT,2166;000000000000 Mail from SU-SCORE rcvd at 18-Jun-81 1919-EDT Mail-from: ARPANET site DEC-MARLBORO rcvd at 10-Jun-81 1458-PDT Date: 10 Jun 1981 1756-EDT From: HALL at DEC-MARLBORO To: admin.mrc at SU-SCORE cc: hall at DEC-MARLBORO Subject: Hung jobs Message-ID: Remailed-date: 18 Jun 1981 1612-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.101: ; You sent some mail a while ago about jobs that get hung trying to logout. At the time, I hadn't experienced that, but today we had one. I had to leave before I could finish investigating, but I did get some interesting data. While I realize that you're looking for a way out once the condition has happened -- and I think it would be nice to generate that -- right now I'd like to know the cause of the problem. Have you seen this kind of data? The stack pointer pointed to the top of UPDL (UPDL+3 or so), but on the stack was some interesting data. There was a DESX2, which means something like "Terminal not available to this job". There was also a terminal number. If you looked at JOBPT of this job, its terminal was in fact the one on the stack. Unfortunately, if you looked at DEVUNT for that terminal, another job owned it. And if you looked at JOBPT for that job, it pointed to the terminal. Thus one job and a terminal agreed that they belonged to each other, but the hung job also thought that it belonged to that terminal (or vice versa). Seems like the classic triangle, almost. Alas, computers have no heart. I haven't gone bug-hunting yet, but I'm wondering if something like this is happening: Job is in logout Job deassigns the terminal, thus making TTACTL be -1 Job dismisses for some reason, not necessarily a bug User pounds on CTRL/C and gets a new job Old job has the controlling terminal lying around and does a JSYS on it (like DOBE) even though it already deassigned it Old job gets error I didn't have time to see why it loops, however. Have you figured that out? Maybe it's trying to type an error message to the terminal! -------- 18-Jun-81 23:19:20-EDT,636;000000000000 Mail from SU-SCORE rcvd at 18-Jun-81 2319-EDT Mail-from: ARPANET site SRI-KL rcvd at 18-Jun-81 1922-PDT Date: 18 Jun 1981 1922-PDT From: ROODE at SRI-KL (David Roode) Subject: for dist. list To: Admin.MRC at SU-SCORE Remailed-date: 18 Jun 1981 1932-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.101: ; How come, when stepping through the files of a directory with GNJFN, if I alter the account of some file, further files which have that account are skipped by that series of GNJFN's? Shouldn't this be considered a bug? --------------- ------- 19-Jun-81 18:56:09-EDT,1044;000000000000 Mail from SU-SCORE rcvd at 19-Jun-81 1856-EDT Mail-from: ARPANET site SRI-KL rcvd at 19-Jun-81 0247-PDT Date: 19 Jun 1981 0244-PDT From: ROODE at SRI-KL (David Roode) Subject: more on wildcarding To: Admin.MRC at SU-SCORE Remailed-date: 19 Jun 1981 1545-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.102: ; The exact situation seems to be that if I am stepping through a file group, and I use the JFN to change the account of one of the files, the wildcard specification is modified to specify the particular account to which I changed the file, so that only files on that account appear. The problem comes up in the case of a program designed to verify files' accounts and correct invalid accounts as needed, since we use the account of the file for disk usage billing. As soon as one correction is made, this bug masks any further files needing correction. One might have expected DEC to provide a utility to handle this aspect of account validation. ------- 19-Jun-81 19:04:07-EDT,1676;000000000000 Mail from SU-SCORE rcvd at 19-Jun-81 1904-EDT Mail-from: ARPANET site SRI-KL rcvd at 19-Jun-81 1304-PDT Date: 19 Jun 1981 0858-PDT From: Harris A. Meyers Subject: Re: for dist. list To: ROODE at SRI-KL, Admin.MRC at SU-SCORE In-Reply-To: Your message of 18-Jun-81 1922-PDT Remailed-date: 19 Jun 1981 1551-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.102: ; I agree with Dave that this "feature" is probably a bug & at one point was considering "fixing" it, but when i saw that DEC appeared to have gone out of their way to get it, I began to wonder it someone might be depending on it and worked around it rather than fixing it. Here is a coy of the message I sent to the list about it before. harris ------------------------------------------------------------------------------- 27-Jun-80 21:02:56-PDT,741;000000000001 Mail-from: ARPAnet host SU-SCORE rcvd at 27-Jun-80 2102-PDT Date: 27 Jun 1980 2059-PDT From: g.Meyers at SU-SCORE (Harris A. Meyers) Reply-to: Meyers@SRI-KL Subject: Question about SACTF To: [SU-SCORE]Tops-20.DIS.46: In JSYSF at SACTF1+3 and SACTF4+4 plus other related code scattered throughout .SACTF great care is taken to store the new account in the JFN data base in the JSB (FILACT(JFN)). Can anyone tell me of what use this code is? It has the following bad side effect: any GNJFN done on the JFN used by the SACTF will only find files with the new account from then on. I consider this a bug and am considering removeing the code, but was wondering if doing so will break something harris ------- ------- 20-Jun-81 00:19:04-EDT,728;000000000000 Mail from SU-SCORE rcvd at 20-Jun-81 0019-EDT Date: 19 Jun 1981 2113-PDT From: Mark Crispin Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022 Stanford-Phone: (415) 497-1407 Subject: KL UCODE bugs To: [SU-SCORE]TOPS-20.DIS.102: ; DEC is working on the KL microcode. The project is a short one, but there is some opportunity to get bugs fixed and I am trying to get together a "short list" of critical UCODE bugs to pass to DEC. The UCODE bugs that have gone out on TOPS-20.DIS have apparently already been passed to the UCODE developers. Please keep the bug reports short and concise. If the demand seems excessive, we may not get anything done. ------- 26-Jun-81 00:22:54-EDT,1877;000000000000 Mail from SU-SCORE rcvd at 26-Jun-81 0022-EDT Mail-from: ARPANET site UTEXAS-20 rcvd at 25-Jun-81 1554-PDT Date: 25 Jun 1981 1753-CDT From: Clive Dawson Subject: Swapping space To: admin.mrc at SU-SCORE cc: cc.clive at UTEXAS-20 Remailed-date: 25 Jun 1981 2116-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.103: ; To the Twenex-Wizards: Our system is running low on swapping space. The DDMP: SWAPPING SPACE LOW ACTION message is appearing on the CTY every minute or so during the busy times of the day. We currently have 10,070 pages of swapping space allocated, and I don't know where it's all going. I have a few questions: 1. Has anybody come up with any good utilities which can give you an idea of how your swapping space is being used? Right now I use SYSDPY which gives me the size of everybody's forks, but it's hard to figure out how much space is shared due to mapped files, etc. 2. I imagine we'll eventually have to reconfigure our PS: and add more swapping space, but I'm trying to hold off for another month until some new disk drives arrive. In the meantime, does anybody have any hints on how to alleviate the situation? In particular, the threshold for firing up DDMP is 4000 (octal) free pages. Since DDMP seems to contribute significantly to the system load when it runs, I'm considering reducing the threshold to 3000 or even 2000. Does anybody know the effects of this? 3. What is the relation between the programs listed under the "Info subsystem-statistics" and those that are resident on the swapper? Are all of those really out there, or does the monitor keep track of them even if they're not using swapping space. Many thanks for any help.. Clive ------- 26-Jun-81 20:31:28-EDT,1470;000000000000 Mail from SU-SCORE rcvd at 26-Jun-81 2031-EDT Mail-from: ARPANET site MIT-XX rcvd at 26-Jun-81 1639-PDT Date: 26 Jun 1981 1942-EDT From: Nat Mishkin Subject: Re: Swapping space To: CC.Clive at UTEXAS-20 cc: admin.mrc at SU-SCORE In-Reply-To: Your message of 25-Jun-81 1853-EDT Remailed-date: 26 Jun 1981 1728-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.103: ; Two points: first, as to finding where all the swap space is, I have hacked SYSDPY so that the "mapped pages" column in the fork display shows the NUMBER of private pages for each fork as opposed to just the existence of private pages. Normal SYSDPY just shows a "P" in this column and this gives you no idea as to the number of private pages. I have actually tracked down "private page hogs" using this information. It'd tedious but better than nothing. Second point: I got burned by the fact that when you build a structure from scratch you can override the default swapping space but the max the default monitor can handle is the default swapping space (~10000). I.e. you can make the swap space be, say, 12000 pages but the default monitor is configured to handle only 10000. You can rebuild the monitor with the appropriate parameter increased. Now I maybe I should have known better but I don't recall seeing anything in DEC's documentation describing this "feature" -- Nat Mishkin ------- 26-Jun-81 20:35:50-EDT,1324;000000000000 Mail from SU-SCORE rcvd at 26-Jun-81 2035-EDT Mail-from: ARPANET site SRI-KL rcvd at 26-Jun-81 0920-PDT Date: 26 Jun 1981 0922-PDT From: Harris A. Meyers Subject: Re: Swapping space To: CC.Clive at UTEXAS-20, admin.mrc at SU-SCORE In-Reply-To: Your message of 25-Jun-81 1553-PDT Remailed-date: 26 Jun 1981 1720-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.103: ; We have found that for fairly large systems the DEC caculations for DRMIN0 (when to run DDMP) and DRMLV0 (when to disallow new private pages) in PAGEM are way too conservative. The following works well for us. harris ------------------------------------------------------------------------------- from dec SETSSP::MOVE B,TOTRC ;PREVENT NEW PRIVATE PAGES CAIL B,^D1024 ;A VERY LARGE SYSTEM? MOVEI B,^D1024 ;YES. USE CUTOFF THEN MOVEM B,DRMLV0 ;WHEN FREE DRUM EQUALS TOTAL CORE IMULI B,2 ;DOUBLE THAT LEVEL MOVEM B,DRMIN0 ;TO CAUSE DDMP ACTIVITY RET ------------------------------------------------------------------------------- from sri monitor SETSSP::MOVE B,TOTRC ;5 MOVEM B,DRMIN0 ;5 TO CAUSE DDMP ACTIVITY ASH B,-1 ;5 PREVENT NEW PRIVATE PAGES MOVEM B,DRMLV0 ;5 WHEN FREE DRUM EQUALS 1/2 TOTAL CORE RET ------- 30-Jun-81 02:21:14-EDT,1272;000000000000 Mail from SU-SCORE rcvd at 30-Jun-81 0221-EDT Mail-from: ARPANET site RUTGERS rcvd at 27-Jun-81 1953-PDT Date: 27 Jun 1981 2252-EDT From: Jonathan Alan Solomon Subject: Bug in the DEC Exec for release 4. To: Admin.MRC at SU-SCORE Remailed-date: 29 Jun 1981 2318-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.103: ; Problem: If have a fork that requires SC%CTC, and you ENABLE and DISABLE above it in the exec, the SC%CTC goes away (and so does SC%GTB, SC%MMN, SC%LOG, SC%MPP, SC%SDV, and SC%SCT). Diagnosis: The code looks like this: DISAB1+13 (in the vanilla unmodified EXEC) RPCAP% ;get capabilities TDZ C,[777B8+777777] ;make them disabled SKIPE PRVENF ;unless were enabling MOVE C,B ;then we should enable them EPCAP Apparently DEC goes out of its way to make this happen, but it breaks all kinds of programs (try pushing out of your kept emacs after doing that), but is not too apparent from the Vanilla Non-multiforking EXEC (but it CAN be reproduced in that EXEC). Solution: Replace the TDZ at DISAB1+14 with a HLLZ C,C would do the trick for disabling the user caps while leaving the job capabilities as they were. Jon ------- 1-Jul-81 04:12:47-EDT,2228;000000000000 Mail from SU-SCORE rcvd at 1-Jul-81 0412-EDT Date: 1 Jul 1981 0108-PDT From: Mark Crispin Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022 Stanford-Phone: (415) 497-1407 Subject: An interesting SPR and answer To: [SU-SCORE]TOPS-20.DIS.104: ; Last April 1, A. N. Onymous sent an SPR to DEC as follows: PROBLEM: No way to input or output Roman numerals. DIAGNOSIS: The NIN% and NOUT% jsi have no code to check for or support SIXBIT/ROMAN/ in AC3. SOLUTION: Allow SIXBIT/ROMAN/ in AC3, and add code to do Roman numeral I/O when this is specified as the base. This is obviously useless in many applications. DEC's reply was: NIN, FOREIGN LANGUAGES, SMOKE, FIRE AND NOVAS SUGGESTION Thank you for your SPR on the NIN JSYS in TOPS-XX version IV. We have decided to implement Roman numeral support in the same release that we change the power line clock to a sundial with a laser measuring the sun's shadow. Both of these issues have had the same priority since the first release of TOPS-20. Similar issues of the same priority are support in the COMND JSYS for foreign languages (ie. new flags specifiying the (sic) language in which the field should be input, CM%GER, CM%FRE, and CM%SPA for German, French and Spanish respectively). This will allow the user to supply a keyword table in English but set the appropriate bit and have the MONITOR do its own translation. This release will also add support for two new devices (called SMOKE: and FIRE:). Whenever a BUGCHK is executed, the SMOKE: device will be activated. Whenever a BUGHLT is executed, the FIRE: device will be activated. We feel that this will allow the DEC-20 to come closer to meeting the image that the public has about computers. As you can see, there are many really exciting features awaiting the TOPS-20 customer base. Unfortunetly, the (sic) project plan for this release calls for this to be released only after the sun novas. We hope you can wait until then. [End of answer to SPR #:20-16152 ] Who says DEC doesn't have a sense of humor?? ------- 8-Jul-81 02:16:26-EDT,951;000000000000 Mail from SU-SCORE rcvd at 8-Jul-81 0216-EDT Mail-from: ARPANET site MIT-XX rcvd at 7-Jul-81 1733-PDT Date: 7 Jul 1981 2035-EDT From: Nat Mishkin Subject: Swap space low... To: admin.mrc at SU-SCORE Remailed-date: 7 Jul 1981 2312-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.104: ; For circulation among TOPS-20 hackers: Can someone explain what goes on in the DDMP routine which gets called by fork 0 every minute or when swap space is low? How is it freeing up swap space? Also, why are there two messages on swap space low: DDMP: SWAP SPACE LOW ACTION and [Caution -- swapping space low...] The latter message appears to have been intended to be printed on all terminals (but the code has been commented out so it only comes out on the CTY). Sometimes you get both messages, sometime you only get the first. -- Nat Mishkin ------- 8-Jul-81 15:55:30-EDT,748;000000000000 Mail from SU-SCORE rcvd at 8-Jul-81 1555-EDT Mail-from: ARPANET site UTEXAS-20 rcvd at 8-Jul-81 1224-PDT Date: 8 Jul 1981 1425-CDT From: Edward C. Pattermann Subject: MOUNTR.CMD To: admin.mrc at SU-SCORE Remailed-date: 8 Jul 1981 1245-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.104: ; Mark, Would you forward this to your mailing list if appropriate ; Does anyone know what the format of the file SYSTEM:MOUNTR.CMD is supposed to be? It is read at the time of a mount request, to set structures domestic or unregulated etc., but I can't get any reasonable format to work! Any help is greatly appreciated, -- Ed ------- 8-Jul-81 20:09:41-EDT,1745;000000000000 Mail from SU-SCORE rcvd at 8-Jul-81 2009-EDT Mail-from: ARPANET site RADC-TOPS20 rcvd at 8-Jul-81 0710-PDT Date: 8 Jul 1981 1008-EDT From: Kevin Paetzold To: NWM at MIT-XX, admin.mrc at SU-SCORE Reply-to: Paetzold at RADC-TOPS20 Telephone: 617-467-7430 Subject: Re: Swap space low... Message-ID: In-reply-to: Message from Nat Mishkin of 7-Jul-81 2035-EDT Remailed-date: 8 Jul 1981 1701-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.104: ; When DDMP does its SWAP SPACE LOW thing it is because CHKR has called DDMP0. DDMP0 has noticed that free swapping space (DRMFRE) is below DRMIN0. DDMP moves (updates) modified file pages in swapping space back to regular disk areas. If swap space is NOT low it only updates pages to files which are in thaw mode. If swap space is low then DDMP will move (update) pages to any file which is not suppressing DDMP. The DDMP SWAP SPACE LOW action is very expensive as it causes a great amount of disk activity and yet more job zero runtime. After CHKR has got DDMP to do its thing it continues along it merry way. Eventually its calls CHKDMS which checks drum space. If CHKDMS notices that space is still low it types the "*****Swapping space low" message on the cty. (remember space is still low after ddmp swap space low action...things are not in good shape). CHKDMS also sends a message to everyone saying the space is low. If you are not seeing the message on your tty then something is amiss. Perhaps your system still suffers from the TTMSG to ARPANET NVT's doesn't work bug. -------- 9-Jul-81 14:25:39-EDT,608;000000000000 Mail from SU-SCORE rcvd at 9-Jul-81 1425-EDT Date: 9 Jul 1981 1038-PDT From: Ted Markowitz Subject: Re: MOUNTR.CMD To: G.ECP at UTEXAS-20, admin.mrc In-Reply-To: Your message of 8-Jul-81 1225-PDT Remailed-date: 9 Jul 1981 1112-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.104: ; The information on MOUNTR.CMD is buried in the OPERATOR'S GUIDE (AA-4176D-TM) in Section V on page 3-39. It is a note on the format of the file. Why this info isn't in the System Manager's Guide is beyond me. Hope that helps. --ted ------- 10-Jul-81 13:24:27-EDT,673;000000000000 Mail from SU-SCORE rcvd at 10-Jul-81 1324-EDT Date: 10 Jul 1981 0942-PDT From: Mark Crispin Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022 Stanford-Phone: (415) 497-1407 Subject: SFUST% bug/documentation error To: [SU-SCORE]TOPS-20.DIS.104: ; Page 3-338 of the Monitor Calls book explicitly states that SFUST% returns with an updated byte pointer in AC2. In reality, it leaves the byte pointer untouched. Is this a bug or a feature? I suspect that the documentation should be changed to reflect reality, but I'm interested in other folks' comments...any comments from DEC people? -- Mark -- ------- 12-Jul-81 05:21:54-EDT,7017;000000000000 Mail from SU-SCORE rcvd at 12-Jul-81 0521-EDT Mail-from: ARPANET site RUTGERS rcvd at 10-Jul-81 1137-PDT Date: 10 Jul 1981 1430-EDT From: WATROUS at RUTGERS Subject: Abbreviations vs. TBADD/TBDEL To: Admin.MRC at SU-SCORE Remailed-date: 12 Jul 1981 0214-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.104: ; The JSYSes TBADD and TBDEL ignore abbreviations entirely when manipulating command for use with the COMND JSYS. Thus, if you have, say, a CONNECT and a CONTINUE command, with a CON abbreviation for CONTINUE, and you dynamically insert a BLANK command, then the CON abbreviation, which pointed to the CONTINUE entry will now point to the CONNECT entry, since the entire table after the inserted entry has been moved one position. Presumably, you wouldn't like this to happen. We have submitted a previous version of this fix to DEC, who responded that abbreviations are only supported in COMND, so COMND should be responsible for maintaining the integrity of tables. They are considering supplying new functions for COMND to add and delete entries in command tables. Their argument is that some user applications might be broken by enforcing bit 33 as an abbreviation for TB%%%. They also pointed out that some cases wouldn't be handled by the fix we supplied. We've fixed those cases and some more that we've come across. So, if you'd like to be able to use TBADD and TBDEL on command tables for the COMND JSYS, and you don't think you'll be breaking any of your local user applications, then here's what you need to do: Replace the entire routine, XTDEL through TDELZ+1 with XTDEL:: stkvar movem t1,xtdbeg ;save table start aos xtdbeg ;point it to first entry movem t2,xtditm ;and entry address XCTU [HLRZ T4,0(T1)] ;GET USED COUNT MOVE T3,T4 SOSGE T3 ;REDUCE COUNT, TABLE ALREADY EMPTY? RETBAD TDELX1 ;YES ADD T4,T1 ;COMPUTE END OF TABLE movem t4,xtdend CAILE T2,(T1) CAMLE T2,T4 ;DELETED ENTRY WITHIN TABLE? RETBAD TDELX2 ;NO xctu [hlrz t2,(t2)] ;get string addr for entry being deleted call xttst1 ;see if entry is abbreviation jrst xtdela ;it is, go ahead and delete it move t4,t1 ;point to first entry in table xtdelc: caml t4,xtditm ;have we reached entry being deleted? jrst xtdela ;yes, go delete it now xctu [hlrz t2,(t4)] ;get address of string for this entry call xttst1 ;is it an abbreviation? skipa ;it is, check further aoja t4,xtdelc ;check next entry xctu [hrrz t2,(t4)] ;get address of entry this is abbr for came t2,xtditm ;is it entry being deleted? aoja t4,xtdelc ;no, check next entry move t2,t4 ;point to entry call [ savet ;save temporaries call xtdel ;delete abbr for entry being deleted retbad () ;error retskp] retbad () sos t3 ;one less entry in final table sos xtditm ; and entry to delete has moved sos xtdend ; as has end of table jrst xtdelc ;go check this entry xtdela: move t2,xtditm ;restore entry to delete move t4,xtdend ;and end of table pointer XCTU [HRLM T3,0(T1)] ;YES, STORE DECREMENTED COUNT JUMPE T3,TDELZ ;JUMP IF TABLE NOW EMPTY HRLI T2,1(T2) ;COMPACT TABLE, FROM DELETED ENTRY +1 XBLTUU [BLT T2,-1(T4)] ;TO DELETED ENTRY UNTIL END move t4,xtdend sos t4 ;compute the end of the table move t1,xtditm ;get the address of the deleted entry xtdel1: camge t4,xtdbeg ;is the entry within range? jrst xtdel2 ;no, go finish xctu [move t3,0(t4)] ;yes, get that table entry call xttst ;is it an abbreviation jrst [ hrrz t2,t3 ;yes caig t2,(t1) ;has the pointer entry been moved? jrst .+1 ;no, go look for another sos t3 ;yes, adjust the pointer camg t2,xtdend ;only if before end of table xctu [movem t3,0(t4)] ;and save the updated pointer jrst .+1] ;try for more soja t4,xtdel1 xtdel2: move t4,xtdend ;resetup t4 TDELZ: XCTU [SETZM 0(T4)] ;CLEAR EMPTY WORD AT END OF TABLE RETSKP Add TBE as a third argument to the ASUBR at XTADD, and after the CALL CHKTBS at XTADD+2, add jxe t1,cm%abr,xtadd1 ;if not abbreviation, don't check it hrrz t3,ent ;point to entry xctu [move t3,(t3)] ;get entry call xtcabr ;check abbreviation retbad() xtadd1: Replace the code from XTADD2 to the end of the page with movem t4,tbe ;save it for comparisons XTADD2: CAML T1,T4 ;NOW AT 'HOLE'? JRST [ MOVE T3,ENT ;YES, INSERT ENTRY call xttst ;is this an abbreviated entry? call adjint ;yes, adjust pointer if in table UMOVEM T3,0(T1) jrst xtadd3] ;continue moving abbreviations XCTU [MOVE T3,-1(T4)] ;MOVE TABLE TO CREATE HOLE call xttst ;is the entry an abbreviation call adjint ;adjust pointer if in table ;since it was moved XCTU [MOVEM T3,0(T4)] SOJA T4,XTADD2 ;here to fixup the part of table before the hole xtadd4: xctu [move t3,0(t4)] ;get table entry call xttst ;is it an abbreviation? jrst [ hrrz t2,t3 ;yes caig t2,(t1) ;has the pointered to entry been moved? jrst xtadd3 ;no, go look for another call adjint ;yes, adjust pointer if in table xctu [movem t3,0(t4)] ;place it back jrst xtadd3] ; xtadd3: move t2,tba ;get the table address cail t4,1(t2) ;is the pointer still in range? soja t4,xtadd4 ;yes, go try again xtrskp: retskp ;no, all done ;routine to test to see if the entry is an abbreviation ;enter at: xttst, t3 has an entry in it ; xttst1, t2 has a string pointer in it ;returns +1 if it is and +2 if it isn't ;on return: t2 has a pointer to the string xttst: hlrz t2,t3 ;get the address of the entry xttst1: push p,t1 call chktbs ;get flags and byte pointer ; txne t1,cm%fw ;if not flag word ;the monitor doesn't seem to care if cm%fw is set!!! txnn t1,cm%abr ;or not an abbreviation jrst [ pop p,t1 ;then restore the register retskp] ;and ignore this entry, fail return pop p,t1 ;else restore the register ret ;and say it is an abbreviation ;routine to insure abbreviation is substring of keyword pointed to ;t2/ string ;t3/ entry for which string is abbreviation ; returns with error already set up, or skips when verified ; with t2 preserved xtcabr: push p,t2 ;save string pointer call xttst ;get string pointer for keyword jrst xtcang ;abbreviation points to abbreviation! jxn t1,cm%nor,xtcang ;error if not legit keyword move t1,(p) ;get abbreviation call ustcmp ;compare jxe t1,sc%sub,xtcang ;error if not substring pop p,t2 ;restore string pointer retskp ;and return success xtcang: pop p,t2 ;fix up stack retbad taddxx ; and give error ;routine to add 1 to t3 iff it points inside current table ;clobbers t2 adjint: hrrz t2,t3 ;get just address caml t2,tba ;before beginning ot table? camle t2,tbe ;or after end? ret ;yes, do nothing aos t3 ;in table, increment ret And finally, define an error in MONSYM: .err (3001,taddxx,) ------- 13-Jul-81 14:27:36-EDT,1930;000000000000 Mail from SU-SCORE rcvd at 13-Jul-81 1427-EDT Date: 13 Jul 1981 1124-PDT From: Mark Crispin Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022 Stanford-Phone: (415) 497-1407 Subject: [Mike Peeler : New FINGER here] To: MMcM at MIT-AI, TOPS-20 at RUTGERS, G.daCruz at SU-SCORE I intend to implement this interface in MM shortly. --------------- Date: 13 Jul 1981 1038-PDT From: Mike Peeler Subject: New FINGER here To: Admin.MRC Mark, You can now invoke Score Finger as an inferior fork to look up a personal name. Simply place the user name at the beginning of some page and map it (with PMAP%) onto page 777 of the Finger fork. Then start Finger (with SFRKV%) at entry vector position 3 (which is fourth in the entry vector, right after the version information). On success, Finger will return the personal name in place of the username on Finger's page 777, and otherwise it will return the null string. Finger first tries for an exact username match and returns the corresponding personal name if that succeeds. If not, it tries for a unique substring match with all the usernames and personal names it knows. If it finds no match or the substring proves ambiguous, it returns the null string, and otherwise it has found precisely one match and returns the personal name. This satisfies the basic need you expressed in your message entitled "MM/Finger interaction". This linkage is intended to supersede the original scheme of using the RSCAN buffer, which, as several people pointed out, is job-wide and may be contested for by other processes. Note that DDT does use page 777, but that Finger should not ever need DDT when invoked as an inferior. The DOVER program uses this new feature without any apparent problems. Happy hacking, Mike ------- --------------- ------- 14-Jul-81 04:11:50-EDT,4341;000000000001 Mail from SU-SCORE rcvd at 14-Jul-81 0411-EDT Date: 14 Jul 1981 0109-PDT From: Mark Crispin Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022 Stanford-Phone: (415) 497-1407 Subject: TOPS-20 extended addressing status To: [SU-SCORE]TOPS-20.DIS.104: ; Following is an excerpt of a message sent to me by one of DEC's TOPS-20 developers on the status of some problems with extended addressing in release 4. They would like for people to look through this list and send anything else back to them. Please note that the people who are doing this are doing it out of the kindness of their hearts to try to make it as winning as possible. What are most important are known fixes to real bugs, followed by wishlist kinds of things. Please send any comments on this to me, and I'll pass them on to DEC. -- Mark -- ********************************************************************** Below is a list of the problems that have been reported to us regarding extended addressing in R4. While the official position is that we don't support the stuff, we obviously want to get it right. If possible, I would like to publish a list of patches, along with a couple of specs, in a user-read document. Would those of you who use extended addressing verify these fixes for us? We have made significant changes in the code since shipping R4. That implies a couple of things: a) Some of the fixes can't be patched easily into R4. b) We may have broken things that worked in R4. If you have a favorite program that demonstrates a R4 problem, and would like to lend it to us, we could use it to test the current code. 1. Problem: Mark Crispin reported jobs looping in KSELF, waiting in a deadly embrace for share counts to go to zero. Solution: Use Mark's patch, which causes SECMAP to decrement the share count. Status: The code has been rewritten, but it still decrements the share count. 2. Problem: CMU reported a security bug such that a user can SMAP a file and write into it in spite of not having write access to the file. Diagnosis: For historical reasons, CPMAP ignored the access bits returned by FKHPTN. This is no longer valid. Status: A lot of code has been written for this since R4, so there is no patch for R4. 3. Problem: FLKTIM BUGCHK's in jobs using extended addressing. Diagnosis: There are lots of causes of FLKTIM's, but one in particular is related to extended addressing. In R4 a new entry point, FLOCKN, was added to FLOCK to allow nested locking. The left half of FLKOWN is supposed to contain -1 if nesting is allowed. However, if the process every has to block, W1 gets a time, and that time gets stored into FLKOWN. Solution: There are several ways to get around this. We are now allowing nesting for all callers, which eliminates the bug. You can get this effect by making the following change: FLOCK1+5/ CAMN Q1,FORKN JFCL FLOCK1+6/ SKIPL FLKOWN CAME Q1,FORKN If that makes you nervous, you can add another variable to the ACVAR and use the second variable for temporary storage. 4. Problem: Repeat counts don't work when creating private sections. Diagnosis: This must have slipped through the cracks in R4. It just wasn't coded. Status: We now have this working. We trust you can live without it for now. 5. Problem: Chuck Hedrick reported J0NRUN's when swapping space is low. Status: We are unable to reproduce this with our current sources. We may get around to debugging it in R4, but in the meantime we hope you'll just increase your swapping space. 6. Problem: Mark Crispin reported that Release 4 MONSYM or MACSYM defined XHLLI to be XMOVEI. Status: For some reason, the R4 MONSYM has two definitions of XHLLI, and the second (and therefore dominant) one is obsolete. The correct definition equates XHLLI with HLLI. It's fixed in our sources now. 7. Problem: Because of a microcode bug, IBP on a two-word byte pointer produces garbage. Status: It's fixed here, but I don't know when you will get the changes. Meanwhile, ILDB works fine. 8. Problem: With large address spaces, RMAP is painfully slow. Status: We've implemented an extended version of RMAP that takes page ranges, but there's no solution in R4. ------- 15-Jul-81 05:25:30-EDT,1188;000000000001 Mail from SU-SCORE rcvd at 15-Jul-81 0525-EDT Mail-from: ARPANET site RUTGERS rcvd at 14-Jul-81 0921-PDT Date: 14 Jul 1981 1216-EDT From: HEDRICK at RUTGERS (Mngr DEC-20's/Dir LCSR Comp Facility) Subject: problem in DDMP possibly leading to J0NRUN To: admin.mrc at SU-SCORE cc: hall at DEC-MARLBORO Remailed-date: 15 Jul 1981 0220-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.104: ; In module PAGEM, at DDMP, there is code ddmp: lock strlok noint This is clearly wrong. In general one wants to go no-int before getting locks, not afterwards, since otherwise an interrupt could theoretically happen between the lock and the noint. Thus the code should be ddmp: noint lock strlok I do not see that there could in fact be an interrupt during DDMP, so this code shouldn't matter. However we were getting J0NRUN's every few weeks, and the dumps showed that STRLOK was being locked but not unlocked. This is what one would expect from this problem if it were a problem. So it seems safest to change it. We have not had any J0NRUN's (except one whose cause we know) since changing this. ------- 15-Jul-81 06:24:11-EDT,7140;000000000000 Mail from SU-SCORE rcvd at 15-Jul-81 0624-EDT Mail-from: ARPANET site RUTGERS rcvd at 15-Jul-81 0308-PDT Date: 15 Jul 1981 0603-EDT From: HEDRICK at RUTGERS (Mngr DEC-20's/Dir LCSR Comp Facility) Subject: DDT extended addressing problem To: admin.mrc at SU-SCORE cc: hall at DEC-MARLBORO Remailed-date: 15 Jul 1981 0317-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.106: ; Here is what I have found, and what I have accomplished so far. Probably you might as well distribute it to the list. I will not likely do any more for some time, and others might see some problem in what I propose to do. There are some clear bugs in the way effective addresses are handle in $X logic. One of these can be fixed easily. However the other is complex. The problem is that when the effective address is computed by local addressing, if RH(ea) < 20, any memory reference using it gets the AC's. E.g. MOVE 1,2 always moves from AC 2 to AC 1, even when done in section 12. Unfortunately the DDT implementors chose to handle this in the effective address logic. They simply treat MOVE 1,2 as if its effective address were 2 (or 1,,2 - which is equivalent). This is not quite right, as the following examples show: - If you do JRST 2 in section 12, the effective address will turn out to be 2. This is close, but no cigar. It is true that JRST 2 should transfer control to AC 2, even when done in section 12. But the PC will be 12,,2. This shows up if you do a PUSHJ while you are in the AC's. The PC pushed on the stack should be 12,,2 but with the current DDT you will get a simple 2. - Consider DMOVE 1,17. The current DDT will take this to refer to 17 and 20. However it should refer to 17 and 12,,20. - Consider XMOVEI 2,3. This should give [1,,3] in AC 2, because the AC's are considered to be in section 1. In DEC's code, this will give 3. The point is that the effective address should still have the section number in it. The mapping to AC's should occur only when an actual memory reference is to be made, but all internal variables should remember it in the form containing the section number. In order for this to work, an extra bit will be needed so that DDT knows the address was calculated by local addressing. Clearly some occurences of 12,,2 do indeed refer to 12,,2, not AC 2. One can disambiguate these only by knowing whether they are local or global references. The implementors tried to avoid doing this by turning 12,,2 into 2 but as I think I have shown, that will not work. I have a patch that appears to make things work in sections 0 and 1, which are typically where code is. It works (if it does work) because in sections 0 and 1 there is no problem. One can leave around the actual effective address, since 0,,3 and 1,,3 both will result in AC 3. One doesn't need to know whether they were computing locally or not. This fix will *not* work in section 2, as there one has to choose between 2,,3, which is the right effective address but will result in DDT refering to the wrong place in memory, and 1,,3 (or 0,,3) which will refer to the right word, but give wrong results in the cases shown above. I choose 1,,3 in this case, on the grounds that simple memory references are more common than the problem cases shown above. I would be interested in knowing whether anyone sees any problems with this analysis, before I proceed with redesigning the addressing logic of DDT. The following FILCOM shows - a fix to a bug in doing global indirection - the partial fix just mentioned - the code from the Dispatch related to IBP and ILDB File 1) DSK:DDT.MAC[4,211] created: 0519 15-Jul-1981 File 2) DSK:DDT.DEC[4,211] created: 1532 06-Nov-1979 ************** 1)94 JRST CIFIW4 ;[CLH] 1) ;HERE IF GLOBAL ADDRESSING 1) TLZ T,770000 ;[CLH] LEAVE ONLY EFIW Y FIELD 1) HLLZ S,T ;[CLH] UPDATE S TO NEW CURRENT SECTION 1) JRST CIFIW7 ;[CLH] NOT LOCAL, SO NOT LOCAL AC 1) ;HERE IF LOCAL ADDRESSING 1) CIFIW4: HLL T,S ;THEN E STAYS IN LOCAL SECTION **** 2)94 CIFIW4: HLL T,S ;THEN E STAYS IN LOCAL SECTION ************** 1)94 ;HERE TO DETECT AC'S 1) ;[clh] check for AC's: Note that this will work for code in section 1) ;0 or 1, but not in general for higher sections. The problem is that 1) ;JRST 2 will end up with a PC of 1,,2, which is wrong in sections > 1 1) ;Also things like DMOVE 1,17 will load from 1,,17 and 1,,20. 1) CIFIW6: TXNE T,777760 ;[CLH] IS LOCAL REFERENCE TO A REGISTER? 1) JRST CIFIW7 ;[CLH] NO 1) ANDI T,17 ;YES, REDUCE TO UNABIGUOUS AC 1) ; (NOTE "SECTION-NESS" STILL IN S) 1) SKIPE S ;[CLH] IF IN NON-ZERO SECTION 1) HRLI T,1 ;[CLH] AC's are considered in section 1 1) ;CHECK IFIW INDIRECTION 1) CIFIW7: POP P,R ;GET BACK ORIGINAL WORD 1) TXNN R,@ ;IFIW I BIT ON? **** 2)94 ;CHECK IFIW INDIRECTION 2) CIFIW6: TXNN T,777760 ;IS LOCAL REFERENCE TO A REGISTER? 2) ANDI T,17 ;YES, REDUCE TO UNABIGUOUS AC 2) ; (NOTE "SECTION-NESS" STILL IN S) 2) POP P,R ;GET BACK ORIGINAL WORD 2) TXNN R,@ ;IFIW I BIT ON? ************** 1)95 ;[CLH] INSERT LABEL 1) CEFFEX: MOVEI W,INDPTH ;MAX LOOP COUNT FOR INDIRECTION 1) MOVEM W,TEM ;SO WE DON'T GET CAUGHT **** 2)95 MOVEI W,INDPTH ;MAX LOOP COUNT FOR INDIRECTION 2) MOVEM W,TEM ;SO WE DON'T GET CAUGHT ************** 1)140 MOVEM 17,HAK304 ;[CLH] SAVE USER AC17 1) ILDB @I.NSTE ;[CLH] INCREMENT THE USER'S BYTE PTR 1) MOVE 17,HAK304 ;[CLH] RESTORE USER AC17 1) JSR SWAP ;BACK TO DDT CONTEXT **** 2)140 IBP @I.NSTE ;INCREMENT THE USER'S BYTE PTR 2) JSR SWAP ;BACK TO DDT CONTEXT ************** 1)140 JUMPE S,IXBP2 ;[CLH] JUMP IF IN NON-ZERO SECTION 1) TLNN T,(1B12) ;[CLH] NON-ZERO SECTION - IS THIS EXTENDED? 1) JRST IXBP2 ;[CLH] NO, LUCKY - DO IT AS IF IN SECTION 0 1) MOVE R,I.NSTE ;[CLH] YES, GET EA OF OPCODE 1) HRRI R,1(R) ;[CLH] POINT TO SECTION ADDR. 1) PUSHJ P,FETCH ;[CLH] GET IT 1) POPJ P, ;[CLH] FAILED 1) HLLZ S,I.NSTE ;[CLH] GET SECTION # OF OPCODE 1) PUSHJ P,CEFFEX ;[CLH] GET EA OF IT'S TARGET BYTE 1) POPJ P, ;[CLH] FAILED 1) JRST IXBP5 ;[CLH] CONTINUE 1) ;[CLH] INSERT LABELS 1) IXBP2: PUSHJ P,CEFFIX ;CALCULATE BYTE POINTER EFFECTIVE ADDRESS 1) POPJ P, ;MEMORY READ ERROR 1) IXBP5: MOVEM T,I.NEA2 ;REMEMBER IT FOR LATER TYPEOUT 1) EXCH F,FLAGS ;BACK TO $X FLAGS **** 2)140 PUSHJ P,CEFFIX ;CALCULATE BYTE POINTER EFFECTIVE ADDRESS 2) POPJ P, ;MEMORY READ ERROR 2) MOVEM T,I.NEA2 ;REMEMBER IT FOR LATER TYPEOUT 2) EXCH F,FLAGS ;BACK TO $X FLAGS ************** 1)194 PADR: TDNN T,[777776,,777760] ;[CLH] IF 0-17 IN SECTION 0-1 1) TLZ T,1 ;[CLH] THEN PRINT IT AS SECTION 0 1) JRST (AR) ;PADSO OR TOC 1) PADSO: JUMPE T,FP7B ;PRINT A ZERO **** 2)194 PADR: JRST (AR) ;PADSO OR TOC 2) PADSO: JUMPE T,FP7B ;PRINT A ZERO ************** 1)362 DD(HAK304,1) ;[CLH] TEMP USED TO SAVE AC17 IN $X OF IBP 1) DD(I.PXC,1) ;-1 IF $X01 CALLED FROM $PX **** 2)362 DD(I.PXC,1) ;-1 IF $X01 CALLED FROM $PX ************** ------- 21-Jul-81 16:25:23-EDT,5531;000000000000 Mail-from: SU-SCORE rcvd at 21-Jul-81 1625-EDT Mail-from: ARPANET site RUTGERS rcvd at 21-Jul-81 0700-PDT Date: 21 Jul 1981 0956-EDT From: HEDRICK at RUTGERS (Mngr DEC-20's/Dir LCSR Comp Facility) Subject: comnd jsys bug fix To: admin.mrc at SU-SCORE Remailed-date: 21 Jul 1981 1318-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.106: ; Problem: A program sets up a comnd call consisting of two alternatives: a switch and a file spec. It supplies a default file name (via .CMDEF, not the GTJFN defaults). If the user types something illegal, e.g. an illegal switch, no error message is issued. Furthermore, ? causes the program to start, and does not issue the help text. Diagnosis: Defaulting is being done wrong for file names. Normally, the default is copied to the COMND buffer only if it is displayed on the screen. However when a file spec is involved, after the GTJFN the atom buffer is copied to the main COMND buffer. (This is done at CMFIL2+24.) The idea is that if the user typed or ^F during the GTJFN, there will be recognition output which he saw on the screen, and we want it put in the buffer in case of future ^R, etc. This is usually OK, but in the case mentioned above, here is what happens: user types /FOOBAR ? the buffer now contains /FOOBAR ? ^ We call COMND. It fails to recognize /FOOBAR as either a switch or a filename. Thus it supplies the default file name. The default is put into the atom buffer, terminated by CRLF. After the GTJFN, it is copied to the main buffer. the buffer now contains GAZONK.DEL ^ All traces of the illegal switch and the ? have disappeared. The program now parses a confirm, and proceeds on its way. I believe that when a default is supplied, normally it should not be copied into the main buffer. Since the user didn't see it, ^R shouldn't show it. Any typeahead will now remain undisturbed in the buffer. However there are some exceptions to this. If the user typed or ^F, the default is displayed on his terminal. If the default is a partial file name (e.g. without version number), he could now type another or ^F to complete the file name. This completion output must be copied to the buffer, since it showed on his screen. I believe I can show that whenever the user typed or ^F, it is safe to copy the filename back to the buffer. Since and ^F cause the COMND jsys to activate immediately, there can't be any typeahead there. Hence there is no harm done in this case. Thus it seems that the correct solution is to skip copying the file name back to the buffer when the default is supplied, except that if the user typed ^F or , it should be copied: Cure: The following patch goes in COMND, at CMFIL2+24. (It is probably easier to find as CMGJE-7.) File 1) COMND.MAC.13,21-Jul-81 09:18:36 File 2) COMND.MAC.12,10-Jul-81 11:55:00 1)37 txnn f,cm%esc ;[172] if esc was typed, arg was echoed 1) txnn f,cmdeff ;[172] else if default, shouldn't be in buffer 1) CALL CMGJC ;COPY INPUT TO MAIN BUFFER **** 2)37 CALL CMGJC ;COPY INPUT TO MAIN BUFFER ************** We are running with the patch installed in DDT, and all the test cases I can dream up work. However the COMND jsys is so obscure and convoluted that there could be ill effects. Further discussion: The entire concept of supplying defaults because of "null input" is controversial. The Monitor Calls Manual says that defaults are supplied when the user types ^F, , or as the non-blank character in the field. This is quite clear. However in addition, the monitor attempts to supply it when the user types a "null field". SPR 20-13582 (1-Jul-80), by Leslie McMillin, describes in some detail the pitfalls with trying to handle null fields. From that SPR and the response, it appears that in 3A the default is supplied whenever the current user input does not match the syntax of any of the alternatives. I.e. in my example, if the user types a nonexistent switch, this would be treated as an error. Since it was a switch, it matches the switch syntax, and the default is not supplied. However if the user types a comma, it does not match the syntax of any of the options, and the default is supplied. The comma is left around for a later call to COMND. In 4, it appears that the default is used whenever there would otherwise be an error, although this behavior does not seem to be consistent. (It almost looks like a non-existent switch if left for later COMND calls, but a non-existent file is treated as an error. People who are using defaults in sophisticated ways should be warned of this issue. The DEC response to Leslie's SPR was incredibly arrogant, both in tone and in substance. They told Leslie that everything would be fine if she just went back and read her manual more carefully. It seems to me that the supplying of defaults for null fields is in fact not documented, and that it is going to be very difficult to do this in a way that does not lead to surprises. PS: The program that led me to have to fix this bug is our native-mode version of FILCOM. That is now finished, and anyone who wants it is welcome to copy it from us, provided of course that you are licensed for DEC's FILCOM. You will also need our version of the COMND package, which we have modified to handle RSCAN when requested. ------- 25-Jul-81 21:58:20-EDT,1162;000000000000 Mail-from: SU-SCORE rcvd at 25-Jul-81 2158-EDT Mail-from: ARPANET site UTAH-20 rcvd at 24-Jul-81 0813-PDT Date: 24 Jul 1981 0912-MDT From: Randy Frank Subject: Front-end tidbit To: admin.mrc at SU-SCORE Remailed-date: 25 Jul 1981 1851-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.106: ; (Mark, for distribution list) Learned something interesting about the front-end: As shipped from Marlboro, the core memory on the 11/40 is set up to run in non-interleaved mode. It is a trivial jumper change on the memory boards (documented in the prints) to modify 11/40 memory to run 2-way interleaved. Seems to speed up the 11/40 about 15-20%. We have done so, and it seems to improve some 11/40 problems (especially lost input data at high speeds), although the problems don't go away. We are planning to add a cache to the 11/40 (on a trial basis) to see if it further improves 11/40 performance. Will let you know the results. Randy (P.S. Does anyone have any idea why DEC ships the damn thing non-interleaved? Seems to be a stupid thing to do.) ------- 27-Jul-81 20:13:57-EDT,747;000000000000 Mail-from: SU-SCORE rcvd at 27-Jul-81 2013-EDT Mail-from: ARPANET site RADC-TOPS20 rcvd at 27-Jul-81 0830-PDT Date: 27 Jul 1981 1122-EDT From: Donna Lynch To: ADMIN.MRC at SU-SCORE cc: ADMIN at RADC-TOPS20 Subject: DEC'S ARCHIVE Message-ID: Remailed-date: 27 Jul 1981 1707-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.108: ; Mark-- I am system manager on RADC TOPS-20, replacing Bob Doane. I am quite unhappy with DEC's archive. Would you know of anyone who has a better archive system? Could you send such a message to your distribution list? Thank you. Donna Lynch -------- 28-Jul-81 03:10:05-EDT,2717;000000000001 Mail-from: SU-SCORE rcvd at 28-Jul-81 0309-EDT Mail-from: ARPANET site RUTGERS rcvd at 27-Jul-81 1736-PDT Date: 27 Jul 1981 2031-EDT From: HEDRICK at RUTGERS (Mngr DEC-20's/Dir LCSR Comp Facility) Subject: Re: DEC'S ARCHIVE To: ADMIN at RADC-TOPS20 cc: admin.mrc at SU-SCORE In-Reply-To: Your message of 27-Jul-81 1122-EDT Remailed-date: 28 Jul 1981 0004-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.108: ; It all depends upon what you mean by better. In my opinion, the DEC archiver does a much better job of storing information about offline files, and doing retrievals, than anything else I have seen. Since these facilities have to be integrated into monitor and spooling system, you are not going to find anyone else who has done a system like that. I had an archiver under release 3A. To archive a file you used a program ARCHIVE. It set a bit in the FDB, and another bit in a system file that said there was a request for that directory. Then the operator used a privileged command within ARCHIVE to scan the system. For each directory that was marked in the system file, it looked at all files to find those with the bit in the FDB. It then created .CMD files for DUMPER and the EXEC to dump and delete the files. We modified DUMPER to append the file name, save date, etc. to a file 20-ARCHIVE.DIR in the user's area. The advantages of this system are: - very simple. none of the complexities of Archived, Migrated, Offline, Invisible, etc. The data is in a normal text file which you can search with any editor. (Also this keeps you from filling up your directory.) - saving is fast, since only the directories with requests are scanned, and the scan happens only once. The rest is done by command files. DEC's archiver seem to look at every file on the system 4 times - the two tapes are guaranteed to be identical, since they are produced with the same command file. Thus if something odd happens to one, you can make a copy of the good one. This is a fairly common problem. Some files take the system stand-alone to do archiving just to make sure the two tapes are the same. However we abandoned this system in favor of DEC's, because - archive retrievals had to be done by hand. This isn't too important, since we had far more saves than retrieves. - there was slightly more manual intervention in the dump, though most of the stuff was in command files. - we thought it would be nice to have the data in the directory I am no longer so sure that this was a good idea. I think the efficiency and simplicity of our old system is probably a win. ------- 29-Jul-81 22:58:57-EDT,850;000000000000 Mail-from: SU-SCORE rcvd at 29-Jul-81 2258-EDT Date: 29 Jul 1981 1955-PDT From: Mark Crispin Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022 Stanford-Phone: (415) 497-1407 Subject: IPCF MAILER crashes To: [SU-SCORE]TOPS-20.DIS.108: ; SCORE has been experiencing some strange MAILER crashes, with PCs like 2, 600105, etc. One very obvious bug is at ONQ+4; there is a RET which should be JRST [ POP P,W RET] However, this only happens if MAILER is about to crash due to lack of further free storage. I am trying replacing the HALTF in the literal that reports NO MORE FREE STORAGE AVAILABLE with the following: MOVEI A,4 MOVEI B,W MSEND ;SEND IT OFF NOW ERJMP DOQ1 ;TOSS IT ON THE FLOOR IF IT FAILS JRST DOQ ;DO THE REMAINDER OF THE QUEUE ------- 30-Jul-81 18:52:07-EDT,1835;000000000000 Mail-from: SU-SCORE rcvd at 30-Jul-81 1851-EDT Mail-from: ARPANET site UTEXAS-20 rcvd at 30-Jul-81 1539-PDT Date: 30 Jul 1981 1735-CDT From: Clive Dawson Subject: Misc. things To: admin.mrc at SU-SCORE Remailed-date: 30 Jul 1981 1545-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.108: ; Mark-- A couple of things have arisen that I'd like your comments on. 1) A user on our other 2060 system managed to create 4-page file which had a byte-count of approx. 17,000,000,000 36-bit bytes. Presumably he did this by accident, but it turns out that an unprivilged user can also do this on purpose. Anyway, he then proceeded to try and print the file, which caused LPTSPL to hang in a solid RUN state, doing a SIN JSYS. A couple of hours went by before the operator noticed this and tried to cancel the print job with OPR. This didn't work, and we ended up having to kill LPTSPL. When we brought it back up it of course grabbed the same job again, etc., until I finally discovered the problem with the file and made the byte count more reasonable using REV. This is a clearly undesireable situation, since any user can cause plenty of headaches for operators. The question is, what is a good fix? Should users be prevented from munging byte-counts, or at least setting them to something ridiculous? Or should the monitor know enough not to get stuck when trying to read such files (i.e. pay more attention to the actual page count)? 2) Do you know of anybody who has hacked the monitor to allow ^H as a rubout character, WITHOUT the undesireable effect of having ^H's converted to DEL's when a user program does single-character input? ------- 31-Jul-81 20:49:03-EDT,665;000000000000 Mail-from: SU-SCORE rcvd at 31-Jul-81 2048-EDT Mail-from: ARPANET site USC-ISIB rcvd at 31-Jul-81 1629-PDT Date: 31 Jul 1981 1629-PDT From: MCGREAL at USC-ISIB Subject: Accounting software To: Larson, MRC at SU-SCORE, Knight Remailed-date: 31 Jul 1981 1743-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.108: ; Does anyone have a program that will dump login and logout times from the fact files on rel. 4 for a specific user only. Better yet a program that will allow you to dump various fields with optional filters to pick out particular users or pieslices etc. Thanks, Gary ------- 1-Aug-81 02:23:19-EDT,847;000000000000 Mail-from: SU-SCORE rcvd at 1-Aug-81 0223-EDT Mail-from: ARPANET site SRI-KL rcvd at 30-Jul-81 2001-PDT Date: 30 Jul 1981 2000-PDT From: Chris Ryland Subject: outstanding bug with SIN? To: admin.MRC at SRI-KL Remailed-date: 31 Jul 1981 2317-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.108: ; Mark: Do you happen to know if the R4 bug with bogus destination byte pointers to SIN has been fixed? In particular, do the following: MOVE 1,JFN MOVE 2,[770777,,anything] MOVNI 3,^D512 SIN and your program will hang in the SIN for a few seconds before the system crashes with an ILLPT3. I haven't looked into it, because I presume this is a silly non-zero-section bug which has probably been fixed. Has it? Anyone want to try it? /Chris ------- 4-Aug-81 01:31:19-EDT,953;000000000000 Mail-from: SU-SCORE rcvd at 4-Aug-81 0131-EDT Mail-from: ARPANET site MIT-XX rcvd at 3-Aug-81 1518-PDT Date: 3 Aug 1981 1816-EDT From: Nat Mishkin Subject: FFORK/RFORK To: admin.mrc at SU-SCORE Remailed-date: 3 Aug 1981 2222-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.108: ; Do you know of this problem? Do you know of a solution? If a fork (call it A) freezes (FFORKs) another fork (call it B) which has the "inferior fork termination" interrupt (.ICIFT) enabled and itself has a fork (call it C) which has previously halted normally (via HALTF), then when A unfreezes (RFORKs) B, B gets another fork termination interrupt (presumably from C). Diagrammatically: A FFORK...RFORK | B .ICIFT enabled | C halted I grovelled around in the PSI code in the monitor for a while but I couldn't find the answer. -- Nat Mishkin ------- 4-Aug-81 20:33:52-EDT,1063;000000000000 Mail-from: SU-SCORE rcvd at 4-Aug-81 2033-EDT Mail-from: ARPANET site SANDIA rcvd at 4-Aug-81 0911-PDT Date: 4 Aug 1981 1011-MDT From: Norm Samuelson Subject: FTP and FTPSER bugs To: admin.mrc at SU-SCORE Remailed-date: 4 Aug 1981 1727-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.108: ; (Mark - please send this to your distribution list) The DEC versions of FTP and FTPSER use the old style 8-bit arpanet addresses internally. That causes problems when a host on a large numbered imp (one which will not fit in the 8-bit format) tries to communicate with any other host. I have tried to fix these bugs in the most straightforward way I could, without adding any other useful features. All sites which are running vanilla DEC versions of FTP and FTPSER should install these patches. The patched files are available in directory at SU-SCORE or in at SANDIA. There are .MAC files and .DIF files for both FTP and FTPSER. ------- 6-Aug-81 16:26:00-EDT,549;000000000000 Mail-from: SU-SCORE rcvd at 6-Aug-81 1625-EDT Mail-from: ARPANET site BBNG rcvd at 6-Aug-81 1022-PDT Date: 6 Aug 1981 1323-EDT From: Dan Tappan To: Admin.MRC at SU-SCORE Remailed-date: 6 Aug 1981 1319-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.110: ; Mark, could you forward this to the 20 list (unless you know the answer). Does anyone know the format of IPCF messages sent to/from QUASAR? I'm particularly interested in SUBMIT messages. Dan ------- 7-Aug-81 23:01:47-EDT,3561;000000000000 Mail-from: SU-SCORE rcvd at 7-Aug-81 2301-EDT Mail-from: ARPANET site USC-ISIC rcvd at 7-Aug-81 1521-PDT Date: 7 Aug 1981 1513-PDT From: JGOLDBERGER at USC-ISIC (Joel Goldberger) Subject: Performance improvement for Class-Scheduler To: Admin.MRC at SU-SCORE Remailed-date: 7 Aug 1981 1953-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.110: ; Problem: 1) Class Scheduler is too rigorous in using Class & Job Distances for ordering of GOLST. Q1 & Q2 should always be above the "compute" queues reagrdless of windfall or how greedy they are. 2) Network terminals should be treated as "physical", only PTYs should be penalized Cause: 1) The actual Q a fork is on is disregarded if Class-Scheduling is on. 2) Check is being made for "physical TTY" rather than specifically PTY Solution: 1) Recognize Q1 & Q2 as special. 2) Use CHKPTY instead of CKPHYT -------------------------------------------------- ;SCHED.MAC.2130 & SCHED.MAC.2530 27-Jul-81 2031 LINE 1, PAGE 1 1) ;<4.ISI-MONITOR>SCHED.MAC.2130 31-Mar-81 13:25:06 Edit by SMITH LINE 1, PAGE 1 2) ;ISISRC:<4.ISI-MONITOR>SCHED.MAC.2530 4-May-81 13:13:58, Edit by CHASE 2) ;#253 Use CHKPTY, not CKPHYT, to decide if line is pty vs "physical" 2) ;ISISRC:<4.ISI-MONITOR>SCHED.MAC.2370 14-Apr-81 09:44:10, Edit by JGOLDBERGER 2) ;#237 Give additional priority to forks in TCOTST as well as those in TCITST 2) ;ISISRC:<4.ISI-MONITOR>SCHED.MAC.2340 13-Apr-81 16:10:31, Edit by JGOLDBERGER 2) ;#234 Make Q1 & Q2 more loveable at CORFC4-2 & CORF55 2) ;<4.ISI-MONITOR>SCHED.MAC.2130 31-Mar-81 13:25:06 Edit by SMITH LINE 36, PAGE 74 1) JUMPL T1,R ;IF CLASS IN WINDFALL, NO BOOST 1) CAIN CX,INTQ1 ;SECOND INTERACTIVE QUEUE? 1) FADRI T1,(EXP 0.5) ;YES. ATTENUATE CLASS DISTANCE SUCH 1) ; THAT A WELL-BEHAVED CLASS WILL 1) ; ACHIEVE PRIORITY ON THIS QUEUE 1) RET ;AND DONE LINE 36, PAGE 74 2) ;#234 JUMPL T1,R ;IF CLASS IN WINDFALL, NO BOOST 2) CAIN CX,INTQ1 ;SECOND INTERACTIVE QUEUE? 2) ;#234 FADRI T1,(EXP 0.5) ;YES. ATTENUATE CLASS DISTANCE SUCH 2) ; THAT A WELL-BEHAVED CLASS WILL 2) ; ACHIEVE PRIORITY ON THIS QUEUE 2) MOVSI T1,(EXP 1.0) ;#234 make Q2 forks better than other Queues, 2) ;#234 but not as good as Q1 2) RET ;AND DONE LINE 6, PAGE 75 1) SKIPL T1 ;IN WINDFALL? 1) CORF55: SKIPA T1,[EXP 3.1] ;NO. USE BIG BOOST LINE 6, PAGE 75 2) ;#234 SKIPL T1 ;IN WINDFALL? 2) SKIPA ;#234 Ignore windfall status for Q1 2) CORF55: SKIPA T1,[EXP 3.1] ;NO. USE BIG BOOST LINE 13, PAGE 75 1) FADRI T1,(0.5) 1) CALLRET PB2] ;RESTORE T2 AND RETURN LINE 14, PAGE 75 2) ;#234 FADRI T1,(0.5) 2) MOVSI T1,(2.0) ;#234 Q1 forks go to the head of the line 2) CALLRET PB2] ;RESTORE T2 AND RETURN ; ISIMON:SCHED.MAC.2130 & ISIMON:SCHED.MAC.2530 27-Jul-81 2031 PAGE 2 LINE 19, PAGE 85 1) CAIN 2,TCITST ;TTY INPUT? 1) JRST [ HLRZ 2,FKSTAT(FX) ;YES 1) CALL CKPHYT ;IS IT A PHYSICAL TERMINAL? 1) JRST NEWST2 ;FOR PTY, FOLLOW NORMAL ALGORITHM 1) JRST NEWST1] ;YES, BE MORE GENEROUS 1) NEWST2: LOAD 2,FKQN ;CURRENT QUEUE LINE 19, PAGE 85 2) CAIE 2,TCOTST ;#237 TTY Output ? 2) CAIN 2,TCITST ;TTY INPUT? 2) JRST [ HLRZ 1,FKSTAT(FX) ;#253 YES 2) CALL CHKPTY ;#253 IS IT A PTY? 2) JRST NEWST1 ;#253 NO, BE MORE GENEROUS 2) JRST NEWST2] ;#253 FOR PTY, FOLLOW NORMAL ALGORITHM 2) NEWST2: LOAD 2,FKQN ;CURRENT QUEUE ------- 7-Aug-81 23:12:57-EDT,4181;000000000000 Mail-from: SU-SCORE rcvd at 7-Aug-81 2312-EDT Mail-from: ARPANET site USC-ISIC rcvd at 7-Aug-81 1521-PDT Date: 7 Aug 1981 1515-PDT From: JGOLDBERGER at USC-ISIC (Joel Goldberger) Subject: Problems CRJOBing detached jobs To: Admin.MRC at SU-SCORE Remailed-date: 7 Aug 1981 1953-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.110: ; Problem:1) CRJOBing a detached job hangs on the DVCHR in RTTYMD 2) When you "CRJOB" a detached job and then attach to it, the terminal modes are wrong (echo is off, etc.) and if you try to continue the fork that was running the EXEC says "Program never RUN". Cause: 1) The Fork created by CRJOB is never set up as one belonging to the EXEC and therefore never marked as RUN. 2) The initial TTY modes saved at startup are junk since they apply to a detached terminal. Solution: 1) Change CMDN5E to do standard setup for an EXEC owned fork and mark it as having been run. 2) Make RTTYMD recognize detached state and read TTY modes from some known terminal. On our systems TTY1 is the error TTY: and always has valid modes or a reasonable nature. 3) Make LTTYMD avoid DVCHR when no TTY attached -------------------------------------------------- CMDN5E: ; Check to see if CRJOB/PRARG start up & if so, a program to run SKIPE CRPRA ; CRJOB start up? JRST [ HRRZ A,CRPRA+.CJPLP ; Yes, get flags ptr MOVE B,CRPRA(A) ; then flags TLNN B,(1B2) ; Want fork started? JRST .+1 ; No MOVEI A,.FKSZE ;#01 Get a Buffer for FRKTBL entry MOVEI B,XDICT ;#01 From Perm Free Space CALL GETMEM ;#01 HALTF ;#01 Can't happen at this point MOVE Q1,B ;#01 Save Pointer MOVE A,FORK ;#01 Get fork handle MOVX B,FK%RUN ;#01 Flag it as having run IORM B,SLFTAB(A) ;#01 ... MOVEM A,RUNFK ;#01 and also as current running fork HRRM Q1,SLFTAB(A) ;#01 Save addr in FRKTAB MOVSI B,.FHSLF ;#01 We own it MOVEM B,.FKOWN(Q1) ;#01 ... MOVSI B,ITTYMD ;#01 Use Initial TTY modes HRRI B,.FKPTM(Q1) ;#01 Loc for Program/TTY modes BLT B,.FKPTM+NTTYMD+1(Q1) ;#01 Store the modes HRRZ A,CRPRA+.CJPKP ; Get ptr to fork & SFRKV offset HRRZ B,CRPRA(A) CALL CLPRA ; Clear CRJOB/PRARG area PUSH P,[CMDIN4] ; Where to return when done JRST ..STCR] ; Run it CALL CLPRA ---------- SETIOF:: GJINF ;#01 Find out if terminal attached HRRZ A,CIJFN ;FIND OUT WHERE WE'RE READING FROM SETZM TINPF ;#01 First assume not TTY: SKIPGE D ;#01 If detached CAIE A,.PRIIN ;#01 and reading from primary input CAIA ;#01 RET ;#01 return now DVCHR LDB B,[221100,,B] ;GET DEVICE TYPE OF INPUT DEVICE CAIN B,.DVTTY ;#01 GOOD GUESS? SETOM TINPF ;#01 NO, LOUSY ONE. RET -------------------------------------------------- LTTYMD: SKIPN (Q1) ;DO NOTHING IF BLOCK IS 0 DUE TO A BUG OR RET ;A STRANGE INTERRUPT-RESTART SEQUENCE ATSAVE MOVEI A,.CTTRM MOVE B,TTWMOD(Q1) ;FILE MODE WORD TXZ B,TT%OSP ;ENSURE NO OUTPUT SUPPRESS SFMOD GJINF ;#01 JUMPL D,NOTTY1 ;#01 Avoid DVCHR & MTOPR if detached MOVEI A,.CTTRM ;#01 DVCHR ;MTOPR WORKS ON TTY ONLY -------------------------------------------------- RTTYMD: ATSAVE STKVAR ;#01 Variable for TTY designator MOVEI A,.CTTRM ;#01 Assume we'll use .CTTRM MOVEM A,TERMNO ;#01 ... GJINF ;#01 Check for Detached JUMPL D,[MOVEI A,.TTDES+1 ;#01 Detached, use TTY1 (It has reasonable ;#01 modes ) MOVEM A,TERMNO ;#01 JRST .+1 ] ;#01 Rejoin the flow MOVE A,TERMNO ;#01 Use whichever was selected RFMOD MOVEM B,TTWMOD(Q1) DVCHR ;MTOPR WORKS ON TTY ONLY LDB B,[POINTR B,DV%TYP] ;GET DEVICE TYPE CODE CAIE B,.DVTTY ;SKIP IF IT'S A TERMINAL JRST NOTTY2 ;NO - NOT A TTY MOVEI A,4 ;PUT LENGTH INTO BLOCK MOVEM A,TTWMSK(Q1) MOVE A,TERMNO ;#01 NOW SAVE THE MASK MOVEI B,.MORBM MOVEI C,TTWMSK(Q1) MTOPR ERJMP NOTTY2 ;ERROR MEANS WRONG MONITOR MOVEI B,.MORFW ;NOW FOR THE FIELD WIDTH MTOPR MOVEM C,TTWFWT(Q1) MOVEI B,.MOSFW SETZ C, ;TURN OFF FIELD WIDTH MTOPR NOTTY2: MOVE A,TERMNO ;#01 ------- 10-Aug-81 18:03:10-EDT,1455;000000000000 Mail-from: SU-SCORE rcvd at 10-Aug-81 1803-EDT Mail-from: ARPANET site RUTGERS rcvd at 7-Aug-81 2210-PDT Date: 8 Aug 1981 0102-EDT From: HEDRICK at RUTGERS (Mngr DEC-20's/Dir LCSR Comp Facility) Subject: Re: Performance improvement for Class-Scheduler To: JGOLDBERGER at USC-ISIC cc: Admin.MRC at SU-SCORE In-Reply-To: Your message of 7-Aug-81 1813-EDT Remailed-date: 9 Aug 1981 1437-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.110: ; It is not clear to me that the reported change for Q1 and Q2 is really a bug fix. I can see that some sites might want it that way. However the reason we turned on the class scheduler was that compiles were never getting done. Our interpretation was the "interactive" jobs were taking over the system. Now I am as willing as the next man to give a certain priority to jobs coming out of TI wait. But I would like to restrict this priority to jobs that are "well-behaved". It is quite possible to create interactive tasks that take more than their fair share of the CPU. I want them held in check, to allow the rest of us to get some work done. I believe that the class scheduler as supplied by DEC does this. It may result in spotty response now and then, but my video editor is still usable, and people are getting work done. I would be curious whether you believe that your patch will have ill effects for us. ------- 10-Aug-81 18:49:09-EDT,868;000000000000 Mail-from: SU-SCORE rcvd at 10-Aug-81 1849-EDT Date: 10 Aug 1981 1545-PDT From: Bob Knight Subject: Wedged LPTSPLs. To: [SU-SCORE]TOPS-20.DIS.110: ; We at LOTS have seen a lot of wedged LPTSPLs. The symptom is that LPTSPL has just executed a MTOPR with an argument of .MONOP ($MTOPR called from OUTDMP+4 in LPTSPL), and is in a scheduler test of STSWAT (wait for status has arrived from the -11). Lighting bits 19 (status has arrived) and 30 (EOF) in LPTST1 in the monitor cures it. The problem is intermittent and has been observed both on a vanilla-hardware -20 with a R4 front end and 2 -20s with a Print- ronix interface and R3A front end. Somebody's dropping a status response on the floor, but we aren't sure who yet. Has anyone out there seen this prob- lem? Bob Knight ADMIN.KNIGHT@SCORE ------- 10-Aug-81 20:12:37-EDT,612;000000000000 Mail-from: SU-SCORE rcvd at 10-Aug-81 2012-EDT Mail-from: ARPANET site CIT-20 rcvd at 10-Aug-81 1409-PDT Date: 10 Aug 1981 1409-PDT From: Barry Megdal Subject: bliss-11 To: admin.mrc at SU-SCORE Remailed-date: 10 Aug 1981 1647-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.110: ; I'm interested in getting a copy of a BLISS-11 compiler (to run on a 20). Ive heard that there are various versions around. Are you familiar with said versions and from where I can get them? Else, who should I ask? Thanks. B. Megdal ------- 10-Aug-81 23:16:55-EDT,536;000000000000 Mail-from: SU-SCORE rcvd at 10-Aug-81 2316-EDT Mail-from: ARPANET site USC-ECL rcvd at 10-Aug-81 1717-PDT Date: 10 Aug 1981 1714-PDT From: BEC.SHAPIN at USC-ECL Subject: FORUM for tops20 To: admin.mrc at SU-SCORE cc: bec.shapin at USC-ECL Remailed-date: 10 Aug 1981 1722-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.110: ; Mark, Do you know if CONFER has been converted for TOPS20 or know of any TOPS 20 computer aided conferencing system? Ted Shapin. ------- 12-Aug-81 02:05:25-EDT,2545;000000000001 Mail-from: SU-SCORE rcvd at 12-Aug-81 0205-EDT Mail-from: ARPANET site MIT-XX rcvd at 11-Aug-81 1704-PDT Date: 11 Aug 1981 2003-EDT From: Nat Mishkin Subject: Several things To: admin.mrc at SU-SCORE Remailed-date: 11 Aug 1981 2257-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.110: ; The following are some things of general interest. - In the category "now that we've got you hooked...": We just received the renewal for our "Binary Program Update Service Agreement" from DEC on which they informed us that the "TOPS-20 Source Package" is "no longer available". Some checking with our local sales people turns up the fact that instead of the present "self-maintenance" agreement whereby DEC supplies new source releases to source licensees, they are going to charge $8K per release. This of course assumes that you've already coughed up the $??,000 for the source license in the first place. Does anyone have more (or conflicting) information on this subject? It seems to me that this new arrangement is somewhat in conflict (at least ethically) with the understanding one got when one bought a source license. - In the category bugs: (1) I had a DUMPER problem which showed up when doing a retrieve. Apparently when doing some ARCHIVE, DUMPER numbered the 1st saveset on a tape "2", the 2nd "3", etc. The problem is that the files saved in the 2nd saveset (number "3") had their tape location saved in the FDB as saveset "2". When a retrieve was done, the file was erroneously retrieved from the 1st saveset on the tape (DUMPER RETRIEVE just looks at the tape#:ss#:file# when it retrieves the file). Anyone seen anything like it? (2) I saw a MONPDL BUGHLT. When I looked at UPDL in the dump, the process was deep inside COMND and apparently got a carrier off interrupt and jumped to JOBCOF to logout. I don't think this would have blown the stack except for the fact that for some reason while in the JOBCOF logic, it got the interrupt again and re-entered at JOBCOF. Any suggestions on increasing the size of UPDL? - In the category "folklore": can anyone tell me what area of the monitor one can expect to be trashed in a dump from having been overwritten by BOOT? For a while I've been looking at dumps with the RESCD around LCKTTY trashed and it wasn't until now that I thought that this might be due to BOOT. -- Nat Mishkin ------- 12-Aug-81 02:21:26-EDT,1070;000000000001 Mail-from: SU-SCORE rcvd at 12-Aug-81 0221-EDT Date: 11 Aug 1981 2311-PDT From: Mark Crispin Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022 Stanford-Phone: (415) 497-1407 Subject: Re: Several things To: NWM at MIT-XX cc: [SU-SCORE]TOPS-20.DIS.110: ; In-Reply-To: Your message of 11-Aug-81 1703-PDT About your MONPDL bug halts due to recursive JOBCOF calls; I know that can happen for ARPANET jobs which get carrier off interrupts while in the middle of COMND (or while the dynamic data base for the TTY is locked). I fixed it by setting a new flag in the dynamic data saying "already in JOBCOF"; if that flag is set then JOBCOF just dismisses. If the terminal dynamic data base is locked, it cannot be detached. JOBCOF tries to detach the job, but it can't. Since the job is on a network terminal, it tries to close the network connection because it is detaching (or so it thinks!). Closing the network terminal causes a carrier off PSI, and... RECURSION! -- Mark -- ------- 12-Aug-81 03:01:59-EDT,1751;000000000000 Mail-from: SU-SCORE rcvd at 12-Aug-81 0301-EDT Mail-from: ARPANET site AFSC-HQ rcvd at 7-Aug-81 1259-PDT Date: 7 Aug 1981 1558-EDT From: Major Bob Baker To: ADMIN.MRC at SCORE cc: BAKER at AFSC-HQ Subject: PA1050 Problem Message-ID: Remailed-date: 11 Aug 1981 2349-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.110: ; Mark, Have you worked with the TOPS-20 compatibility package, PA1050? I'm having a problem because the INPUT UUO works differently on TOPS-10 and TOPS-20. The problem shows up when I have INITed my controlling TTY and am reading from it with INPUT. If I type some non-break characters and then a Ctrl-Z, TOPS-10 works as follows: As soon as Ctrl-Z is typed, the INPUT UUO returns to the program. The end-of-file flag (as determined by STATZ or STATO) is not set. The program can then process the characters in the input buffer, up to and including the Ctrl-Z. The next INPUT call returns immediately with the EOF flag set. In other words, if INPUT returns with EOF set, it means the buffer is empty and the end-of-file condition (Ctrl-Z) was detected on the previous INPUT. Under TOPS-20, when Ctrl-Z is typed the INPUT UUO returns to the program as with TOPS-10, but the EOF flag is already set. The program sees this (with a STATO), assumes it has processed all input, and goes on its way. Thus it fails to process the characters read in by the last INPUT before the Ctrl-Z. Do you know if this difference is intentional? It doesn't seem like it should be, because it can make programs which work under TOPS-10 bomb under TOPS-20. Bob Baker -------- 12-Aug-81 19:56:31-EDT,723;000000000000 Mail-from: SU-SCORE rcvd at 12-Aug-81 1956-EDT Mail-from: ARPANET site UTAH-20 rcvd at 12-Aug-81 0811-PDT Date: 12 Aug 1981 0910-MDT From: Randy Frank Subject: Re: Several things To: NWM at MIT-XX, admin.mrc at SU-SCORE In-Reply-To: Your message of 11-Aug-81 1803-MDT Remailed-date: 12 Aug 1981 1651-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.110: ; Re: the source issue. We were told the same thing, namely, that instead of charging $4K per year for continuing a source license, there would be a charge everytime a new monitor was released (but no annual charge). The $8K seems high, but doesn't surprise me. Randy ------- 12-Aug-81 20:05:23-EDT,1521;000000000000 Mail-from: SU-SCORE rcvd at 12-Aug-81 2005-EDT Mail-from: ARPANET site UTEXAS-20 rcvd at 12-Aug-81 0947-PDT Date: 12 Aug 1981 1144-CDT From: Clive Dawson Subject: Re: Several things To: NWM at MIT-XX, admin.mrc at SU-SCORE In-Reply-To: Your message of 11-Aug-81 1903-CDT Remailed-date: 12 Aug 1981 1653-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.110: ; Regarding software maintenance licenses for monitor source sites: We were also surprised that self-maintenance was no longer available. The way DEC explained it to us was that somebody figured out that new releases of the monitor, exec, and front-end sources are taking place about every two years. Therefore, rather than pay n hundred dollars a month for the self-maintenance service, they simply lump the whole thing into a one-time fee at the time of the release. In other words, the one-time price of a new release is supposed to be pretty close to what 2 years of self maintenance would have cost you. It is easy to see what DEC is up to. At each of the last several DECUS conferences, source sites have repeatedly pointed out that binary patches provided in the standard SPR answers are of little use to those who have to update source files. It seems to me that we finally have DEC's answer on this: they have eliminated the special self-maintenance service for source sites, making source- level patches a moot point. Clive ------- 12-Aug-81 20:16:49-EDT,6336;000000000000 Mail-from: SU-SCORE rcvd at 12-Aug-81 2016-EDT Mail-from: ARPANET site RUTGERS rcvd at 12-Aug-81 1429-PDT Date: 12 Aug 1981 1727-EDT From: HEDRICK at RUTGERS (Mngr DEC-20's/Dir LCSR Comp Facility) Subject: Re: Several things To: NWM at MIT-XX cc: admin.mrc at SU-SCORE In-Reply-To: Your message of 11-Aug-81 2003-EDT Remailed-date: 12 Aug 1981 1704-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.110: ; 1) The change in source maintenance is the result of demands from users at DECUS. I was not one making the demand, but I think DEC has in good faith responded to what they heard as user requests. The problem was that monitors are released about once every 1.5 years. So if you have a source update contract, as we (and I guess you) did, there were some years during which you paid, but got nothing. Some sites had problems with their auditors about that. Thus they have changed it so that you pay only when there is an actual release. The charge for a release was supposedly calculated to be 1.5 times the previous yearly charge, so that things would come out the same in the end. Possibly it is 1.5 times the previous charge plus some price increase, but there are price increases all the time. I also prefer the old arrangement, and feel queasy under the new one, but I can't come up with any concrete problem with it, assuming DEC does what they say they will do (i.e. sell the new release to all licensed sites for a price comparable with the old contract price). 2) Yes, we have seen the problem with DUMPER also. Actually, we have done a fair amount of work with DUMPER, and you (and others) might like to take all or part of it. You should look at s:<4-bundled>dumper.*. .DEC is DEC's original. .MAC is our current. .DIF is an REDIT difference file from which I have removed some of the more obviously site-dependent changes (however I have not tested the version produced from it). Here is a list of the changes we have made. (I hope whoever is scanning this list at DEC will take note, as one or two of these have never been SPR'ed.) I believe that edit 13 answers your particular question. The edits marked with * are those that are present in DUMPER.DIF. You should feel free to just take DUMPER.MAC. I think the only thing that would be likely to cause incompatibilities is the fact that we don't set files invisible when archiving them. The reason is that the EXEC already does this. If you say ARCHIVE FOO, the EXEC sets FOO invisible. The only way it could be visible when DUMPER gets to it is if the user explicitly set it visible again. In that case it is considered unfriendly for DUMPER to make it invisible again. ;local edits -*-.=1005 ;1* - make it handle tops10 sfd's - not marked. This takes only a few lines ; of code, and makes migration from Tops-10 to Tops-20 feasible for ; sites that use SFD's on the 10. Also, it handles the fact that ; Tops-10 uses _ to separate the project and programmer numbers, ; while DUMPER thinks they use - [We have a special version of ; dumper in which the CREATE command works for Tops-10 BACKUP tapes. ; This was what we used for making our initial migration from Tops-10 ; to Tops-20. We have not bothered to move that patch to later ; releases, since we don't anticipate remigrating. ;2 - add archive mode - this was an earlier archiving system, which we ; have now commented out (in edit 14) ;3 - add take command - needed by the old archiver, but generally useful. ; I use this for preparing SAIL and PASCAL export tapes. ;4 - add CSAVE command - needed by the old archiver. The problem was that ; we had to be able to write an arbitrary number of specified files. ; But a given SAVE command can only list about 10 files, or your ; job runs out of JFN's. CSAVE is like a save, but it continues a ; previous save set. So we just break the commands up into groups ; of 10 files, using CSAVE for all but the first. ;5 - daw 12/12/78 make dumper parse wild fields, not ; just wildcard them entirely ; from Dispatch 5/78 pg. 181 (SPR # 20-11419) ; This edit has been withdrawn, as DEC put it in ;6* - daw 12/3/80 fix loop due to Illegal Record Length ; from Dispatch 10/15/80 pg. 3-19 (SPR # 20-14491) ;7* - daw 12/3/80 avoid ?Drive probably offline due to TM03 error ; from Dispatch 10/15/80 pg. 3-23 (SPR # 20-14685) ;10 - daw 1/26/81 don't set file invisible when archiving - this ; is due to the way we use archiving, and other sites may prefer ; not to do it ;11* - daw 1/27/81 add /NOMAIL to not notify user by mail system ; This is needed mostly when doing reruns to repair odd events, ; something that is more common than we would like. ;12* - daw 2/11/81 shrink buffer after LNGFX1 so we don't dump ; too many pages for file. ; Otherwise some files come back with a few extra (garbage) ; pages when they are restored. In particular, any file edited with ; TVEDIT can't be edited with TVEDIT after a refresh!! This is ; essentially the same bug that was present in the EXEC's COPY command. ;13* - daw 3/10/81 show preference for saveset number in headers ; of tape over that in header of logical blocks ; We don't understand why these numbers ever disagree. This ; patch should be regarded as a workaround to allow you to retrieve ; files from archive tapes with inconsistent save set numbers. We ; leave it to DEC to fix the problem that causes this inconsistency. ; Howver even after they do, this patch will still be necessary to ; allow you to retrieve files from old tapes that still have the ; inconsistency. ;14* - daw 3/19/81 IGNORE becomes useful function from old ARCHIVE ; command; ARCHIVE becomes same as SAVE/ARCHIVE ; This is the edit that removes the old archive system. The old ; ARCHIVE command caused save set boundaries to be ignored when ; retrieving (since we stored the tape name but not save set number). ; That function turns out to be useful apart from out old archiver, ; so we have kept it as IGNORE (SAVESET BOUNDARIES). This requires ; only a few lines of code, and has been requested at many DECUS's. ; so DEC should surely install it. ruedit==14 ;local edit number ------- 13-Aug-81 15:20:20-EDT,1087;000000000000 Mail-from: SU-SCORE rcvd at 13-Aug-81 1520-EDT Mail-from: ARPANET site UTAH-20 rcvd at 12-Aug-81 2030-PDT Date: 12 Aug 1981 1832-MDT From: Randy Frank Subject: more on the source issue To: admin.mrc at SU-SCORE Remailed-date: 13 Aug 1981 1215-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.110: ; We were told that there is one supposed additional advantage: namely, that you can elect to skip a release of the source package, and then get the next one, without paying a premium. Previously, if you let your self-maintenance expire, you had to pay a large premium to re-start it at a later time (this applied to both binary and source self-maint). While I admit that no one will want to skip a monitor/exec release, some might want to skip a release on the FE sources (which I believe is half of the $8k). Or alternately, you could take a wait and see attitude to see if you really needed the FE sources, and then order them for a given release only if you needed them. Randy ------- 13-Aug-81 15:53:29-EDT,834;000000000000 Mail-from: SU-SCORE rcvd at 13-Aug-81 1553-EDT Date: 13 Aug 1981 1219-PDT From: Ted Markowitz Subject: Working sets To: admin.mrc Remailed-date: 13 Aug 1981 1246-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.110: ; A question for the list: Do you use working set pre-loading? Why or why why not? My user community just recently changed in that I'm getting swamped with jobs that seem to use large working sets (~350 pages) for extended periods of time. I'm looking for a way to knock down the swapping rate that is starting to balloon tremendously. I have a 10,000 page drum and am now considering moving one pack of my PS: onto a separate channel to ease contention. Any thoughts or useful experience would be much appreciated. --ted ------- 14-Aug-81 04:42:19-EDT,551;000000000000 Mail-from: SU-SCORE rcvd at 14-Aug-81 0442-EDT Date: 14 Aug 1981 0139-PDT From: Mark Crispin Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022 Stanford-Phone: (415) 497-1407 Subject: PAGER.MAC bug - FPD cleared in wrong word To: [SU-SCORE]TOPS-20.DIS.110: ; I believe that the ANDCAM CX,-1(P) at PGUNT0 is wrong and should be replaced with ANDCAM CX,(P). The alleged purpose of this code is to clear FPD (first part done), but -1(P) is the PC location, not the flags word. ------- 14-Aug-81 07:46:44-EDT,0001087;000000000000 Date: 14 Aug 1981 0746-EDT From: HEDRICK Subject: [MILLER at DEC-MARLBORO: Re: Performance improvement for Class-Scheduler] To: TOPS-20 Mail-from: DEC-MARLBORO rcvd at 13-Aug-81 1531-EDT Date: 13 Aug 1981 1532-EDT From: MILLER at DEC-MARLBORO To: HEDRICK at RUTGERS Subject: Re: Performance improvement for Class-Scheduler Message-ID: In-reply-to: Message from HEDRICK at RUTGERS (Mngr DEC-20's/Dir LCSR Comp Facility) of 8-Aug-81 0102-EDT I am responsible for the strategy in question and I know for sure that it will have an ill effect. The reason the scheduler does not absolutely favor interactive jobs is exactly the reason you have stated. Note that interactive jobs suffer only if the class as a whole is being promiscuous. This requires that one or members are being malicous, or the class has not purchased sufficient computes. Either way, the policy decision seems a far better choice than denying others their fair share. -------- --------------- ======== 14-Aug-81 15:11:17-EDT,1492;000000000000 Mail-from: SU-SCORE rcvd at 14-Aug-81 1511-EDT Mail-from: ARPANET site CMU-20C rcvd at 14-Aug-81 0425-PDT Date: 14 Aug 1981 0722-EDT From: WOHL at CMU-20C Subject: Re: PAGER.MAC bug - FPD cleared in wrong word To: Admin.MRC at SU-SCORE In-Reply-To: Your message of 14-Aug-81 0439-EDT Remailed-date: 14 Aug 1981 1201-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.111: ; I submitted an spr to that effect just before leaving for boston. It causes all sorts of problems on a disk full. For example map one page of some file read only (or into a disk full directory) then do a GFUST% giving a byte pointer into the beggining of the page. After a long pause, the string ends up at the begining of the following page! Ofcourse if there are many non-writable pages it hangs the job with the directory locked.. The problem is, what happens to PXCT of a IDPB while NOINT that gets an illref of some sort because the user page can't get created. What is supposed to happen is the IDPB is skipped, that byte is never returned to the user, as soon as you go OKINT you get the PSI. What happens with FPD set wrong is that the IDPB is restarted instead, but since the bytepointer has been incremented, it gets an illref again and so on. Eventualy it stepps of the end of the non-writable pages (given enough time for lots of pages) and deposits the string into the first writable page thereafter. Aaron ------- 15-Aug-81 13:30:20-EDT,632;000000000000 Mail-from: SU-SCORE rcvd at 15-Aug-81 1330-EDT Date: 15 Aug 1981 1025-PDT From: Mark Crispin Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022 Stanford-Phone: (415) 497-1407 Subject: test message To: TOPS-20 at SU-SCORE This is a test of the new TOPS-20@SCORE mailing list. TOPS-20@SCORE forwards to @PS:TOPS-20.DIS, and can be referenced as an ARPANET address. If you have received this message, you are on the TOPS-20 distribution list. Mail for the distribution list can still be sent to me for distribution, or it can be sent directly. -- Mark -- ------- 15-Aug-81 15:58:25-EDT,467;000000000000 Mail-from: SU-SCORE rcvd at 15-Aug-81 1558-EDT Date: 15 Aug 1981 1250-PDT From: Mark Crispin Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022 Stanford-Phone: (415) 497-1407 Subject: bug in answer to SPR 20-15773 To: TOPS-20 at SU-SCORE There is a bug in the answer to SPR 20-15773 (CTCO 555.1). The patch at DSK10A+4 should read SKIPN T3 followed by MOVSI T3,.STDFE (it was published as MOVEI T3,.STDFE). ------- 15-Aug-81 21:34:29-EDT,1739;000000000000 Mail-from: SU-SCORE rcvd at 15-Aug-81 2134-EDT Mail-from: ARPANET site USC-ISIB rcvd at 15-Aug-81 1820-PDT Date: 15 August 1981 18:19-PDT (Saturday) From: Joel Goldberger To: Ted Markowitz Cc: admin.mrc at Score Subject: Working sets Remailed-date: 15 Aug 1981 1830-PDT Remailed-from: Mark Crispin Remailed-to: TOPS-20 at SU-SCORE Date: Thursday, 13 August 1981 12:19-PDT From: Ted Markowitz To: admin.mrc at 1257-PDT Re: Working sets Remailed-date: 13 Aug 1981 1246-PDT Remailed-from: Mark Crispin Remailed-to: [SU-SCORE]TOPS-20.DIS.110: ; A question for the list: Do you use working set pre-loading? Why or why why not? My user community just recently changed in that I'm getting swamped with jobs that seem to use large working sets (~350 pages) for extended periods of time. I'm looking for a way to knock down the swapping rate that is starting to balloon tremendously. I have a 10,000 page drum and am now considering moving one pack of my PS: onto a separate channel to ease contention. Any thoughts or useful experience would be much appreciated. --ted Ted, We tried it a few times at periods of heavy load and while it did seem to reduce swapping rates the effect on load-average was far too adverse to leave it on. The explanation is fairly obvious since more jobs couldn't run since they couldn't get swapped in. Performance was as one might expect, once you got in core it was great, but if you blocked for any reason it was a long time before you ran again. Joel Goldberger 15-Aug-81 21:51:55-EDT,2881;000000000000 Mail-from: SU-SCORE rcvd at 15-Aug-81 2151-EDT Mail-from: ARPANET site USC-ISIB rcvd at 15-Aug-81 1840-PDT Date: 15 August 1981 18:33-PDT (Saturday) From: Joel Goldberger To: HEDRICK at RUTGERS (Mngr DEC-20's/Dir LCSR Comp Facility) Cc: Admin.MRC at SU-SCORE Subject: Performance improvement for Class-Scheduler Remailed-date: 15 Aug 1981 1845-PDT Remailed-from: Mark Crispin Remailed-to: TOPS-20 at SU-SCORE Date: Friday, 7 August 1981 22:02-PDT From: HEDRICK at RUTGERS (Mngr DEC-20's/Dir LCSR Comp Facility) To: JGOLDBERGER at USC-ISIC cc: Admin.MRC at SU-SCORE Re: Performance improvement for Class-Scheduler It is not clear to me that the reported change for Q1 and Q2 is really a bug fix. I can see that some sites might want it that way. However the reason we turned on the class scheduler was that compiles were never getting done. Our interpretation was the "interactive" jobs were taking over the system. Now I am as willing as the next man to give a certain priority to jobs coming out of TI wait. But I would like to restrict this priority to jobs that are "well-behaved". It is quite possible to create interactive tasks that take more than their fair share of the CPU. I want them held in check, to allow the rest of us to get some work done. I believe that the class scheduler as supplied by DEC does this. It may result in spotty response now and then, but my video editor is still usable, and people are getting work done. I would be curious whether you believe that your patch will have ill effects for us. It was our experience that the DEC definition of "good-behavior" was too restricted, and many of us that thought we were behaving pretty well were still getting terrible response. Our situation is somewhat different from yours in that we actually have to enforce allocations of CPU usage among our customers, rather than just having a large user community that all deserve and expect the same level of performance. Because of this restriction we have classes set up rather disproportionately, and it was our observation that the classes with the big allocations were killing the little ones since they rarely ran over their share (misbehaved in DEC's eyes). Since the smaller classes were almost always over their allocation whenever a process in the big class wanted the machine the little guy got thrown to the very end of the line. The changes (which I never advertised as Bug Fixes) made life in the little class atleast bearable. We have also monitored long-range percentages of CPU utilization and haven't seen any real perturbation since making these changes, that is the big classes are still getting most of the machine. Joel Goldberger 17-Aug-81 11:27:36-EDT,524;000000000000 Mail-from: SU-SCORE rcvd at 17-Aug-81 1127-EDT Mail-from: ARPANET site SU-SCORE rcvd at 17-Aug-81 0823-PDT Date: 17 Aug 1981 0823-PDT From: Ted Markowitz Subject: Opinions on Pre-loading To: tops-20 at SU-SCORE The consenus seems to be that there is no consensus! For some folks it's a tremendous boost in performance and for others it's a disaster. The best advice is to try it while monitoring the system's performance and see if you like it. Thanks for the responses. --ted ------- 17-Aug-81 16:34:19-EDT,466;000000000000 Mail-from: SU-SCORE rcvd at 17-Aug-81 1634-EDT Mail-from: ARPANET site CIT-20 rcvd at 17-Aug-81 1329-PDT Date: 17 Aug 1981 1327-PDT From: Barry Megdal Subject: Who's on list To: tops-20 at SU-SCORE Is anyone from Caltech on the TOPS-20 list? (Ours systems people have changed... Lindblad is gone). If he was the only one, you should replace him with me (BARRY@CIT-20). Dick Lang (DICK@CIT-20) should also be on there. Thanks. ------- 17-Aug-81 19:49:37-EDT,1636;000000000000 Mail-from: SU-SCORE rcvd at 17-Aug-81 1949-EDT Date: 17 Aug 1981 1645-PDT From: Mark Crispin Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022 Stanford-Phone: (415) 497-1407 Subject: Administrivia with TOPS-20@SCORE To: BARRY at CIT-20, tops-20 at SU-SCORE In-Reply-To: Your message of 17-Aug-81 1327-PDT Barry, I have updated the TOPS-20 mailing list per your request. Everybody: Please be careful about what you send to TOPS-20@SCORE. Requests for additions and deletions to the mailing list should be sent to me and not to the list. TOPS-20@SCORE was created for the convenience of people who knew their message should go out on the list and wanted to send it "directly". It also saves me the effort of redistributing these messages. Other large lists on the network have been forced to move back to a "moderator" to act as a filter; I hope we're a tight enough community that we don't have to do this. In case anybody wants to see the list of members on the list, it is online at SU-SCORE as PS:TOPS-20.DIS. This file can be FTP'd from SCORE without an FTP login, or by logging in as user ANONYMOUS with any password. I would also like to mention here the existance of a mailing list at MIT-XX, "BUG-TWENEX", which MIT-XX's users report bugs in their system to. At times this mailing list has interesting mail, but it is NOT a safe mailing list to report security bugs to. The MIT systems people normally forward messages of general interest from this list to me to redistribute to TOPS-20@SCORE. -- Mark -- ------- 19-Aug-81 00:09:03-EDT,687;000000000000 Mail-from: SU-SCORE rcvd at 19-Aug-81 0008-EDT Mail-from: ARPANET site RAND-UNIX rcvd at 18-Aug-81 2026-PDT Date: Tuesday, 18 Aug 1981 18:22-PDT To: admin.mrc at SU-SCORE Cc: mike at RAND-UNIX Subject: AN20 for vdh From: mike at RAND-UNIX Remailed-date: 18 Aug 1981 2036-PDT Remailed-from: Mark Crispin Remailed-to: TOPS-20 at SU-SCORE Mark, If you don't know the answer to this offhand, can you forward it to the list? Thanks. What is involved in a) connecting a 20 to a VDH connection on a TIP and b) converting an AN20 local host connection to an AN20 VDH connection? I already know that the VDH is a lose. Thanks, Michael Wahrman 20-Aug-81 16:33:32-EDT,736;000000000000 Mail-from: SU-SCORE rcvd at 20-Aug-81 1633-EDT Mail-from: ARPANET site SU-SCORE rcvd at 20-Aug-81 1325-PDT Date: 20 Aug 1981 1325-PDT From: Patrick Milligan Subject: Archived TOPS-20.Dist mail To: TOPS-20 at SU-SCORE Does anyone keep an archive of TOPS-20.Dist [and Twenex-wizards] mail? I am missing all mail from 6-May-81 to 18-May-81 due to a tape screwup, and I would like to fill in the hole. [Admin.MRC doesn't keep an archive, although he's thinking about it]. If an archive can be found, maybe we can set up a generally available place to keep it... Reply to CSD.Milligan@SU-SCORE. If an archive is set up, I will let everyone know about it... Thanks... -- Patrick ------- 20-Aug-81 23:26:42-EDT,684;000000000000 Mail-from: SU-SCORE rcvd at 20-Aug-81 2326-EDT Mail-from: ARPANET site RUTGERS rcvd at 20-Aug-81 2020-PDT Date: 20 Aug 1981 2106-EDT From: Jonathan Alan Solomon Subject: Re: Archived TOPS-20.Dist mail To: CSD.Milligan at SU-SCORE cc: TOPS-20 at SU-SCORE, JSol at RUTGERS In-Reply-To: Your message of 20-Aug-81 1625-EDT Rutgers has been keeping Archives of all the information on TOPS-20.DIS in a private directory available only to Systems programmers. Mail dating back to 1979 (don't know when in 79) is archived on tape, but the most recent stuff (since 1-jan-1981) are online. I'll send you the stuff from that time in a second. /Jsol ------- 20-Aug-81 23:55:55-EDT,1319;000000000000 Mail-from: SU-SCORE rcvd at 20-Aug-81 2355-EDT Date: 20 Aug 1981 2048-PDT From: Mark Crispin Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022 Stanford-Phone: (415) 497-1407 Subject: patch in NETWRK To: TOPS-20 at SU-SCORE I sent this out as a source level patch a while ago, but a site recently asked me for a DDT version. This patch alleges to avoid IMPMSO BUGINFs; it makes sure there is a valid link set up before doing the link closing code. If you have this patch installed, the symbol LINKF is defined in NETWRK: FLG(LINKF,R,IOS,400000) ; Link table index valid The DDT patch follows: TOPS-20 Command processor 4(560) @ENABLE $GET SYSTEM:MONITR $START 140 DDT NETWRK$: NETCLL 1/ JRST IMPCLL JRST FFF FFF/ 0 TRZE IOS,400000 FFF2+1/ 0 CALL IMPCLL FFF2+2/ 0 MOVEM IOS,NETSTS(UNIT) FFF2+3/ 0 RET FFF2+4/ 0 FFF: NETOPS+2/ RET JRST FFF FFF/ 0 MOVEI IOS,400000 FFF+1/ 0 IORB IOS,NETSTS(UNIT)$> FFF+2/ 0 RET FFF+3/ 0 FFF: DOFSMA+13/ PUSHJ P,@ACTAB(T2) $< FFF/ 0 MOVE IOS,NETSTS(UNIT)$> FFF+1/ 0 PUSHJ P,@ACTAB(T2) FFF+2/ 0 JUMPA T1,DOFSMA+14 FFF+3/ 0 JUMPA T2,DOFSMA+15 DOFSMA+13/ PUSHJ P,@ACTAB(T2) JUMPA FFF2+11 ^Z $SAVE SYSTEM:MONITR.EXE ------- 21-Aug-81 01:32:49-EDT,1157;000000000000 Mail-from: SU-SCORE rcvd at 21-Aug-81 0132-EDT Date: 20 Aug 1981 2224-PDT From: Mark Crispin Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022 Stanford-Phone: (415) 497-1407 Subject: correction to previous message To: TOPS-20 at SU-SCORE There was a minor typographical error in the previous message re: patch to NETWRK. A spurious DDT end patch instruction was listed in the second of the three patches. The corrected patch follows: TOPS-20 Command processor 4(560) @ENABLE $GET SYSTEM:MONITR $START 140 DDT NETWRK$: NETCLL 1/ JRST IMPCLL JRST FFF FFF/ 0 TRZE IOS,400000 FFF2+1/ 0 CALL IMPCLL FFF2+2/ 0 MOVEM IOS,NETSTS(UNIT) FFF2+3/ 0 RET FFF2+4/ 0 FFF: NETOPS+2/ RET JRST FFF FFF/ 0 MOVEI IOS,400000 FFF+1/ 0 IORB IOS,NETSTS(UNIT) FFF+2/ 0 RET FFF+3/ 0 FFF: DOFSMA+13/ PUSHJ P,@ACTAB(T2) $< FFF/ 0 MOVE IOS,NETSTS(UNIT)$> FFF+1/ 0 PUSHJ P,@ACTAB(T2) FFF+2/ 0 JUMPA T1,DOFSMA+14 FFF+3/ 0 JUMPA T2,DOFSMA+15 DOFSMA+13/ PUSHJ P,@ACTAB(T2) JUMPA FFF2+11 ^Z $SAVE SYSTEM:MONITR.EXE ------- 21-Aug-81 19:11:39-EDT,1245;000000000000 Mail-from: SU-SCORE rcvd at 21-Aug-81 1911-EDT Mail-from: ARPANET site SU-SCORE rcvd at 21-Aug-81 1604-PDT Date: 21 Aug 1981 1603-PDT From: Patrick Milligan Subject: Re: Archived TOPS-20.Dis mail To: TOPS-20 at SU-SCORE Thanks to all of you who replied to my request. There were several people who either mailed me the messages, a pointer to an archive, or offered to make the message available. Due to the potentially confidential nature of some of the messages on TOPS-20.Dis (especially those relating to security holes), it is probably not a great idea to have the archives generally available for FTP via an ANONYMOUS login... Perhaps a special FTP login (TOPS-20?) on some host (SU-SCORE?) could be set up, and the password obtained by sending a request to Admin.MRC@SU-SCORE... Any ideas or comments? The most complete set of archived mail that I ran across was via Jonathan Alan Soloman . He has archives on magtape going back to 1979, and has messages since 1-Jan-81 online. If we can setup a reasonably secure archive, we appear to have no problems with "stocking" it with back issues... Thanks again to fellow TOPS-20.Dis packrats... -- Patrick ------- 23-Aug-81 12:26:12-EDT,578;000000000000 Mail-from: SU-SCORE rcvd at 23-Aug-81 1226-EDT Mail-from: ARPANET site RADC-TOPS20 rcvd at 23-Aug-81 0918-PDT Date: 23 Aug 1981 1217-EDT From: Kevin Paetzold To: TOPS-20 at SU-SCORE Reply-to: Paetzold at RADC-TOPS20 Mail-stop: MR1-2/L10 Telephone: 617-467-7430 Subject: newest greatest netsrv Message-ID: is in RADC-TOPS20::PS:NETSRV.MAC.2. Big bug fix and a new feature switch (FT.TIP). You probably do not want ft.tip on. DEC-2136 does however. KWP -------- 24-Aug-81 13:30:11-EDT,537;000000000000 Mail-from: SU-SCORE rcvd at 24-Aug-81 1330-EDT Mail-from: ARPANET site RADC-TOPS20 rcvd at 24-Aug-81 1023-PDT Date: 24 Aug 1981 1322-EDT From: Kevin Paetzold To: TOPS-20 at SU-SCORE Reply-to: Paetzold at RADC-TOPS20 Mail-stop: MR1-2/L10 Telephone: 617-467-7430 Subject: NETSRV Message-ID: For those who dont know or havent figured it out yet. NETSRV now reads initial commands from SYSTEM NETSRV.RUN and not SYSTEM:NETSRV.CMD. -------- 24-Aug-81 14:36:45-EDT,1123;000000000000 Mail-from: SU-SCORE rcvd at 24-Aug-81 1436-EDT Date: 24 Aug 1981 1117-PDT From: Mark Crispin Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022 Stanford-Phone: (415) 497-1407 Subject: What NETSRV is To: TOPS-20 at SU-SCORE Re: Kevin Paetzold's earlier messages to TOPS-20@SCORE about a new version of NETSRV available: For those of you who may not have heard of NETSRV, it is a new program that replaces both NETSER and FTSCTL (the SYSJOB subjobs which handle incoming TELNET and FTP connections). NETSRV is a major change for the better, and I believe it will be part of DEC's Release 5 distribution of TOPS-20AN. Considering all the bugs in NETSER/FTSCTL (including the security bug that a host can crash your SYSJOB by continually leaving half-opened connections which NETSER/FTSCTL never close until job 0 runs out of JFNs), I cannot recomment NETSRV more highly for ARPANET TOPS-20 sites. There are some basic hooks in NETSRV for other networks, and I intend to implement 3mb Ethernet functionality in it shortly. -- Mark -- ------- 25-Aug-81 14:54:55-EDT,331;000000000000 Mail-from: SU-SCORE rcvd at 25-Aug-81 1454-EDT Mail-from: ARPANET site SRI-AI rcvd at 25-Aug-81 1148-PDT Date: 25 Aug 1981 1148-PDT From: ROODE at SRI-AI (David Roode) Subject: MTU tape copy program To: TOPS-20 at SU-SCORE Does anyone have sources to this program? It doesn't do some things I would like it to. ------- 29-Aug-81 00:54:42-EDT,736;000000000000 Mail-from: SU-SCORE rcvd at 29-Aug-81 0054-EDT Mail-from: ARPANET site RUTGERS rcvd at 28-Aug-81 2150-PDT Date: 29 Aug 1981 0049-EDT From: PLEASANT at RUTGERS (Mel Pleasant) Subject: QUASAR documentation To: tops-20 at SU-SCORE Does anyone have some online documentation on the entire QUASAR queueing system? Also, for those of you who have played with it; what pitfalls should I be aware of when creating a new spooled device. Any information would be apreciated. I am willing to put together some type of document that will describe the wheres and hows of playing with the QUASAR system so that others will not have to suffer the fate of modifying it without help....... -Mel ------- 29-Aug-81 13:58:40-EDT,588;000000000000 Mail-from: SU-SCORE rcvd at 29-Aug-81 1358-EDT Mail-from: ARPANET site UTAH-20 rcvd at 29-Aug-81 1053-PDT Date: 29 Aug 1981 1152-MDT From: Randy Frank Subject: Re: QUASAR documentation To: PLEASANT at RUTGERS, tops-20 at SU-SCORE In-Reply-To: Your message of 28-Aug-81 2249-MDT The only documentation of know of is a) the various .unv files - they contain fairly complete descriptions of of the control blocks b) a hard-copy document describing the quasar run time system. I've never seen an on-line version of this document. Randy ------- 29-Aug-81 16:55:13-EDT,569;000000000000 Mail-from: SU-SCORE rcvd at 29-Aug-81 1655-EDT Mail-from: ARPANET site RADC-TOPS20 rcvd at 29-Aug-81 1350-PDT Date: 29 Aug 1981 1645-EDT From: Kevin Paetzold To: PLEASANT at RUTGERS, tops-20 at SU-SCORE Reply-to: Paetzold at RADC-TOPS20 Mail-stop: MR1-2/L10 Telephone: 617-467-7430 Subject: Re: QUASAR documentation Message-ID: In-reply-to: Message from PLEASANT at RUTGERS (Mel Pleasant) of 29-Aug-81 0049-EDT Documentation for GLXLIB exists. -------- 1-Sep-81 13:30:39-EDT,976;000000000000 Mail-from: SU-SCORE rcvd at 1-Sep-81 1330-EDT Mail-from: ARPANET site RADC-TOPS20 rcvd at 1-Sep-81 1020-PDT Date: 1 Sep 1981 1320-EDT From: Mark Pratt To: tops-20 at SCORE Reply-to: Pratt at RADC-TOPS20 Telephone: 315-330-4013 Subject: DEC's SNDMSG Message-ID: DEC's distributed copy of SNDMSG has a bug which may or may not be known to the TOPS-20 distribution list, but here goes anyway. With the new HSTNAM.TXT file, SNDMSG overflows the HSTTAB table but does not tell the user. This can be remedied by changing the NHSTTB value to 4000, however it will still never tell when it overflows. At around SYSGET+17: CAILE C,HSTTAB+NHSTTB ;OVERFLOW TABLE? JRST SYSGTF Can be changed to: CAILE C,HSTTAB+NHSTTB ;OVERFLOW TABLE? JRST [HRROI A,[ASCIZ/ ?SNDMSG's host table overflowed. /] PSOUT HALTF JRST SYSGTF] ;CONTINUE IF THEY WANT TO -------- 1-Sep-81 17:49:46-EDT,746;000000000000 Mail-from: SU-SCORE rcvd at 1-Sep-81 1749-EDT Mail-from: ARPANET site SRI-KL rcvd at 1-Sep-81 1128-PDT Date: 1 Sep 1981 1122-PDT From: LARSON at SRI-KL Subject: re: DEC's SNDMSG To: TOPS-20 at SU-SCORE At the risk of flaming, I am puzzled why people keep ignoring the ESOUT jsys. It will send the CR and LF if needed and the ?. It will also clear the input buffer so there will be no problem with typeahead. Here is Mark's fix (which I highly recommend - failing without a message is bad form), modified to use ESOUT. CAILE C,HSTTAB+NHSTTB ;OVERFLOW TABLE? JRST [HRROI A,[ASCIZ /SNDMSG's host table overflowed. /] ESOUT ;give error message HALTF ; and stop. JRST SYSGTF] ;CONTINUE IF THEY WANT TO ------- 2-Sep-81 08:33:01-EDT,1083;000000000000 Mail-from: SU-SCORE rcvd at 2-Sep-81 0832-EDT Mail-from: ARPANET site SUMEX-AIM rcvd at 28-Aug-81 1618-PDT Date: 28 Aug 1981 1618-PDT From: Gilmurray at SUMEX-AIM Subject: Tops-20 time bugs To: Admin.MRC at SU-SCORE Remailed-date: 2 Sep 1981 0511-PDT Remailed-from: Mark Crispin Remailed-to: TOPS-20 at SU-SCORE Mark, Consider the following times: 0023:00, 0024:00, and 0025:00. IDTIM% can handle the 1st and 3rd OK. However, it gives an TILFX1 error on the 2nd. I don't like that (especially since Tenex allows the 2nd format). The following patches fix this bug(?): ITN7+4/ CAIL => CAILE CKMDT1 1/ GAIGE => CAIG The equivalent bug exists in ODCNV% too and the fix is: ODC2+6/ CAIL => CAILE The issue is whether or not the time can be eactly 1 day. Personally I can go either way on this but, in any case, 0024:00 shouldn't be illegal. The above fixes treat 0024:00 as 24 hours (not minutes). Also, I finallly got the 4 monitor loaded (including the PUP code) and I'll start testing it next week. Frank G. ------- 2-Sep-81 18:39:45-EDT,708;000000000000 Mail-from: SU-SCORE rcvd at 2-Sep-81 1839-EDT Mail-from: ARPANET site UTEXAS-20 rcvd at 2-Sep-81 1533-PDT Date: 2 Sep 1981 1731-CDT From: Clive Dawson Subject: Moving archived files To: tops-20 at SU-SCORE I need to move the contents of a directory from one structure to another. Unfortunately, there are several off-line (archived) files in the directory which COPY complains about. It seems that I'll either have to retrieve all the files in order to move them, or else use DUMPER to save the entire directory and restore it on the other structure. Does anybody know of any easier way to do this which doesn't involve the tape drive? Thanks, Clive ------- 2-Sep-81 19:56:36-EDT,549;000000000000 Mail-from: SU-SCORE rcvd at 2-Sep-81 1956-EDT Mail-from: ARPANET site MIT-XX rcvd at 2-Sep-81 1650-PDT Date: 2 Sep 1981 1950-EDT From: Nat Mishkin Subject: Archive To: tops-20 at SU-SCORE Can anyone explain to me why the archive system has the peculiar property that archive "requests" are marked in the file being archived while retrieve requests are handled by QUASAR? It is incredibly painful to have to sweep the whole file system to determine whether anyone wants any files archived. -- Nat Mishkin ------- 2-Sep-81 20:06:34-EDT,448;000000000000 Mail-from: SU-SCORE rcvd at 2-Sep-81 2006-EDT Mail-from: ARPANET site UTAH-20 rcvd at 2-Sep-81 1701-PDT Date: 2 Sep 1981 1758-MDT From: Randy Frank Subject: Re: Archive To: NWM at MIT-XX, tops-20 at SU-SCORE In-Reply-To: Your message of 2-Sep-81 1750-MDT Everyone (including it seems DEC) seems to agree that this assymetry is stupid. Whether or not anything will ever get done about it is anyone's guess. ------- 3-Sep-81 00:56:05-EDT,644;000000000000 Mail-from: SU-SCORE rcvd at 3-Sep-81 0056-EDT Mail-from: ARPANET site SRI-KL rcvd at 2-Sep-81 2147-PDT Date: 2 Sep 1981 1745-PDT From: ROODE at SRI-KL (David Roode) Subject: Re: Archive To: NWM at MIT-XX, tops-20 at SU-SCORE In-Reply-To: Your message of 2-Sep-81 1650-PDT You have to sweep the filesystem anyway, if you are doing forced migration. Maybe the system was designed with forced migration as an assumption. P.S. Anybody have any handle on what fraction of forced migrations are never retrieved? Anybody have any plans to arrange to have all the directory deadwood pointing to such files cleaned out? ------- 3-Sep-81 01:14:04-EDT,438;000000000000 Mail-from: SU-SCORE rcvd at 3-Sep-81 0114-EDT Mail-from: ARPANET site UTAH-20 rcvd at 2-Sep-81 2207-PDT Date: 2 Sep 1981 2303-MDT From: Randy Frank Subject: Re: Archive To: ROODE at SRI-KL, NWM at MIT-XX, tops-20 at SU-SCORE In-Reply-To: Your message of 2-Sep-81 1845-MDT Yes, but even for forced migration you would only have to sweep the file system ONCE, not twice like the current system does. ------- 4-Sep-81 09:02:37-EDT,484;000000000000 Mail-from: SU-SCORE rcvd at 4-Sep-81 0902-EDT Mail-from: ARPANET site RUTGERS rcvd at 4-Sep-81 0556-PDT Date: 4 Sep 1981 0856-EDT From: Roy Marantz Subject: Connecting Dolphins to the 20 To: tops-20 at SU-SCORE Has anyone had any experience connecting Dolphins tothe 20? I'm about to start doing this soon and would appreciate and info about how you did (or are doing) it. I'm also willing to exchange software with others. Thanks. Roy ------- 4-Sep-81 10:48:31-EDT,2319;000000000000 Mail-from: SU-SCORE rcvd at 4-Sep-81 1048-EDT Mail-from: ARPANET site BBND rcvd at 4-Sep-81 0741-PDT Date: 4 Sep 1981 1041-EDT From: EONEIL at BBND Subject: Moving archived files, archive runs To: TOPS-20 at SU-SCORE cc: EONEIL, DIPACE re:Moving archived files--Clive Dawson @UTEXAS-20 We too have had trouble moving directories across structure boundaries, so I have added a COPY command to DUMPER which runs the SAVE and RESTORE code as coroutines--each page is set up as if to go to tape, only to trigger a context switch, and then go off to the output file as if it had just come off tape. Thus you get a file copy mechanism identical to dumping to tape and restoring from tape, without the physical tape. The modifying commands--SINCE ..., SUPERSEDE...,CREATE, etc. can be used to modify the appropriate side of the operation. For ex., DUMPER>CREATE DUMPER>COPY PS: FS: will create FS: and all its subdirectories and copy all the files in these directories, preserving archive data, access dates, invisibility status, etc. "All the files" means, of course, all files DUMPER would dump, and omits temporary, deleted, and no-dump files. It would also use DUMPER's obnoxious SUPER OLDER default and refuse to copy an older-but-higher-version file. To get around this, you can use our SUPER UNLESS command which allows any file restored unless there is a file of that exact filespec already on disk. The CREATE command has had much-needed work as well. I can supply the binary version of this DUMPER--the sources are considered proprietary. re:Nat Mishkin's question about the inefficiency of archive runs Jim Calvin and I designed and implemented the archive system here at BBN, so we are responsible for this situation. My figures show it costs about .6 KLsec/1000 files on the structure to do the 4 scans necessary for a full archive run (2 tape copies of each file), or about 30KLsecs for a "typical" 50,000 file-600Mbyte file system. Our idea was to offload as much computation, such as queue management, from first shift onto second or third shift, when our machines are more or less idle--we considered this "free" computer time. Obviously if your machines are running day and night this assumption is no good.--Betty O'Neil ------- 4-Sep-81 10:58:53-EDT,1462;000000000000 Mail-from: SU-SCORE rcvd at 4-Sep-81 1058-EDT Mail-from: ARPANET site SUMEX-AIM rcvd at 4-Sep-81 0746-PDT Date: 4 Sep 1981 0743-PDT From: Rindfleisch at SUMEX-AIM Subject: Re: Connecting Dolphins to the 20 To: MARANTZ at RUTGERS, tops-20 at SU-SCORE In response to the message sent 4 Sep 1981 0856-EDT from MARANTZ@RUTGERS Roy, The Dolphins use the PUP protocol on the 3 Mbit/sec Ethernet. They also connect to the 10 Mbit/sec Xerox Ethernet but the specs for that have not been released and we are not using it. We have our 2020 on the Ethernet and the Dolphins can communicate with it. Thus, TOPS-20 is not a problem. As far as hardware connections, we can get away with a UNIBUS interface for the 2020. For 2040-2060's, there are two approaches being pursued: 1) Ralph Gorin and company are debugging a massbus interface for the SCORE 2060. This should be working soon and I'm sure can be made available to others. However, this is not DEC-supported hardware. 2) RAND (Chris Ryland) and possibly CMU (Aaron Wohl) are looking into a DTE connection. I'm not sure what the state of this is. A final hassle for now is when Xerox will release the 10/20 PUP software so we can share the code with you and others who have asked. This has been months coming, with frequent promises that the release is just about to be finalized. I just don't know when that act will get together. Tom R. ------- 4-Sep-81 14:17:43-EDT,390;000000000000 Mail-from: SU-SCORE rcvd at 4-Sep-81 1417-EDT Mail-from: ARPANET site BBND rcvd at 4-Sep-81 1113-PDT Date: 4 Sep 1981 1412-EDT From: EONEIL at BBND Subject: Corr. to Archive run stats To: TOPS-20 at SU-SCORE cc: EONEIL Change "KLsecs" to "KLmins" in my previous message, i.e., it should be .6 KLmin/1000 files, or 30KLmin for a "typical" large filesystem. --Betty ------- 4-Sep-81 17:15:50-EDT,1082;000000000000 Mail-from: SU-SCORE rcvd at 4-Sep-81 1715-EDT Mail-from: ARPANET site SUMEX-AIM rcvd at 4-Sep-81 1410-PDT Date: 4 Sep 1981 1409-PDT From: Rindfleisch at SUMEX-AIM Subject: Re: Connecting Dolphins to the 20 To: MARANTZ at RUTGERS, tops-20 at SU-SCORE cc: RINDFLEISCH at SUMEX-AIM In response to the message sent 4 Sep 1981 1310-EDT from MARANTZ@RUTGERS I guess I don't understand what the interface protocol between the front end and the 20 will be for terminals, file xfers, etc. Are you planning to use existing DECnet or NCP code in TOPS-20 and convert to/from PUP's at the front end? You stand to have to rewrite much of the user level code that exists for various kinds of Ethernet servers (PUPSRV, CHAT, PUPFTP, XMAILR, etc.). There has been some work on Ethernet/ARPAnet gateways at PARC but I don't know how complete or available that stuff is. I personally would not spend much time writing new PUP code since the durability of that protocol is questionable. Seems easier to adopt (soon to be) available TOPS-20 hacks... Tom R. ------- 4-Sep-81 19:33:49-EDT,1635;000000000000 Mail-from: SU-SCORE rcvd at 4-Sep-81 1933-EDT Date: 4 Sep 1981 1625-PDT From: Mark Crispin Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022 Stanford-Phone: (415) 497-1407 Subject: New format for TOPS-20 distribution list To: TOPS-20 at SU-SCORE Folks - Effective immediately, an archive has been established at SCORE for the TOPS-20 distribution list messages. This directory is at SCORE. Due to the sensitive nature of some of the messages which have gone out on the list, the directory is protected; however anybody with a "guest system programmer" account (user group 1) at SCORE has access to the directory. All messages starting with this one will be logged in this directory as PS:TOPS-20.MESSAGES; anybody with access to the directory can read this file. In addition, the famous TOPS-20.DIS file which contains the membership list for this list has moved to as well. Unlike all the other files on this directory, it allows read access to the world. I am expecting to have the past messages which have been distributed to the list on in a couple of days. also contains some other files which I have moved over from my "notes" directory. I haven't gone through all of it yet (some of it is complete trash), and there may be some duplication with messages on the list; but I hope to eventually have a true archive of TOPS-20 folklore here. Yours in maintaining our favorite operating system, -- Mark -- ------- 5-Sep-81 04:20:45-EDT,676;000000000000 Mail-from: SU-SCORE rcvd at 5-Sep-81 0420-EDT Mail-from: ARPANET site RAND-AI rcvd at 5-Sep-81 0115-PDT Date: 4 Sep 1981 2203-PDT Sender: GEOFFM at RAND-AI Subject: Re: New format for TOPS-20 distribution list From: Geoffrey C. Mulligan (AFDSC, The Pentagon) To: Admin.MRC at SU-SCORE Cc: TOPS-20 at SU-SCORE Message-ID: <[RAND-AI] 4-Sep-81 22:03:45.GEOFFM> In-Reply-To: Your message of 4 Sep 1981 1625-PDT Mark, If you need help putting the archive together I would be glad to volunteer some time. How are you able to put so much time into this? I thought that married person had to devote time to their spouses! geoff 5-Sep-81 18:42:51-EDT,1377;000000000000 Mail-from: SU-SCORE rcvd at 5-Sep-81 1842-EDT Mail-from: ARPANET site SRI-KL rcvd at 5-Sep-81 1538-PDT Date: 5 Sep 1981 1536-PDT From: Chris Ryland Subject: Re: Connecting Dolphins to the 20 To: Rindfleisch at SUMEX-AIM, MARANTZ at RUTGERS, tops-20 at SU-SCORE In-Reply-To: Your message of 4-Sep-81 1409-PDT Yes, I agree wholeheartedly with Tom about using existing protocols. The EOS folks promise in all directions that they'll free up the PARC TENEX PUP support so that we can use SUMEX's excellent TOPS-20 adaptation. Using a front-end -11 on the -20 to interface to the Ethernet is rather painless. In particular, I've just made some minor changes to DTESRV which allow a front-end -11 to come up with no previous arrangement on the -20 (unlike the current DN20 support). This allows you to write packet forwarders for nearly any network with little pain (we will soon have one at Fairchild for the Chaosnet and Ethernet.) The hardware is dirt cheap using this approach, since you don't have to buy all those special boot hardware components: viz., for the cost of a used 11/34 (around $7K), plus the bare DTE boards ($3K exactly), you have a network front-end. Anyone want to network up to 4 -20's together with the Chaosnet? It'd only cost you $7K plus $3K per -20, and the Chaosnet software is free from MIT. ------- 8-Sep-81 11:06:50-EDT,754;000000000000 Mail-from: SU-SCORE rcvd at 8-Sep-81 1106-EDT Mail-from: ARPANET site RUTGERS rcvd at 8-Sep-81 0758-PDT Date: 8 Sep 1981 1056-EDT From: Roy Marantz Subject: Re: Connecting Dolphins to the 20 To: RYLAND at SRI-KL, Rindfleisch at SUMEX-AIM, tops-20 at SU-SCORE In-Reply-To: Your message of 5-Sep-81 1836-EDT Chris, Wouyld you send me (or point to where I can find) the info about what hardware is needed on the 11/34 to support interconnection with the 20? Also if you don't get the hardware to allow "remote" booting (via a 20 or something) how can you get the FE to reload itself without operator intervention? What is the hardware needed for the "remote" bootstrap capability by the way? Thanks. Roy ------- 8-Sep-81 12:44:20-EDT,628;000000000000 Mail-from: SU-SCORE rcvd at 8-Sep-81 1244-EDT Mail-from: ARPANET site SRI-KL rcvd at 8-Sep-81 0936-PDT Date: 8 Sep 1981 0934-PDT From: Chris Ryland Subject: Re: Connecting Dolphins to the 20 To: MARANTZ at RUTGERS, Rindfleisch at SUMEX-AIM, tops-20 at SU-SCORE In-Reply-To: Your message of 8-Sep-81 0756-PDT Sorry, my last message was chopped off by Score's mailer, from what I can see. I will send a note about this scheme to build ultra-cheap front-ends and the software needed to support it, as soon as I finish our Chaosnet installation here (which is the proof of the pudding.) ------- 8-Sep-81 12:53:43-EDT,325;000000000000 Mail-from: SU-SCORE rcvd at 8-Sep-81 1253-EDT Mail-from: ARPANET site RAND-UNIX rcvd at 8-Sep-81 0949-PDT Date: Tuesday, 8 Sep 1981 09:37-PDT To: tops-20 at SU-SCORE Subject: 2060 MIP rating? From: mike at RAND-UNIX Can anyone tell me how many MIPs (Million Instructions per Second) a 2060 is? Thanks, Michael 8-Sep-81 13:19:08-EDT,523;000000000000 Mail-from: SU-SCORE rcvd at 8-Sep-81 1319-EDT Mail-from: ARPANET site SUMEX-AIM rcvd at 8-Sep-81 1014-PDT Date: 8 Sep 1981 1011-PDT From: Rindfleisch at SUMEX-AIM Subject: Re: 2060 MIP rating? To: mike at RAND-UNIX, tops-20 at SU-SCORE In response to the message sent Tuesday, 8 Sep 1981 09:37-PDT from mike@RAND-UNIX I did a simple-minded test some time ago under time-sharing to check out an instruction mix typical of monitor coding and got a value for the SCORE 2060 of 1.23 MIPS. Tom R. ------- 8-Sep-81 13:31:20-EDT,518;000000000000 Mail-from: SU-SCORE rcvd at 8-Sep-81 1331-EDT Mail-from: ARPANET site SRI-KL rcvd at 8-Sep-81 1028-PDT Date: 8 Sep 1981 1019-PDT From: Chris Ryland Subject: Re: 2060 MIP rating? To: mike at RAND-UNIX, tops-20 at SU-SCORE In-Reply-To: Your message of 8-Sep-81 0955-PDT Whew, that's a toughie, but the "standard" figure we used at MIT was about 2MIP. (JM@MC is the source of this figure.) Thus, the Jupiter, which is supposedly 3-5x faster than a KL10E, will be about 6-10MIP. ------- 8-Sep-81 17:23:47-EDT,462;000000000000 Mail-from: SU-SCORE rcvd at 8-Sep-81 1723-EDT Mail-from: ARPANET site RUTGERS rcvd at 8-Sep-81 1417-PDT Date: 8 Sep 1981 1708-EDT From: Roy Marantz Subject: Re: Connecting Dolphins to the 20 To: RYLAND at SRI-KL, Rindfleisch at SUMEX-AIM, tops-20 at SU-SCORE In-Reply-To: Your message of 8-Sep-81 1234-EDT Thanks. Can you point me at Chaosnet documentation also? I'd like a protocol description. Thanks again. Roy ------- 9-Sep-81 13:09:41-EDT,448;000000000000 Mail-from: SU-SCORE rcvd at 9-Sep-81 1309-EDT Mail-from: ARPANET site SU-SCORE rcvd at 9-Sep-81 1005-PDT Date: 9 Sep 1981 1004-PDT From: Ted Markowitz Subject: Re: 2060 MIP rating? To: tops-20 at SU-SCORE In-Reply-To: Your message of 8-Sep-81 1019-PDT I've been a little out of touch with what's happening on the Jupiter development. Anyone have any details on what it currently looks like, etc.? --ted ------- 11-Sep-81 02:15:41-EDT,3894;000000000000 Mail-from: SU-SCORE rcvd at 11-Sep-81 0215-EDT Mail-from: ARPANET site RUTGERS rcvd at 10-Sep-81 2310-PDT Date: 11 Sep 1981 0209-EDT From: WATROUS at RUTGERS (Don Watrous) Subject: Speeding up archiving To: TOPS-20 at SU-SCORE ARCF calls UPDDIR to update the directory during each jsys call, even if it is a read-only function. This is incredibly costly for both REAPER and DUMPER who gather the tape information of files with ARCF. Skipping the call to UPDDIR for the read-only function speads up both these programs tremendously. (I've just reaped and archived to two tapes a three pack PS: in less than 50 minutes!) To speed things up even further, I've modified ARCF to set a bit in ARCHIVE-REQUESTS.BIN (like MAILER.FLAGS) whenever an archive or a migration is requested. The monitor code is working, but I haven't written the DUMPER support yet. I'll pass along the DUMPER code when that's finished. Both patches are included in the FILCOM below. Lines concerning UPDDIR avoidance are commented with [a], while those for setting the bit in ARCHIVE-REQUESTS.BIN are commented [b]. Don File 1) JSYSF.MAC.19,10-Sep-81 09:45:58 File 2) JSYSF.MAC.15, 8-Jul-81 03:15:02 1) stkvar ;[b,a] 1) HRRZ JFN,T1 ; Copy JFN **** 2)5 HRRZ JFN,T1 ; Copy JFN ************** 1)5 setzm arcflg ;[b] assume not archive request 1) caie t1,.arrar ;[b] requesting archive 1) cain t1,.arriv ;[b] or migrate? 1) hrrzm q3,arcflg ;[b] yes, save set/clear 1) arc1: ;[b] 1) setzm roflg ;[a] assume not read-only function 1) cain t1,.argst ;[a] only read-only function? 1) setom roflg ;[a] this is it 1) CALL @ARCFF(T1) ; Do it 1) JRST ARCFX ; Failed for some reason 1) skipn roflg ;[a] if not read-only function 1) CALL UPDDIR ; Update directory **** 2)5 CALL @ARCFF(T1) ; Do it 2) JRST ARCFX ; Failed for some reason 2) CALL UPDDIR ; Update directory ************** 1)5 skipe arcflg ;[b] if setting archive/migrate 1) call flagit ;[b] flag archive request 1) MRETNG ; Done **** 2)5 MRETNG ; Done ************** 1)6 ;[b] routine to set bit in ARCHIVE-REQUESTS.BIN for this directory 1) flagit: stkvar > ;[b] 1) xctu [ move t1,1] ;[b] get jfn 1) movem t1,filjfn ;[b] 1) hrroi t1,flgtmp ;[b] get structure string for archive request 1) move t2,filjfn ;[b] 1) movx t3,fld(.jsaof,js%dev)!js%paf ;[b] 1) jfns ;[b] 1) erjmp r ;[b] 1) hrroi t2,[asciz \archive-requests.bin\] ;[b] 1) setzb t3,t4 ;[b] create name for binary file there 1) sout ;[b] 1) movx t1,gj%old!gj%sht ;[b] get jfn on binary file 1) hrroi t2,flgtmp ;[b] 1) noint ;[b] stop interrupts now 1) gtjfn ;[b] 1) erjmp flagi3 ;[b] 1) movem t1,flgjfn ;[b] 1) movx t2,fld(1,of%bsz)!of%rd!of%wr!of%thw ;[b] open file 1) openf ;[b] 1) erjmp flagi2 ;[b] 1) hrroi t1,flgtmp ;[b] get directory string of archive request 1) move t2,filjfn ;[b] 1) movx t3,fld(.jsaof,js%dev)!fld(.jsaof,js%dir)!js%paf ;[b] 1) jfns ;[b] 1) erjmp flagi1 ;[b] 1) movx t1,rc%emo ;[b] get that directory number 1) hrroi t2,flgtmp ;[b] 1) rcdir ;[b] 1) erjmp flagi1 ;[b] 1) txne t1,rc%nom ;[b] 1) jrst flagi1 ;[b] 1) hrrz t2,t3 ;[b] position there in binary file 1) move t1,flgjfn ;[b] 1) sfptr ;[b] 1) erjmp flagi1 ;[b] 1) seto t2, ;[b] mark that directory number 1) bout ;[b] 1) erjmp flagi1 ;[b] 1) flagi1: move t1,flgjfn ;[b] close the file 1) closf ;[b] 1) erjmp flagi2 ;[b] 1) jrst flagi3 ;[b] 1) flagi2: move t1,flgjfn ;[b] toss the jfn 1) rljfn ;[b] 1) erjmp flagi3 ;[b] 1) flagi3: okint ;[b] 1) ret ;[b] 1)7 ; Involuntary migration; File exempt from migration **** 2)7 ; Involuntary migration; File exempt from migration ************** ------- 11-Sep-81 21:53:36-EDT,361;000000000000 Mail-from: SU-SCORE rcvd at 11-Sep-81 2153-EDT Mail-from: ARPANET site SRI-KL rcvd at 11-Sep-81 1849-PDT Date: 11 Sep 1981 1837-PDT From: ROODE at SRI-KL (David Roode) Subject: MIP ratings To: tops-20 at SU-SCORE How about MIP ratings for 20's without cache, VAX-11/750's and VAX-11/780's, PDP-11/70's, /44's, /23's, and IBM 370 compatibles? ------- 12-Sep-81 19:16:55-EDT,836;000000000000 Mail-from: SU-SCORE rcvd at 12-Sep-81 1916-EDT Mail-from: ARPANET site MIT-XX rcvd at 12-Sep-81 1611-PDT Date: 12 Sep 1981 1910-EDT From: Nat Mishkin Subject: BAT blocks To: tops-20 at SU-SCORE Does anyone know an easy way of forcing particular disk sectors into the BAT block table? I just image copied (pack to pack) a disk pack and in the process I overwrote the destination pack's BAT block. I knew I was going to do this so I isolated the files I knew would map onto bad blocks on the new pack. I figured a couple of references to these files would elicit enough disk errors for the monitor to mark the files' blocks as bad in the new BAT block. Unfortunately, it didn't and now I can't delete these files without returning bad blocks to the free pool. Any ideas? -- Nat Mishkin ------- 12-Sep-81 22:44:51-EDT,771;000000000001 Mail-from: SU-SCORE rcvd at 12-Sep-81 2244-EDT Mail-from: ARPANET site SRI-KL rcvd at 12-Sep-81 1939-PDT Date: 12 Sep 1981 1939-PDT From: Chris Ryland Subject: DTE hardware/software caveat To: Tops-20 at SU-SCORE I found out the hard way that (a) sending a packet via the MCB protocol (and, I presume, the RSX20F protocol) which isn't an even number of words or (b) sending a packet which doesn't start on an even-word (4-byte) boundary will cause the KL to die horribly (the clock even stops.) This is on a secondary front-end's DTE, not a privileged DTE. Could be randomness in DTESRV, but I doubt it. Nothing of this sort was warned about in the DTE hardware manual (field circus fiche version). Anybody have any ideas? ------- 13-Sep-81 01:31:49-EDT,535;000000000000 Mail-from: SU-SCORE rcvd at 13-Sep-81 0131-EDT Mail-from: ARPANET site UTAH-20 rcvd at 12-Sep-81 2226-PDT Date: 12 Sep 1981 2324-MDT From: Randy Frank Subject: Re: BAT blocks To: NWM at MIT-XX, tops-20 at SU-SCORE In-Reply-To: Your message of 12-Sep-81 1710-MDT I have a program from DEC call BATUPD that is used form manipulating BAT blocks. You can anonymous ftp them from [utah-20]batupd.*. They normally don't reside their, so if anyone wants them, get them within a week. Randy ------- 13-Sep-81 23:18:07-EDT,690;000000000000 Mail-from: SU-SCORE rcvd at 13-Sep-81 2318-EDT Mail-from: ARPANET site UTAH-20 rcvd at 13-Sep-81 2015-PDT Date: 13 Sep 1981 2115-MDT From: Randy Frank Subject: Re: Speeding up archiving To: WATROUS at RUTGERS, TOPS-20 at SU-SCORE In-Reply-To: Your message of 11-Sep-81 0009-MDT I'd like to add my vote to this obvious (why didn't I think of it...) solution to speeding up archiving (i.e., a file similar to the mailer flags file). If anyone from DEC is out their listening, I think that this scheme should DEFINITELY be adopted, and it is a simple, elegant, and easy to implement solution to the archiving overhead problem. Cudos to Watrous!!! ------- 14-Sep-81 10:27:18-EDT,581;000000000010 Mail-from: SU-SCORE rcvd at 14-Sep-81 1027-EDT Mail-from: ARPANET site RADC-TOPS20 rcvd at 14-Sep-81 0722-PDT Date: 14 Sep 1981 1021-EDT From: Mark Pratt To: TOPS-20 at SCORE Reply-to: Pratt at RADC-TOPS20 Telephone: 315-330-4013 Subject: VAX on Arpa Message-ID: Can anyone tell me if Vax's have been interfaced to Arpa, and if so, can you briefly tell me how it was done. I notice there are a couple of Vax's out there and they are labeled as UNIX. Thanks Mark Pratt -------- 14-Sep-81 12:36:17-EDT,434;000000000000 Mail-from: SU-SCORE rcvd at 14-Sep-81 1236-EDT Mail-from: ARPANET site SRI-KL rcvd at 14-Sep-81 0933-PDT Date: 14 Sep 1981 0930-PDT From: Richard R. Cower Subject: Re: VAX on Arpa To: Pratt at RADC-TOPS20, TOPS-20 at SU-SCORE cc: COWER at SRI-KL In-Reply-To: Your message of 14-Sep-81 0721-PDT Contact David Kashtan. I think he is getting mail at sri-ai (if not..it will be forwarded). ..rich ------- 14-Sep-81 15:35:41-EDT,480;000000000000 Mail-from: SU-SCORE rcvd at 14-Sep-81 1535-EDT Mail-from: ARPANET site RUTGERS rcvd at 14-Sep-81 1231-PDT Date: 14 Sep 1981 1335-EDT Sender: AWALKER at RUTGERS From: Jonathan Alan Solomon Subject: Re: VAX on Arpa To: Pratt at RADC-TOPS20 cc: TOPS-20 at SU-SCORE In-Reply-To: Your message of 14-Sep-81 1021-EDT There's a VAX running VMS (it's a testbed for EUNICE), on SRI-IU. Contact Dave for more information. /JSol ------- 14-Sep-81 15:59:37-EDT,677;000000000000 Mail-from: SU-SCORE rcvd at 14-Sep-81 1559-EDT Mail-from: ARPANET site RADC-TOPS20 rcvd at 14-Sep-81 1255-PDT Date: 14 Sep 1981 1548-EDT From: Mark Pratt To: tops-20 at SCORE Reply-to: Pratt at RADC-TOPS20 Telephone: 315-330-4013 Subject: Vax and Arpa Message-ID: I'd like to thank everyone for all the responses I have gotten regarding Vax's on the network. I now know what I needed to, and if anyone is interested, I will redistribute those messages to anyone that would like them, as long as the original senders have no objections. Again, thanks. Mark  -------- 14-Sep-81 19:59:24-EDT,600;000000000000 Mail-from: SU-SCORE rcvd at 14-Sep-81 1959-EDT Mail-from: ARPANET site RUTGERS rcvd at 14-Sep-81 1652-PDT Date: 14 Sep 1981 1831-EDT From: Jonathan Alan Solomon Subject: Debugging aid needed. To: TOPS-20 at SU-SCORE I'm looking for a method of trapping on the modification of a location in memory. Does anyone know of a program that breaks (into DDT) when some location is referenced? Does an Address Break do what I want? I will settle for some indication of where in my program the word is being modified. Also it should be continuable. Thanks, JSol ------- 14-Sep-81 23:39:21-EDT,653;000000000000 Mail-from: SU-SCORE rcvd at 14-Sep-81 2339-EDT Mail-from: ARPANET site SRI-CSL rcvd at 14-Sep-81 2031-PDT Date: 14 Sep 1981 2029-PDT Sender: GEOFF at SRI-CSL Subject: Re: VAX on Arpa From: the tty of Geoffrey S. Goodfellow Reply-To: Geoff at SRI-CSL To: Pratt at RADC-TOPS20 Cc: TOPS-20 at SCORE Message-ID: <[SRI-CSL]14-Sep-81 20:29:17.GEOFF> In-Reply-To: There are two VMS NCP implementations that I know exist. One is by Dave Kashtan of SRi-AI (Kashtan@SRI-IU), the other is by DTI. You might try contacting Jody Kravitz (kravitz@dti) for information on the DTI implementation. 16-Sep-81 02:00:34-EDT,856;000000000000 Mail-from: SU-SCORE rcvd at 16-Sep-81 0200-EDT Mail-from: ARPANET site RUTGERS rcvd at 15-Sep-81 2255-PDT Date: 16 Sep 1981 0156-EDT From: Jonathan Alan Solomon Subject: Bug in the exec To: TOPS-20 at SU-SCORE Try this on your default EXEC: @DEASSIGN (DEVICE) FOO? ^asking for help bombs out with the error: ?Invalid help string pointer What happens is that the macro that parses the device doesn't have the string. This is at DEAS1: in EXECMT.MAC DEAS1: DEVX ;NOT "DEASSIGN *", CHECK FOR REAL DEVICE CMERRX ;NOT THAT EITHER! Should be DEAS1: DEVX ;NOT "DEASSIGN *", CHECK FOR REAL DEVICE CMERRX ;NOT THAT EITHER! This actually could be considered a bug in DEVX, but I discovered it was trivial to fix in the exec hence this change. Cheers, JSol ------- 16-Sep-81 10:11:32-EDT,889;000000000000 Mail-from: SU-SCORE rcvd at 16-Sep-81 1011-EDT Mail-from: ARPANET site DEC-MARLBORO rcvd at 16-Sep-81 0702-PDT Date: 16 Sep 1981 1000-EDT From: Larry Campbell To: JSol at RUTGERS, TOPS-20 at SU-SCORE Subject: Re: Debugging aid needed. Message-ID: <"MS5(1734)+GLXLIB1(1033)" 11760719332.16.71.15809 at DEC-MARLBORO> In-reply-to: Message from Jonathan Alan Solomon of 14-Sep-81 1831-EDT If you SET ADDRESS-BREAK, your fork will be terminated when it tries the watched-for reference. You can continue it, or run DDT (but to continue from DDT you do $G, not $P, and must first turn off the break or increment the repeat count or it will just break again). You can break after certain flavors of references, or after n references, with subcommands to SET ADDRESS-BREAK. -------- 16-Sep-81 16:44:03-EDT,421;000000000000 Mail-from: SU-SCORE rcvd at 16-Sep-81 1643-EDT Mail-from: ARPANET site MIT-XX rcvd at 16-Sep-81 1303-PDT Date: 16 Sep 1981 1603-EDT From: Steve Berlin Subject: Release 5 To: tops-20 at SU-SCORE Is there any recent info about release 5? Any good guesses about when it will be released? When it goes into field-test? Also, is PCL planned to be included? Thanks... -- Steve ------- 16-Sep-81 21:28:04-EDT,871;000000000000 Mail-from: SU-SCORE rcvd at 16-Sep-81 2128-EDT Mail-from: ARPANET site MIT-XX rcvd at 16-Sep-81 1821-PDT Date: 16 Sep 1981 2122-EDT From: Nat Mishkin Subject: MTOPR Documentation Error To: tops-20 at SU-SCORE Just in case anyone finds a need to use the MTOPR .MOTPS ("assign interrupt channels for non-controlling terminal") feature...the documentation in the Monitor Calls Reference Manual is completely wrong. A quick perusal of the monitor source (you know things must be getting bad when this is the 1st place you look when something doesn't seem to work as advertised) turns up the fact that the format is AC3 pointing to a block whose 1st word contains 2, and whose 2nd word contains (output channel#,,input channel#). The manual says AC3 is supposed to contain (input channel#,,output channel#). -- Nat Mishkin ------- 17-Sep-81 13:01:26-EDT,48;000000000000 Mail-from: SU-SCORE rcvd at 17-Sep-81 1301-EDT 17-Sep-81 13:31:28-EDT,820;000000000000 Mail-from: SU-SCORE rcvd at 17-Sep-81 1331-EDT Mail-from: ARPANET site UTAH-20 rcvd at 17-Sep-81 1024-PDT Date: 17 Sep 1981 1122-MDT From: Randy Frank Subject: Investment opportunities To: tops-20 at SU-SCORE I have a great investment opportunity: better than the stock market, gold, real estate, bonds... Try DECSystem 20 Reference manuals: if you've tried to buy any manuals lately you know what I mean. $46 for the Hardware Reference manual, and Monitor Calls Reference manual, $30 for the Edit reference manual and Fortran, etc. It's obscene. Even with DEC's policy of "allowing" you to re-print manuals for a 25% royalty, the manual prices are ridiculous. Two years ago when everyone complained, the manual prices were bad; now they've gone into orbit. Randy ------- 17-Sep-81 13:45:47-EDT,402;000000000000 Mail-from: SU-SCORE rcvd at 17-Sep-81 1345-EDT Mail-from: ARPANET site SRI-KL rcvd at 17-Sep-81 1038-PDT Date: 17 Sep 1981 1034-PDT From: Richard R. Cower Subject: Re: Investment opportunities To: FRANK at UTAH-20, tops-20 at SU-SCORE cc: COWER at SRI-KL In-Reply-To: Your message of 17-Sep-81 1022-PDT Does a futures market exist? Can we buy on margin? ..rich ------- 17-Sep-81 17:47:05-EDT,772;000000000000 Mail-from: SU-SCORE rcvd at 17-Sep-81 1746-EDT Mail-from: ARPANET site SRI-KL rcvd at 17-Sep-81 1441-PDT Date: 17 Sep 1981 1415-PDT From: Chris Ryland Subject: Re: Release 5 To: FRANK at UTAH-20, BERLIN at MIT-XX, tops-20 at SU-SCORE In-Reply-To: Your message of 17-Sep-81 0950-PDT I've been talking with DEC about field-test and R5 release, and here's the story: they plan to start field-testing in about a month, with final release vaguely aimed at 4-6 months later. The story with PCL is that all the hooks will be in the standard DEC EXEC, and you'll receive enough .REL files to link in PCL as a non-source site. This is a step up from the MFEXEC policy, which was basically that it was unavailable to non-source sites. ------- 17-Sep-81 18:57:07-EDT,1051;000000000000 Mail-from: SU-SCORE rcvd at 17-Sep-81 1857-EDT Mail-from: ARPANET site SRI-KL rcvd at 17-Sep-81 1550-PDT Date: 17 Sep 1981 1546-PDT From: ROODE at SRI-KL (David Roode) Subject: Re: Investment opportunities To: FRANK at UTAH-20, tops-20 at SU-SCORE In-Reply-To: Your message of 17-Sep-81 1022-PDT A couple of thoughts... one reason for their high prices is that you can order a single manual over the phone charging it to Master Charge or Visa. This type of onsies and twosies has got to cost them money. The other reason is that they insist on pricing the manuals to recover the complete cost of producing the manual--in the case of many manuals, some of this cost should be considered for recovery under other methods--for example, it behooves them to keep track of what the monitor calls do even if they are not going to produce a reference document on that matter. Finally, when the manual is prices at $46, I wonder how many people resist the temptation of the local double sided auto collating Xerox machine? ------- 18-Sep-81 03:36:40-EDT,1177;000000000000 Mail-from: SU-SCORE rcvd at 18-Sep-81 0336-EDT Mail-from: ARPANET site RUTGERS rcvd at 18-Sep-81 0028-PDT Date: 18 Sep 1981 0321-EDT From: HEDRICK at RUTGERS (Mngr DEC-20's/Dir LCSR Comp Facility) Subject: Re: Investment opportunities To: FRANK at UTAH-20 cc: tops-20 at SU-SCORE In-Reply-To: Your message of 17-Sep-81 1322-EDT This is why we do our own local documentation. As far as I know, no one buys any DEC manuals here, except a few copies of the JSYS manual. I hadn't seen the $46 price, though. That may stop what little sales there is. I agree that there is no possible way we can ask students to pay $46 for a manual. Would it be legal for each university to take responsibility for reprinting one manual, thus getting volumes high enough that we could do a reasonable job? Actually, the best thing for everyone would be for us to subcontract to DEC to do our printing for us. This would keep their volume up, and help keep the costs down for the rest of the customers. I would certainly be happy to arrange for printing of one of the manuals here if it looked like the volume was going to be enough to make it cost-effective. ------- 18-Sep-81 15:31:28-EDT,367;000000000000 Mail-from: SU-SCORE rcvd at 18-Sep-81 1531-EDT Mail-from: ARPANET site SANDIA rcvd at 18-Sep-81 1225-PDT Date: 18 Sep 1981 1325-MDT From: Norm Samuelson Subject: MAINSAIL To: tops-20 at SU-SCORE I have a user who is interested in MAINSAIL. Can anybody tell me who has it and under what conditions it is available? - Sam - ------- 18-Sep-81 16:24:37-EDT,425;000000000000 Mail-from: SU-SCORE rcvd at 18-Sep-81 1624-EDT Mail-from: ARPANET site SUMEX-AIM rcvd at 18-Sep-81 1317-PDT Date: 18 Sep 1981 1314-PDT From: Eric Schoen Subject: Re: MAINSAIL To: tops-20 at SU-SCORE MAINSAIL is available through XIDAK, Inc, in Los Altos, CA. You can contact Clark Wilcox via Arpanet mail as Wilcox@SRI-KL, I think. XIDAK's phone number is (415) 948-4387. Eric ------- 20-Sep-81 13:40:07-EDT,820;000000000000 Mail-from: SU-SCORE rcvd at 20-Sep-81 1340-EDT Mail-from: ARPANET site RADC-TOPS20 rcvd at 20-Sep-81 1032-PDT Date: 20 Sep 1981 1327-EDT From: Mark Pratt To: TOPS-20 at SCORE Reply-to: Pratt at RADC-TOPS20 Telephone: 315-330-4013 Subject: Passwords and EXEC Message-ID: Here is a change to the EXEC which will not type out passwords during a ^ECREATE, BUILD, or I DIR, unless VERBOSE has been specified. This is nice since most of the time you don't want the password to type out. This way you have to specifically have to ask for it. In EXEC4 of EXEC, at PR2-2, insert after the JUMPE TLNN Z,F3 ;ONLY TYPE PASSWORD ON VERBOSE MODE JRST [TYPE <- available using VERBOSE> JRST PR2] -- Mark -------- 20-Sep-81 13:47:19-EDT,1088;000000000000 Mail-from: SU-SCORE rcvd at 20-Sep-81 1347-EDT Mail-from: ARPANET site RADC-TOPS20 rcvd at 20-Sep-81 1042-PDT Date: 20 Sep 1981 1343-EDT From: Mark Pratt To: TOPS-20 at SCORE Reply-to: Pratt at RADC-TOPS20 Telephone: 315-330-4013 Subject: IMPLEO's Message-ID: Has anyone out there experienced something similar to this: RADC-TOPS20 has recently experienced some problems with TELNET in which the user (already connected to RADC-TOPS20) connected to RADC-TOPS20, got logged in, started to work, and suddenly his TELNET'd job seemed to hang. The job wouldn't respond to anything. The job running TELNET was working fine. When looking at the status of the connections with NETSTAT, the hung job's status was OPND and the TELNET job was DATW. At the same time, a buginf IMPLEO (can't find lt entry for for output message) for that user came up on the console. The problem does not seem to be reproducible. I am wondering if anyone else has seen this. Thanks Mark -------- 22-Sep-81 17:21:18-EDT,2915;000000000001 Mail-from: SU-SCORE rcvd at 22-Sep-81 1721-EDT Mail-from: ARPANET site BBND rcvd at 22-Sep-81 1104-PDT Date: 22 Sep 1981 1256-EDT From: TAPPAN at BBND (Dan Tappan) Subject: Bug in FORK To: TOPS-20 at SCORE cc: Clynn The following bug causes PAGLCK bughlt's occasionally when using Mark's TCP TELNET. The cause is that the TCP, in the CLZFF code, is fondling the user's address space after it has been PMAP'ed to oblivion. The original code had a check of the SPT share count to catch something like this, but since the check was after the CLZFF it didn't work. One fix would have been just to move the share count check to before the CLZFF, but I decided the following one is not much less efficent, and potentially catches more bugs. (Note that this bug only shows up on a system running TCP, but it might be a good idea to get the fix in any system, since the bug could be hit if anything else new starts playing around with the user address space) A SRCCOM of the relevant changes follows: ; FORK.MAC.14 & FORK.MAC.9 22-Sep-81 1242 PAGE 1 LINE 1, PAGE 1 1) ;FORK.MAC.10, 27-Aug-81 11:36:23, Edit by TAPPAN 1) ;101: Fix bug in KSELF, where shared UPT not getting properly cleared 1) ;FORK.MAC.9, 10-Jul-81 18:51:14, Edit by TAPPAN LINE 1, PAGE 1 2) ;FORK.MAC.9, 10-Jul-81 18:51:14, Edit by TAPPAN LINE 97, PAGE 15 1) ;;; 101: Deletion 1) CALL FLOCK LINE 96, PAGE 15 2) MOVE FX,FORKX 2) HLRZ 1,FKPGS(7) 2) LOAD 2,SPTSHC,(1) ;GET SHARE COUNT OF UPT 2) PUSH P,2 ;SAVE IT FOR LATER CHECK 2) CALL FLOCK ; FORK.MAC.14 & FORK.MAC.9 22-Sep-81 1242 PAGE 2 (This is at just above KSEF2) LINE 120, PAGE 15 1) ;;; 101: Do at least one pass through the UPT to be sure pages are gone 1) JRST KSEF3A ; Skip the DISMS first time through 1) 1) KSEF3: MOVEI 1,^D5000 1) DISMS ;WAIT FOR 5 SECS 1) KSEF3A: MOVE FX,FORKX ; get our fork index 1) HLRZ 1,FKPGS(FX) ; THEN CLEAR MAP AGAIN 1) LOAD 2,SPTSHC,(1) ; SHARE COUNT OF UPT 1) PUSH P,2 1) SETZ 1, 1) HLLZ 2,FKPGS(FX) 1) KSEF4: HRRZ T3,T2 ;MAKE A GOOD ADDRESS. 1) SKIPE UPTPGA(T3) ;QUICK CHECK FOR ALREADY EMPTY 1) CALL SETPT ;BUT NOT USING PMAP 1) MOVEI 6,0(T3) 1) CAIGE 6,777 1) AOJA 2,KSEF4 1) ; 101: End of change 1) LINE 123, PAGE 15 2) LINE 158, PAGE 15 1) ;;; 101: deletion 1) ^L LINE 144, PAGE 15 2) KSEF3: MOVEI 1,^D5000 2) DISMS ;WAIT FOR 5 SECS 2) HLRZ 1,FKPGS(7) ;THEN CLEAR MAP AGAIN 2) LOAD 2,SPTSHC,(1) ;SHARE COUNT OF UPT 2) PUSH P,2 2) SETZ 1, 2) HLLZ 2,FKPGS(7) 2) KSEF4: HRRZ T3,T2 ;MAKE A GOOD ADDRESS. 2) SKIPE UPTPGA(T3) ;QUICK CHECK FOR ALREADY EMPTY 2) CALL SETPT ;BUT NOT USING PMAP 2) MOVEI 6,0(T3) 2) CAIGE 6,777 ; FORK.MAC.14 & FORK.MAC.9 22-Sep-81 1242 PAGE 3 2) AOJA 2,KSEF4 2) JRST KSEF2 2) ^L ---------------- Dan ------- 22-Sep-81 18:18:35-EDT,432;000000000000 Mail-from: SU-SCORE rcvd at 22-Sep-81 1818-EDT Mail-from: ARPANET site SANDIA rcvd at 22-Sep-81 1512-PDT Date: 22 Sep 1981 1608-MDT From: Norm Samuelson Subject: DECUS To: tops-20 at SANDIA It always helps to find out such things AFTER you make your reservations, but all the DEC-10/20 sessions at the fall DECUS in L.A. will be in the old Biltmore hotel, not the new Bonaventure. - Sam - ------- 23-Sep-81 11:37:33-EDT,1127;000000000000 Mail-from: SU-SCORE rcvd at 23-Sep-81 1137-EDT Mail-from: ARPANET site RADC-TOPS20 rcvd at 23-Sep-81 0831-PDT Date: 23 Sep 1981 1131-EDT From: Mark Pratt To: TOPS-20 at SCORE cc: ADMIN at RADC-TOPS20 Reply-to: Pratt at RADC-TOPS20 Telephone: 315-330-4013 Subject: MONRD% JSYS Message-ID: There is a bug in the MONRD jsys which breaks reading of PSB locations and the fork status function. This bug only occurs if you've changed the edit number of the monitor, say like using the edit number as a local edit number. In the CHKFRK routine of the MONRD% jsys, which is in the source for SYSDPY, there is the following code which can be removed for version 4 sites. At CHKFRK+4, remove HRRZ T2,.JBVER ;GET MONITOR VERSION CAIGE T2,NWFKPT ;NEW STYLE SCHEDULER CODE ? JRST CHKFRO(P1) ;NO, GO DO IT THE OLD WAY Also, remove CHKFRO: +$$(FKPT,STG) ;GET THE QUEUE FORK IS ON CAIE T2,$$(WTLST,STG) ;IS FORK IN A WAIT ? CAIN T2,$$(GOLST,STG) ;OR RUNNABLE ? JRST SKP(P1) -- Mark -------- 26-Sep-81 17:42:50-EDT,2859;000000000001 Mail-from: SU-SCORE rcvd at 26-Sep-81 1742-EDT Mail-from: ARPANET site SRI-KL rcvd at 26-Sep-81 1436-PDT Date: 26 Sep 1981 1435-PDT From: ROODE at SRI-KL (David Roode) Subject: abysmal state of VAX/VMS To: tops-20 at SU-SCORE A long time ago, I heard a rumor of a TOPS-30 that was supposed to be a TENEX-like operating system for the VAX. Is there any more recent rumbling along these lines? Can anyone comment on the VMS operating system, specifically: 1) Why was there no "?" style help let along command completion implemented in the command language? 2) Why are there no read dates kept for files? 3) Why was there no LOAD-class commands feature? 4) Why is the command language they did implement (DCL) so unruly in its organization. For example, the command to cancel a spooler request is a switch option on the DELETE command which is normally used to delete files. This seems silly. Conversely, the command to "unlock" a file is top level, where as it seems this should be relatively little-used. (Files are "locked" when something goes wrong, like a ^C while they are being written.) 5) If a parity error occurs in reading from a .EXE file which the user is running, the user gets an abnormal termination report for the .EXE file (several lines of "stack dump", etc.) but then finds himself logged off the system, without so much as a message to that effect. 6) Unless the user defines his own synonym, or "the image is installed" in order to run a system provided program (CUSP, program), the user must use a command like: RUN SYS$SYSTEM:PROGNAME or RUN DBA0:PROGNAME or else he can use the only built in shorthand, which is MCR PROGNAME and which was designed to mean "run me in RSX-11M compatibility mode, using its comand language, pretend PROGNAME is 'installed' in RSX-11M, and run it." 7) Although there is little logic in it, every user is assigned a UIC (like [101,2]) which essentially seems to be another way of specifiying the username, and is stored as an attribute of any directories the user may have (none of which need match the username). Sometimes the UIC is required to identify the user, and sometimes the directory. There doesn't seem to be any easy way to find out the username of a given UIC, either. All files are owned by someone specified via UIC. If you create a file in a user's directory for him, you own it, and he cannot access it as owner. There is no way to change the file owner. If you want him to own it, you have to remember to specify this by setting your UIC to be his before creating the file. If a user finds files someone else created, he has no way of knowing whose UIC that is. Well, I guess DEC believes in repeating their past mistakes, not repeating their successes, and then some. ------- 26-Sep-81 19:40:50-EDT,1347;000000000001 Mail-from: SU-SCORE rcvd at 26-Sep-81 1940-EDT Mail-from: ARPANET site SANDIA rcvd at 26-Sep-81 1634-PDT Date: 26 Sep 1981 1735-MDT From: Norm Samuelson Subject: Re: abysmal state of VAX/VMS To: ROODE at SRI-KL cc: tops-20 at SANDIA In-Reply-To: Your message of 26-Sep-81 1535-MDT Boy, It sure is good to see that someone else thinks VMS sucks!!! Oh, There are a couple of things I may be able to help you with. There is a program called WHO which translates UIC to username and vice-versa. It is NOT a one-to-one translation, each username maps to one UIC, but many other user names may map to the SAME UIC.! Most of what I see wrong with VMS seems to come from one of two places, either trying to maintain compatibility with RSX-11M (not unreasonable), or trying (and failing miserably) to make it somewhat compatible with TOPS-10 and TOPS-20. My favorite gripe is the TERRIBLE way COLON is handled in il-logical names. If you use the DEFINE command, and include a colon (as you should and must on TOPS-20), the logical name you just defined has a colon on it, and will NEVER be of any use. Logical names MUST NOT include the colon. There are some times you MUST INCLUDE the colon, some times you MUST OMIT it, and still other times where it is optional...A real mess!!! - Sam - ------- 26-Sep-81 20:42:51-EDT,996;000000000000 Mail-from: SU-SCORE rcvd at 26-Sep-81 2042-EDT Date: 26 Sep 1981 1737-PDT From: Mark Crispin Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Subject: discussions about VAX/VMS, etc. To: TOPS-20 at SU-SCORE I do not believe that discussions about VMS are apropos for this mailing list, which is mostly for the spread of technical folklore on TOPS-20. Many of the people on this list may be interested in such a discussion, but it would be better to spawn off another list for it. My personal belief is that there is little likelihood to see functionality of the sort we know and love on TOPS-20 on VMS. The VMS developers seem to believe that it is "inefficient" to have a user interface. If anybody would like to spawn off a VMS mailing list, the membership of the TOPS-20 list is online at SU-SCORE as PS:TOPS-20.DIS. The file is in MM format. ------- 26-Sep-81 22:41:01-EDT,680;000000000000 Mail-from: SU-SCORE rcvd at 26-Sep-81 2240-EDT Mail-from: ARPANET site RUTGERS rcvd at 26-Sep-81 1935-PDT Date: 26 Sep 1981 2234-EDT From: Jonathan Alan Solomon Subject: Re: discussions about VAX/VMS, etc. To: Admin.MRC at SU-SCORE cc: TOPS-20 at SU-SCORE In-Reply-To: Your message of 26-Sep-81 2037-EDT There currently is a mailing list for discussion of VAX problems, both for VMS and UNIX. The list is called INFO-VAX@MIT-AI, and I maintain it. I am open to suggestions that it be moved to some more secure site if discussions warrant doing so, but the current discussion is much more appropriate on INFO-VAX than on TOPS-20 /Jon ------- 27-Sep-81 10:03:25-EDT,900;000000000000 Mail-from: SU-SCORE rcvd at 27-Sep-81 1003-EDT Mail-from: ARPANET site USC-ECLB rcvd at 27-Sep-81 0701-PDT Date: 27 Sep 1981 0650-PDT From: Mark Thompson Subject: Re: Investment opportunities To: TOPS-20 at SU-SCORE In-Reply-To: Your message of 17-Sep-81 1546-PDT Unfortunately, at DEC everything is a P/L center, so the people who print the manuals have to recover the cost (rather than the more obvious method of charging it to the product). It does seem that they could come up with some sort of scheme to keep the prices reasonable (at the very least, print it on the same cheap paper that IBM uses.... You dont really need notebook style paper), and it is true that if you are a bookstore, they will kick the price down to where you can use a reasonable markup before you get to cover price (Which may have something to do with it too).. ------- 28-Sep-81 12:41:32-EDT,779;000000000000 Mail-from: SU-SCORE rcvd at 28-Sep-81 1241-EDT Mail-from: ARPANET site SRI-KL rcvd at 28-Sep-81 0937-PDT Date: 28 Sep 1981 0921-PDT From: Richard R. Cower Subject: Re: abysmal state of VAX/VMS To: ROODE at SRI-KL, tops-20 at SU-SCORE cc: COWER at SRI-KL In-Reply-To: Your message of 26-Sep-81 1435-PDT The only comment I can offer is that VMS is a "young" operating system, and has a number of areas in which to grow. I can assure you, if you had the opportunity to use an early Tenex...you would have found more to complain about than the lack of various features in the command language. I would advise you to make a list of your VMS complaints, and carry them to DECUS, where you can present them to the developers. ..Rich Cower ------- 29-Sep-81 17:25:13-EDT,1206;000000000000 Mail-from: SU-SCORE rcvd at 29-Sep-81 1725-EDT Mail-from: ARPANET site AFSC-HQ rcvd at 29-Sep-81 1420-PDT Date: 29 Sep 1981 1716-EDT From: Chuck Perilli Address: HQ AFSC/ACDPS, Andrews AFB, DC 20334 Phone: (301)981-4002; AUTOVON: 858-4002 Subject: System Display Programs To: TOPS-20 at SU-SCORE cc: : ; Our computer operations people have requested a program to display the following information either on the same screen or to automatically switch between different screens to display the information: 1. Print Queue 2. Mount Queue 3. Batch Queue 4. Jobs (a very abbreviated listing is adequate) 5. Free pages remaining on PS: 6. Load average I am considering just modifying SYSDPY to do this on a 24x132 col CRT. We do not have a full time operator for the 20, so they have placed a CRT next to the console of the Honeywell 6000 that normally keeps the operator(s) busy. Ideally, a glance at the CRT should give the operator an idea of what's going on in the 20 and whether anything needs attention. If anyone knows of a program more suitable than SYSDPY for this application, I'd appreciate hearing about it. ------- 29-Sep-81 17:48:00-EDT,690;000000000000 Mail-from: SU-SCORE rcvd at 29-Sep-81 1747-EDT Mail-from: ARPANET site SRI-KL rcvd at 29-Sep-81 1438-PDT Date: 29 Sep 1981 1435-PDT From: ROODE at SRI-KL (David Roode) Subject: Re: System Display Programs To: PERILLI at AFSC-HQ, TOPS-20 at SU-SCORE cc: at AFSC-HQ In-Reply-To: Your message of 29-Sep-81 1416-PDT The way our operators watch what needs attention without being at the console is to just make a one-way terminal link (TLINK) from the console to their terminal. That way, all console messages are visible at the remote location, and the terminal they are on is free to issue normal commands. Maybe the fancy display you want could be added to OPR. ------- 30-Sep-81 00:15:34-EDT,1124;000000000000 Mail-from: SU-SCORE rcvd at 30-Sep-81 0015-EDT Mail-from: ARPANET site USC-ISIB rcvd at 29-Sep-81 2109-PDT Date: 29 Sep 1981 2108-PDT Sender: JGOLDBERGER at USC-ISIB Subject: Bad response under light load From: Joel Goldberger Reply-To: JGOLDBERGER at USC-ISIB To: TOPS-20 at SCORE Message-ID: <[USC-ISIB]29-Sep-81 21:08:17.JGOLDBERGER> A number of our users have been reporting poor response even though the Load Average is quite low (1-3). This seems to occur only after the system has been through a period of very heavy load. For example several of the reports have mentioned Saturday mornings after especially bad Fridays (Load Av >25). Has anyone else noticed anything like this, or does anyone have any ideas what might be going on. We have class scheduling turned ON and use a bias knob setting of 6. We have changed the bias settings so that SK%HQR is off for 6. The specific symptom is that large programs (NLS or LISP) take a very long time to startup. It seems that if the system is reloaded and never goes through a high load period response is much better. Joel Goldberger 1-Oct-81 11:31:02-EDT,388;000000000000 Mail-from: SU-SCORE rcvd at 1-Oct-81 1130-EDT Mail-from: ARPANET site SANDIA rcvd at 1-Oct-81 0828-PDT Date: 1 Oct 1981 0928-MDT From: Norm Samuelson Subject: DECNET - performance fix for NFT/FAL To: tops-20 at SANDIA In the 15-Sep-81 Dispatch, a 10 page patch is given to improve performance of NFT and FAL. Has anyone installed it? - Sam - ------- 1-Oct-81 12:39:48-EDT,378;000000000000 Mail-from: SU-SCORE rcvd at 1-Oct-81 1239-EDT Mail-from: ARPANET site UTEXAS-20 rcvd at 1-Oct-81 0934-PDT Date: 1 Oct 1981 1133-CDT From: Edward C. Pattermann Subject: FE packs To: tops-20 at SU-SCORE Can a FE source pack be mounted and accessed on a VAX? Is the FE pack format compatible with any VAX (or -11) format? Thanks, Ed ------- 1-Oct-81 16:38:11-EDT,542;000000000001 Mail-from: SU-SCORE rcvd at 1-Oct-81 1638-EDT Mail-from: ARPANET site UTAH-20 rcvd at 1-Oct-81 1334-PDT Date: 1 Oct 1981 1430-MDT From: Randy Frank Subject: Re: FE packs To: G.ECP at UTEXAS-20, tops-20 at SU-SCORE In-Reply-To: Your message of 1-Oct-81 1033-MDT FE source packs are unfortunately in RSX Files-11 format, but written in 18 bit (20 sectors/track) mode instead of 16 bit mode. Thus, I suspect that you'd have to write some special software to read them under anything other than RSX20F. ------- 1-Oct-81 18:18:02-EDT,664;000000000001 Mail-from: SU-SCORE rcvd at 1-Oct-81 1817-EDT Mail-from: ARPANET site SRI-KL rcvd at 1-Oct-81 1504-PDT Date: 1 Oct 1981 1454-PDT From: Harris A. Meyers Subject: Re: FE packs To: G.ECP at UTEXAS-20, tops-20 at SU-SCORE In-Reply-To: Your message of 1-Oct-81 0933-PDT It is a 20 sector rsx format disk. The standard diskdriver on VAX/VMS only supports 22 sector disks. Dave Kashtan (Kashtan@sri-iu) has a driver that will support 20 or 22 sector disks. Be warned though that there is a bug in the parity circit on the 780's MBA that can cause your system to hang if the 2 "extra" bits are not both 0 or both 1. harris ------- 2-Oct-81 01:21:37-EDT,660;000000000001 Mail-from: SU-SCORE rcvd at 2-Oct-81 0121-EDT Date: 1 Oct 1981 2217-PDT From: J. Q. Johnson Subject: Re: FE packs To: G.ECP at UTEXAS-20 cc: tops-20 at SU-SCORE In-Reply-To: Your message of 1-Oct-81 0933-PDT Sorry. FE packs are written in 18-bit format, not 16-bit, so they are not accessible to any -11, just as the FE file system for the -20 (what the -20 sees as FRONT-END-FILE-SYSTEM.BIN ) is not accessible to a standard -11 disk driver. However, it would not be hard to modify your disk driver in the VAX or -11 to read such packs; look at the mods that were made in RSX20F for details. ------- 2-Oct-81 14:52:11-EDT,3783;000000000000 Mail-from: SU-SCORE rcvd at 2-Oct-81 1452-EDT Date: 2 Oct 1981 1142-PDT From: Mark Crispin Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Subject: MM/XMAILR/XMAILBOX To: TOPS-20 at SU-SCORE cc: MMcM at SU-SCORE, Mooers at BBNA, Geoff at SRI-CSL, KLH at SRI-NIC, Postel at USC-ISIF [I decided to send this message to the TOPS-20 list, because I've lost track of all the sites which run XMAILR/XMAILBOX and some interested sites may not have heard of it.] There are new versions of MM, XMAILR, and XMAILBOX at SU-SCORE as MRC:MM.FAI, MRC:XMAILR.FAI, and MRC:XMLBX.FAI. SCORE allows FTP without login for public access files. Several major problems have been fixed, as well as minor annoyances users have been complaining about for a long time. For those of you who might not know what this software is, MM is an advanced but simple to use mailsystem for TOPS-20. It is not as powerful as Hermes, but it has most of what a typical user actually uses and is considerably faster than Hermes. Most TOPS-20 sites do run MM or at least DEC's variant of it, MS. Presently there isn't any up-to-date document on MM other than its built-in help, but my wife is working on an Intro to MM and an MM Manual. XMAILR is a multi-network mailer. It supports ARPANET, Chaosnet, Dialnet, and Ethernet. It knows about the ARPANET XRCP and MLFL options for efficient delivery of messages. XMAILR knows how to route messages through gateways; using XMAILR a user on a site on MIT's Chaosnet can send mail to a site on Stanford's Ethernet. XMAILBOX is an advanced mailbox database lookup utility. It reads the file SYSTEM:MAILING.LISTS or SYSTEM:MAILING.LISTS-BIN (the latter is a compilation of MAILING.LISTS, saving it the trouble of recompiling if it is up to date) and returns the expansion of a mailbox. A mailbox may expand to an address (what the BBN MAILBOX utility does) or more generally a list of addresses; an address may be a local or network address, another mailbox, an indirect file, or an output file. For example, TOPS-20@SCORE expands to @PS:TOPS-20.DIS, which in turn has the membership list plus TOPS-20-ARCHIVE, a mailbox which expands to *PS:TOPS-20.MESSAGES (the "*" indicates a file destination). There are some dependencies to this software. MM as set up by default can be stand-alone, although it is recommended that sites which use the DEC IPCF MAILER for local mail get ahold of Stanford's modified version (I think DEC will distribute a new version of IPCF MAILER with release 5 that will have the better support for MM and MS). As an option, MM can use the HOSTS2 host table instead of the monitor host table (the limited table in SYSTEM:HSTNAM.TXT). To use XMAILR MM must use HOSTS2, and to use XMAILBOX the system must run XMAILR as the network mailer (actually this last limitation is only because the old Tenex MAILER or NMAILR doesn't know about XMAILBOX). XMAILR can run either along with NMAILR or as the only network mailer; in the latter case the site should get Stanford/MIT's modifications to FTPSER to write the right format queued mail files, also any program that writes [--UNSENT-MAIL--] files has to be either fixed to write XMAILR-format [--NETWORK-MAIL--] files or removed. XMAILR can be tortured into reading [--UNSENT-MAIL--] files by an assembly switch, but doing so loses a lot of the functionality provided only by [--NETWORK-MAIL--] files. MM, XMAILR, and XMAILBOX can be made to run under Tenex with some additional software. -- Mark -- ------- 2-Oct-81 23:46:24-EDT,3095;000000000000 Mail-from: SU-SCORE rcvd at 2-Oct-81 2346-EDT Mail-from: ARPANET site RUTGERS rcvd at 2-Oct-81 2017-PDT Date: 2 Oct 1981 2203-EDT From: HEDRICK at RUTGERS (Mngr DEC-20's/Dir LCSR Comp Facility) Subject: for the mailing list, a query about administrative policy To: admin.mrc at SU-SCORE cc: rms at MIT-AI, rindFLEISCH at SUMEX-AIM, wactlar at CMU-10A Remailed-date: 2 Oct 1981 2040-PDT Remailed-from: Mark Crispin Remailed-to: TOPS-20 at SU-SCORE, REG at SU-AI I would appreciate having a summary about the policies used at other sites about giving software out. I am noticing that an increasing amount of software is becoming proprietary. We are being asked to sign various objectionable agreements to get software from sites to whom we have freely given our software and software support. I am seriously considering adopting some sort of policy whereby we treat a site the same way they treat us. This will take some care to formulate. Among the problems is how to handle the fact that there are different groups at the same institution that have different policies. E.g. I have excellent relations with most of MIT. However our VLSI group just got a license from another research team at MIT which they are supposed to sign that would by implication require us to make the software execute-only, not put it on backups, and would allow them to remove our right to use it (and make us expunge all copies) on 90 days notice without cause. I do not intend to single out MIT, since we have had similar occurrences with most Universities with whom we deal (and not with some industrial groups). If we don't do anything about this, it is easy to forsee the collapse of the "hacker community" that has given us all the software we know and love on PDP-10's of various colors. If the problem is not with the groups themselves, but with University lawyers, then I would suggest that a reasonable approach would be to start a cooperative arrangement among any interested Universities wherein all software within a certain class is mutually licensed. Personally, I would be happy to include non-Universities, but some University legal staffs might feel that this would be a bad idea. (Or maybe they could join by paying some sort of royalty fee to the group as a whole.) When you are dealing with only one program, it is easy to feel that what you have to gain by keeping control of that program outweighs any vague concern about mutuality with other researchers. However if there is a large body of existing software from which you will be cut off if you don't agree to share, the tradeoff will probably look quite different. What I really want is for this to go to system managers. I would appreciate it if you would forward this message to anyone who seems appropriate. I would appreciate in knowing how many sites would be interested in getting involved in such an arrangement, and what they think it could reasonably cover, i.e. just things developed by hackers, or results of reseach projects? ------- 3-Oct-81 00:21:33-EDT,2174;000000000000 Mail-from: SU-SCORE rcvd at 3-Oct-81 0021-EDT Mail-from: ARPANET site UTAH-20 rcvd at 2-Oct-81 2113-PDT Date: 2 Oct 1981 2214-MDT From: Randy Frank Subject: Re: for the mailing list, a query about administrative policy To: tops-20 at SU-SCORE In-Reply-To: Your message of 2-Oct-81 2003-MDT I am in almost total sympathy with Chuck. For the record, we have a written departmental policy requiring the free distribution of software developed here to other universities and not-for-profit institutions, although it does allow for the sale of software to for-profit concerns. The sole exception to this is where the terms of a contract prohibit this (for example, the sponsor reserved certain proprietary rights to the software); we normally strongly fight against such clauses in contracts, but sometimes they are inevitable. It therefore strongly bothers us when we get charged for software developed at other universities. I agree that it is very tempting to begin to treat others the way that we're being treated. The one mild exception that I have with Chuck's msg is that we have found it necessary under certain circumstances to require license agreements for some of our software (at the moment REDUCE, the X.25 package, and shortly PCC/20). This is because of our desire to prevent recipients of the software from re-marketing our software for profit. This is not some abstract concern. About two years ago (prior to our having any license agreements), a Boston firm actually took REDUCE and marketed it under the name AUTOMATH with only trivial modifications. As we had (at that time) no licensing procedures, the Univ. lawyers said we had no basis for legal action. Thus our current license grants a non-tranferable, non-exclusive license to the specified software. I sincerely hope that it doesn't have any of the objectionable clauses that Chuck has alluded to (I promise I'll go check!) I think that it may be very feasible to develop some blanket license agreement that provides the type of protection we feel is needed, but doesn't have to be signed for each piece of software. Randy ------- 3-Oct-81 01:02:37-EDT,1210;000000000000 Mail-from: SU-SCORE rcvd at 3-Oct-81 0102-EDT Date: 2 Oct 1981 2158-PDT From: Mark Crispin Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Subject: Re: for the mailing list, a query about administrative policy To: FRANK at UTAH-20, HEDRICK at RUTGERS, TOPS-20 at SU-SCORE cc: rms at MIT-AI, rindFLEISCH at SUMEX-AIM, wactlar at CMU-10A In-Reply-To: Your message of 2-Oct-81 2112-PDT I think Randy's message says more or less the same thing about how Stanford handles licensing. For our "proprietary" software we require some kind of a non-disclosure agreement (e.g. a non-transferable non-exclusive software license) to prevent the sort of theft Randy alluded to (the guy who attempted to market REDUCE as AUTOMATH was unreal!). In some cases we just might want to sell the software to a for-profit concern although we'd never grant an exclusive license. I believe that Stanford is usually pretty open about its software distribution policy and our restrictions, such as they are, are to protect that software from being re-marketed for profit by others. -- Mark -- ------- 3-Oct-81 02:08:49-EDT,1289;000000000010 Mail-from: SU-SCORE rcvd at 3-Oct-81 0208-EDT Date: 2 Oct 1981 2259-PDT From: Mark Crispin Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Subject: Craig Taylor's MM problem To: CTaylor at USC-ISIF, Action at USC-ISIB, TOPS-20 at SU-SCORE The problem with MM and "MOVE ^B?" automatically doing the MOVE turns out to be a monitor bug. If a SAVED-MESSAGES-FILE is set up in MM, the MOVE command defaults to it. When COMND sees the invalid character "^B", the file parse fails, and COMND cleverly overwrites the garbage with the filename, leaving no trace in the buffer of the garbage. What's worse, it appends a CR/LF at the end after the filename, so if the filename is the last item on the command line or is followed only by defaults, the command will instantly execute! This monitor bug can be demonstrated in my TELNET as well, by typing "LOG ^B?" to it. You'll get no help, it will immediately confirm, and behave as if "LOG TELNET.LOG" was typed. I poked around a bit in MDDT at SCORE trying to come up with a quick patch, but nothing I did worked right. If anybody has a fix for this bug, I'd appreciate it... -- Mark -- ------- 3-Oct-81 11:59:02-EDT,1004;000000000000 Mail-from: SU-SCORE rcvd at 3-Oct-81 1158-EDT Mail-from: ARPANET site USC-ISIB rcvd at 3-Oct-81 0853-PDT Date: 3 Oct 1981 0853-PDT Sender: SMITH at USC-ISIB Subject: OFNs getting used up From: SMITH at USC-ISIB To: TOPS-20 at SU-SCORE Message-ID: <[USC-ISIB] 3-Oct-81 08:53:32.SMITH> We found that on one of our systems with many directoriess and much mutual access that we were steadily losing OFN's. The problem was a flag set wrong in the directory cache code. LINE 1, PAGE 1 1) ;DIRECT.MAC.3200 17-Jul-81 12:26:35 Edit by SMITH 1) ;#320 Set "release OFN" flag correctly when no room in directory cache 1) ;DIRECT.MAC.3110 7-Jul-81 10:32:12 Edit by SMITH LINE 1, PAGE 1 2) ;DIRECT.MAC.3110 7-Jul-81 10:32:12 Edit by SMITH LINE 98, PAGE 33 1) JRST [ SETONE DRROF ;#320 INDICATE TO RELEASE THIS 1) UNLOCK DIRCLK ;RELEASE LOCK LINE 98, PAGE 33 2) JRST [ SETZRO DRROF ;INDICATE TO RELEASE THIS 2) UNLOCK DIRCLK ;RELEASE LOCK 5-Oct-81 00:17:29-EDT,467;000000000000 Mail-from: SU-SCORE rcvd at 5-Oct-81 0017-EDT Mail-from: ARPANET site RUTGERS rcvd at 4-Oct-81 2114-PDT Date: 5 Oct 1981 0003-EDT From: WATROUS at RUTGERS (Don Watrous) Subject: Re: Craig Taylor's MM problem To: Admin.MRC at SU-SCORE, CTaylor at USC-ISIF, Action at USC-ISIB, To: TOPS-20 at SU-SCORE In-Reply-To: Your message of 3-Oct-81 0159-EDT See HEDRICK's message to TOPS-20 distribution list dated 21 Jul 81, subject "comnd jsys bug fix". ------- 5-Oct-81 00:23:24-EDT,1332;000000000000 Mail-from: SU-SCORE rcvd at 5-Oct-81 0023-EDT Mail-from: ARPANET site UTAH-20 rcvd at 4-Oct-81 2120-PDT Date: 4 Oct 1981 2218-MDT From: Randy Frank Subject: Performance "bug" in FESRV To: tops-20 at SU-SCORE This performance bug fix is un-important unless you make heavy use of FE: devices on a front-end (I think some of the IBM comm stuff does; we do for several specialized uses here). In FESRV BLKSIZ is set to 64 words, which for 8 bit bytes translates to a 256 byte buffer. This means that every time that FESRV calls DTESRV (DTEQ) with a buffer, it's usually 256 bytes long. Unfortunately, a maximum size front-end indirect packet is 254 bytes long, guaranteeing that every FE buffer gets split up into two DTE buffers, one 254 long and one 2 bytes long, which totally kills the little performance that the DTE is capable of (we're trying to stuff a lot of data down a DTE through a FE device, and were analyzing where all the overhead was). Cutting BLKSIZ down to 62 in FESRV guarantees that for 8 bit bytes an FE buffer will fit in a DTE indirect packet. The correct solution (which I haven't done since we always use 8 bit bytes on an FE:), it to calculate the buffer size in conjunction with the byte size to make sure that the result will fit in a DTE packet. ------- 6-Oct-81 16:32:45-EDT,1141;000000000000 Mail-from: SU-SCORE rcvd at 6-Oct-81 1632-EDT Mail-from: ARPANET site RADC-TOPS20 rcvd at 6-Oct-81 1328-PDT Date: 6 Oct 1981 1625-EDT From: Mark Pratt To: TOPS-20 at SCORE Reply-to: Pratt at RADC-TOPS20 Telephone: 315-330-4013 Subject: [OPERATOR at WPAFB-AFWAL: Your Archive Program] Message-ID: Is there anyone out there with an archive system for DEC-10's. Please reply to OPERATOR@WPAFB-AFWAL (Joe McClendon) Thanks, Mark - - - - - - - Begin message from: OPERATOR at WPAFB-AFWAL Mail-from: ARPANET host WPAFB-AFWAL rcvd at 6-Oct-81 1533-EDT Date: 6 Oct 1981 (Tuesday) 1532-EDT From: OPERATOR at WPAFB-AFWAL Subject: Your Archive Program To: PRATT at RADC-TOPS20, ADMIN at RADC-TOPS20 This is Joe McClendon. I am the administrator for the DEC-10 here. I've been told that you have a program that archives sets of files for users. I'de like very much to get what info you have on this program. Please advise if it works on a DEC-10 and how I can get it. Thanks, Joe - - - - - - - End forwarded message -------- 6-Oct-81 17:14:45-EDT,617;000000000000 Mail-from: SU-SCORE rcvd at 6-Oct-81 1714-EDT Mail-from: ARPANET site UTEXAS-20 rcvd at 6-Oct-81 1409-PDT Date: 6 Oct 1981 1609-CDT From: Edward C. Pattermann Subject: VISICALC To: tops-20 at SU-SCORE Does anyone know of a VISICALC implementation (or something simular) on DEC20's? For those of you not familiar with VISICALC, it is a very popular program on APPLES, Trash-80's, etc, which provides an electronic worksheet for analyzing any type of 'what if' situations. (if I find anything, I will forward the info back to this mailing list) Thanks, Ed ------- 7-Oct-81 15:16:44-EDT,359;000000000000 Mail-from: SU-SCORE rcvd at 7-Oct-81 1516-EDT Mail-from: ARPANET site SUMEX-AIM rcvd at 7-Oct-81 1212-PDT Date: 7 Oct 1981 0954-PDT From: Rindfleisch at SUMEX-AIM Subject: UNINET To: TOPS-20 at SU-SCORE Does anyone know of or have direct experience with UNINET as a network for remote terminal access to TOPS-20/TENEX systems? Tom R. ------- 11-Oct-81 23:06:15-EDT,965;000000000000 Mail-from: SU-SCORE rcvd at 11-Oct-81 2306-EDT Date: 11 Oct 1981 2003-PDT From: Mark Crispin Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Subject: RNAMX2 error To: TOPS-20 at SU-SCORE I have encountered a problem where a program can get the RNAMX2 error. It reads a file, and can overwrite it with a new version of that file; it first builds that file under another name and then renames it over. If that file gets expunged at exactly the right time, the RNAMX2 can happen. I have come to the conclusion that the proper fix is to remove the RNAMX2 error entirely. If a superceding RNAMF% finds that the file is gone, it should treat that JFN as a virgin JFN (which is what the user application wanted to do when it unmapped all the pages and closed the file). Has anybody else encountered this problem (and perhaps has a fix)? ------- 12-Oct-81 19:01:13-EDT,1118;000000000000 Mail-from: SU-SCORE rcvd at 12-Oct-81 1901-EDT Mail-from: ARPANET site SRI-KL rcvd at 12-Oct-81 1548-PDT Date: 12 Oct 1981 1446-PDT From: LARSON at SRI-KL Subject: host tables in monitor To: TOPS-20 at SU-SCORE I have noticed an apparent inefficiency in the monitor host tables. It looks like the tables HSTSTS and HOSTNN need to have one entry per host, while HOSTN needs to have one entry per host name. This means that HOSTN must be larger by the number of nicknames in the tables. There is only one variable (NHOSTS) that describes the length of these tables, so two of them must be somewhat larger than they need to be. If a new variable were created, perhaps NHOSTN (Number of HOST Names), we could shrink the size of HOSTN. Many references would have to be checked, to be sure that all indexes were properly based on the new variable (some routines scan HOSTN, assuming it to be NHOSTS long). Has anyone thought about this before? I am really suprised that it hasn't been done -- especially in tenex, where address space in the monitor is sometimes quite critical. Alan ------- 12-Oct-81 19:31:20-EDT,583;000000000000 Mail-from: SU-SCORE rcvd at 12-Oct-81 1931-EDT Date: 12 Oct 1981 1559-PDT From: Mark Crispin Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Subject: host tables in monitor To: TOPS-20 at SU-SCORE Of course, a solution is not to have nicknames in the monitor host table at all, which is what Stanford and a number of other places have done by moving to the HOSTS2 host table. That way monitor address space isn't wasted with lots of worthless nicknames. ------- 12-Oct-81 20:18:15-EDT,995;000000000000 Mail-from: SU-SCORE rcvd at 12-Oct-81 2018-EDT Date: 12 Oct 1981 1712-PDT From: Mark Crispin Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Subject: .MORSP function of MTOPR% To: TOPS-20 at SU-SCORE There is a monitor problem in that an unprivileged user cannot do a .MORSP MTOPR% on another user's terminal. This breaks the /DIAL-IN switch in SCORE's FINGER program for unprivileged users. What happens is that MTOPR calls CHKJFN, which does the access check without knowing that it is perfectly safe to let a .MORSP MTOPR% through. My fix to this was to replace the following two instructions at CHKJF5-2 in IO.MAC: MOVEI A,DESX2 RET with: UMOVE A,B ;GET POSSIBLE MTOPR% FUNCTION CODE HRL A,KIMUEF ;GET JSYS NUMBER CAME A,[,,.MORSP] ;IS THIS AN .MORSP MTOPR%? RETBAD (DESX2) ;TTY NOT AVAILBLE TO THIS JOB ;...DROP INTO CHKJF5 ------- 13-Oct-81 12:33:10-EDT,520;000000000000 Mail-from: SU-SCORE rcvd at 13-Oct-81 1233-EDT Mail-from: ARPANET site BBNG rcvd at 13-Oct-81 0526-PDT Date: 13 Oct 1981 0821-EDT From: Dan Tappan Subject: Re: host tables in monitor To: Admin.MRC at SU-SCORE cc: TOPS-20 at SU-SCORE, Tappan at BBNG In-Reply-To: Your message of 12-Oct-81 1859-EDT There really isn't an inefficency there. HOSTNN and HSTSTS are hash tables, and thus need to be twice as large as the number of hosts, whereas HOSTN is used in a linear search. Dan ------- 13-Oct-81 17:38:21-EDT,748;000000000010 Mail-from: SU-SCORE rcvd at 13-Oct-81 1738-EDT Mail-from: ARPANET site AFSC-HQ rcvd at 13-Oct-81 1433-PDT Date: 13 Oct 1981 1750-EDT From: Chuck Perilli Address: HQ AFSC/ACDPS, Andrews AFB, DC 20334 Phone: (301)981-4002; AUTOVON: 858-4002 Subject: Character Handling in FORTRAN To: TOPS-20 at SU-SCORE cc: PM at AFSC-HQ, : ; Does anyone have (or know of) a package of string handling routines for FORTRAN. Current Air Force policy requires all "official" programs be written in COBOL or FORTRAN, and our programmers are having fits with DEC's archaic version of FORTRAN. Most other mini/maxi computers, including VAX, have FORTRAN-77 which at least addresses the problem of character handling. ------- 13-Oct-81 18:35:25-EDT,965;000000000000 Mail-from: SU-SCORE rcvd at 13-Oct-81 1835-EDT Mail-from: ARPANET site RUTGERS rcvd at 13-Oct-81 1534-PDT Date: 13 Oct 1981 1828-EDT From: PLEASANT at RUTGERS (Mel Pleasant) Subject: Re: Character Handling in FORTRAN To: PERILLI at AFSC-HQ cc: TOPS-20 at SU-SCORE, PM at AFSC-HQ, PLEASANT at RUTGERS In-Reply-To: Your message of 13-Oct-81 1750-EDT There exists a string handling package called STRLIB which was explicitly written for FORTRAN. Unfortunately, the entire package is written in MACRO. It does not contain any UUO or JSYS calls so it can be used on either a DEC-10 or DEC-20. This package was/is?? distributed by DEC. If you can't get the package from DEC quickly, you can FTP the .rel and .doc files from here. If you want, I can also restore the sources for you from tape. The two files which are currently up on this system are: Strlib.Rel Strlib.Doc -Mel ------- 13-Oct-81 23:17:02-EDT,563;000000000000 Mail-from: SU-SCORE rcvd at 13-Oct-81 2316-EDT Mail-from: ARPANET site RUTGERS rcvd at 13-Oct-81 2014-PDT Date: 13 Oct 1981 2135-EDT From: HEDRICK at RUTGERS (Mngr DEC-20's/Dir LCSR Comp Facility) Subject: Re: Character Handling in FORTRAN To: PERILLI at AFSC-HQ cc: TOPS-20 at SU-SCORE, PM at AFSC-HQ, at AFSC-HQ In-Reply-To: Your message of 13-Oct-81 1750-EDT DEC has an old package that is quite complete. I think it is called STRLIB. We probably have it lying around from the days when we were a Tops-10 site. Haven't seen it since. ------- 14-Oct-81 21:34:17-EDT,652;000000000000 Mail-from: SU-SCORE rcvd at 14-Oct-81 2134-EDT Mail-from: ARPANET site UTEXAS-20 rcvd at 14-Oct-81 1832-PDT Date: 14 Oct 1981 2031-CDT From: Edward C. Pattermann Subject: Visicalc To: tops-20 at SU-SCORE Regarding my earlier message concerning a implementation of VISICALC on a DEC-20, a version is currently being developed by National Computer Performance Company. More information can be obtained by writing ; Bud Pine National Computer Performance Co. 907 Flying Fish St. Foster City, CA 94404 The product is hoped to be ready for preliminary demonstrations in about 6 weeks or so. -- Ed ------- 15-Oct-81 06:59:31-EDT,328;000000000000 Mail-from: SU-SCORE rcvd at 15-Oct-81 0659-EDT Mail-from: ARPANET site CMU-20C rcvd at 15-Oct-81 0357-PDT Date: 15 Oct 1981 0656-EDT From: WOHL at CMU-20C Subject: Large RP06 structures? To: TOPS-20 at SU-SCORE Does someone have monitor changes to allow RP06 structures to be larger than three packs? Aaron ------- 15-Oct-81 10:51:44-EDT,666;000000000001 Mail-from: SU-SCORE rcvd at 15-Oct-81 1051-EDT Mail-from: ARPANET site USC-ISIB rcvd at 15-Oct-81 0747-PDT Date: 15 Oct 1981 0730-PDT Sender: SMITH at USC-ISIB Subject: Re: Large RP06 structures? From: SMITH at USC-ISIB To: WOHL at CMU-20C Cc: TOPS-20 at SU-SCORE Message-ID: <[USC-ISIB]15-Oct-81 07:30:38.SMITH> In-Reply-To: Your message of 15 Oct 1981 0656-EDT You may have up to 6 RP06's in a structure if you change: DSKMSK to 777770 in STG DSKMSK to -1B14 in CHECKD DSKNB to 1B13 in PROLOG MXSTRU to 6 in your parameters file (it comes that way in PARAN only; there is an "NDG MXSTRU,4" in PROLOG) Dennis 15-Oct-81 14:48:13-EDT,1210;000000000000 Mail-from: SU-SCORE rcvd at 15-Oct-81 1448-EDT Date: 15 Oct 1981 1142-PDT From: Mark Crispin Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Subject: bug?/misfeature? in IDTIM JSYS To: TOPS-20 at SU-SCORE, Goldberg at USC-ISIB The string "14 October 1981 21:50 edt" is parsed as being October 14, 1981 9:50PM in whatever the local time zone is. This is because IDTIM terminates its parse at the space after "21:50" and never even sees the "edt". This breaks MM's date/time parsing code (for "In-Reply-To:" in a REPLY message) if the recepient is in a different time zone from the sender. Multics systems send messages with this format date/time. I think that what needs to be done is to fix IDTIM to save the pointer after a successful time parse and continue reading characters if the terminator was merely a space. If it's unable to figure out what is after the time, it should restore the pointer as the updated string pointer; otherwise it should parse it in case it's a timezone or AM/PM/etc. Has anybody worked on IDTIM in this area? -- Mark -- ------- 15-Oct-81 15:41:00-EDT,489;000000000000 Mail-from: SU-SCORE rcvd at 15-Oct-81 1540-EDT Mail-from: ARPANET site SUMEX-AIM rcvd at 15-Oct-81 1233-PDT Date: 15 Oct 1981 1233-PDT From: Eric Schoen Subject: Re: bug?/misfeature? in IDTIM To: tops-20 at SU-SCORE Mark, I'm all in favor of doing what you suggested. I have code in the Tops-20/Tenex Pup service to do exactly that, since Unix and later IFS operating systems place the timezone after the time, separated by a space. Eric ------- 15-Oct-81 16:57:57-EDT,820;000000000001 Mail-from: SU-SCORE rcvd at 15-Oct-81 1657-EDT Mail-from: ARPANET site USC-ISIB rcvd at 15-Oct-81 1349-PDT Date: 15 Oct 1981 1347-PDT Sender: SMITH at USC-ISIB Subject: Re: Large RP06 structures? [revised reply] From: SMITH at USC-ISIB To: WOHL at CMU-20C Cc: TOPS-20 at SU-SCORE Message-ID: <[USC-ISIB]15-Oct-81 13:47:55.SMITH> In-Reply-To: Your message of 15 Oct 1981 0656-EDT You may have up to 6 RP06's in a structure if you change: DSKMSK to 777770 in STG DSKMSK to -1B14 in CHECKD DSKNB to 1B13 in PROLOG MXSTRU to 6 in your parameters file (it comes that way in PARAN; there is an "NDG MXSTRU,4" in PROLOG) You also need to modify the MXPGUN computation in STG to be based on PAGCY1 & CYLUN1 instead of PAGCY0 & CYLUN0, or make MXSTRU be 12. Dennis 15-Oct-81 17:32:53-EDT,4109;000000000000 Mail-from: SU-SCORE rcvd at 15-Oct-81 1732-EDT Mail-from: ARPANET site RUTGERS rcvd at 15-Oct-81 1427-PDT Date: 15 Oct 1981 1725-EDT From: WATROUS at RUTGERS (Don Watrous) Subject: ARCHIVE-REQUESTS.BIN, etc. To: Tops-20 at SU-SCORE Well, I believe I've finished the speedup for DEC's archive system. I've also done some more support work on it too. The programs affected are the monitor, the EXEC, and DUMPER. I've provided (on [RUTGERS]PS:) FILCOMs (DIFs, actually) for the monitor (DISC.DIF and JSYSF.DIF) and the EXEC (EXECIN.DIF) and our sources for DUMPER, REAPER, and REV. FTP them at your convenience. Remember we're only on the Arpanet over a 9600 baud phone line so please be patient. The monitor has three changes: 1) ARCHIVE-REQUESTS.BIN is supported. (This has been redone since my last message to use two bits to avoid races). ARCF does not call UPDDIR on read-only functions. (This is the same patch I sent before and is highly recommended.) 3) A table entry is changed for RNAMF. (A file shouldn't take the "exempt from migration" bit with it if it's renamed. When it does, people who rename MAIL.TXT to MAIL.OLD cannot archive MAIL.OLD.) The EXEC changes are: An INFO PENDING-ARCHIVE-REQUESTS command (much like INFO ARCHIVE-STATUS, but only for incompleted requests) has been added which now uses ARCHIVE-REQUESTS.BIN if the filespec is <*>*.*.*. (There is a SCAN subcommand to override use of the .BIN file.) INFO DISK reports on pages pending archive. For DUMPER I've just included the source because it's easier and there's no reason not to. It includes a lot of work done locally, none of which should bother anyone. First of all, for archive runs of <*>*.*.*, ARCHIVE-REQUESTS.BIN is supported. (There is a /SCAN switch to override this.) Files being archived aren't set invisible. (This is done automatically by the EXEC, and if the user deliberately undoes it, why give them a hassle?) Other local mods include handling Tops-10 SFD's (which was handy for moving from a 10 to a 20), a TAKE command, a CSAVE command (not used anymore, but for continuing a saveset), a /NOMAIL switch for archiving (which we've found useful when re-archiving files which were on a destroyed archive tape - it saved half the confusion), an IGNORE command for ignoring saveset boundaries on the tape (when you know the files are \somewhere/ on that tape). Also included are various useful bugfixes. REV has a lot of support for the archive functions in the FDB. While not necessary for the archive speedup, it's quite useful. (It also supports a just added feature here - the "Last reader" string in the FDB. If people are interested in this - I stole .FBBK2 for it - I can distribute the code for the monitor/EXEC involved.) REAPER too, while not being necessary for the archive speedup, has had a LOT of work done on it. We use it basically for trimming users down to quota, so we've put some work into that area. If you specify INTERROGATE, REAPER will ask "Trim PS: to 100?" before doing it. (If you like at this point, you can specify another value to trim to.) The exempt from migration bit is set for MAIL.TXT, 20-ARCHIVE.DIR (a remnant of our previous archiver), [UNSENT-MAIL].* and MIGRATION.ORDER. Files are trimmed in reverse chronological order of access (rather than alphabetical). Much speedup has been effected when used for a trim (90% of both elapsed and cpu time). Pending archive/migration requests aren't counted against the user. Online archived files have their contents deleted if they would be migrated. A DISTRIBUTE command will invoke quota distributing between a user and their subdirectories. (If the user's total usage exceeds their total quota, then over quota directories are trimmed proportionately until the total usage is brought in line.) I'll leave the files online until they're not accessed for a while. You'll feel better about the archiving system once you get all this code in your system! Don ------- 15-Oct-81 19:52:18-EDT,1790;000000000000 Mail-from: SU-SCORE rcvd at 15-Oct-81 1952-EDT Mail-from: ARPANET site SUMEX-AIM rcvd at 15-Oct-81 1646-PDT Date: 15 Oct 1981 1643-PDT From: Sweer at SUMEX-AIM Subject: Bug in Tenex EDDT To: Tops-20 at SU-SCORE There is a problem proceeding from breakpoints in Tenex EDDT which TOPS20 has fixed, but I note is not fixed in our sources, nor in those at ISI or BBN. When called from a breakpoint in a BUGCHK or BUGHLT (or anywhere else for that matter), EDDT saves the state of the PI system via CONI PI,SAVPI, and then turns off all channels via CONO PI,@SAVPI+1. The location SAVPI+1 contains the octal constant 1177 (in both 10X and Tops20), which turns off all selected channels. The problem comes in restoring the state of the PI system in the routine RESTOR. The code in 10x is as follows: MOVE T,SAVPI ... ;a few other instructions AND T,SAVPI+1 IORI T,2000 ;Turn on channels HRRZM T,SAVPI ... ;a few other instructions CONO PI,@SAVPI Bit 26 is the problem. If PI6 was in progress at the time of the breakpoint (and at Sumex there's a lot of action on PI6), it is preserved over the AND T,SAVPI+1, and the resultant CONO PI,@SAVPI ends up with both bits 25 and 26 ON! This has resulted in the loss of PI active bits for various channels, as the CONO tells the machine to turn them on and turn them off in the same CONO. For us the fix is to change the AND T,SAVPI+1 to an ANDI T,177. Tops20 chose to insert a TRZ T,1000 following the IORI T,2000. I gather whoever made that fix wasn't really sure what to do, as there was no edit history line referring to it, and word of such a bug never got passed around to the Tenex sites after it was discovered. Also they left in the AND T,SAVPI+1 which is obviously wrong. Andy ------- 16-Oct-81 17:14:39-EDT,387;000000000000 Mail-from: SU-SCORE rcvd at 16-Oct-81 1714-EDT Mail-from: ARPANET site RUTGERS rcvd at 16-Oct-81 1404-PDT Date: 16 Oct 1981 1651-EDT From: WATROUS at RUTGERS (Don Watrous) Subject: Support for last reader string To: Tops-20 at SU-SCORE Rutgers' support for the last reader string is now available for anonymous FTP as [RUTGERS]PS:LAST-READER.STRING. Don ------- 17-Oct-81 15:59:36-EDT,525;000000000000 Mail-from: SU-SCORE rcvd at 17-Oct-81 1559-EDT Mail-from: ARPANET site SRI-KL rcvd at 17-Oct-81 1255-PDT Date: 17 Oct 1981 1252-PDT From: ROODE at SRI-KL (David Roode) Subject: stalled forks To: tops-20 at SU-SCORE Was there some bug uncovered recently that had to do with forks that on startup for the first time appeared to be frozen for a period ranging from 20 seconds to 2 minutes? Control-C won't interrupt a fork in this state. I thought I saw something about this but can't chase it down now. ------- 17-Oct-81 18:58:29-EDT,983;000000000000 Mail-from: SU-SCORE rcvd at 17-Oct-81 1858-EDT Mail-from: ARPANET site UTEXAS-20 rcvd at 17-Oct-81 1553-PDT Date: 17 Oct 1981 1749-CDT From: Edward C. Pattermann Subject: DEC Monitor classes To: tops-20 at SU-SCORE Does anyone have any experience with the two DEC Monitor classes, the one week monitor structures class, and the two week monitor internals class? If you are going to take the internals class, do you need the structures class, and vice versa? I need to educate my systems people on supporting the monitor. They have been hacking on TOPS-20 for about two years, but just now have we received a source license. If anyone has any experience that they can share, I would appreciate it. I mainly need to decide if both classes are going to be necessary for them, and whether I need to send everyone, or whether the handouts are sufficient for one to be able to pass on the knowledge to the rest. Thanks, Ed ------- 17-Oct-81 19:07:17-EDT,1069;000000000000 Mail-from: SU-SCORE rcvd at 17-Oct-81 1907-EDT Date: 17 Oct 1981 1602-PDT From: Mark Crispin Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Subject: TOPS-20 monitor classes To: TOPS-20 at SU-SCORE I took Monitor Internals in February 1980. Monitor Structures is a new course; I have the feeling it is mostly an overview course such as the old System Programming course was. I highly recommend it. It is not a good idea to try to use the course materials without taking the course. Whether or not you send one person to take the course and then to pass it on or send everybody is up to you; I feel that anybody who is going to work on the monitor regularly should take the course for him or her self. My notes from MI are online at SCORE on the TOPS-20 archive as PS:T20-MONITOR-INTERNALS.CLASS-NOTES. Most of it is release 3A oriented, although there are some notes about 3A/4 differences. -- Mark -- ------- 17-Oct-81 19:16:01-EDT,474;000000000000 Mail-from: SU-SCORE rcvd at 17-Oct-81 1915-EDT Mail-from: ARPANET site UTAH-20 rcvd at 17-Oct-81 1611-PDT Date: 17 Oct 1981 1707-MDT From: Randy Frank Subject: Re: DEC Monitor classes To: G.ECP at UTEXAS-20, tops-20 at SU-SCORE In-Reply-To: Your message of 17-Oct-81 1649-MDT I agree with MRC. I found the internals course to be well worth the time. The lectures and labs were very good, and the course materials are also excellent. ------- 18-Oct-81 16:21:40-EDT,962;000000000000 Mail-from: SU-SCORE rcvd at 18-Oct-81 1621-EDT Mail-from: ARPANET site MIT-XX rcvd at 18-Oct-81 1317-PDT Date: 18 Oct 1981 1615-EDT From: Nat Mishkin Subject: Rebuilding file system To: tops-20 at SU-SCORE A funny things just happened to me when I re-built my PS: to make more swap space...I got more free space when I was done than I had when I started. Before the rebuild I had 8800 free pages. I increased the swap space by 3000 pages. After restoring all the files I had 10000 free pages. There is a remote possibility that the old PS: was configured with more swap space than I thought, but this is somewhat unlikely. Any ideas? I find it hard to believe that directory compaction could account for ~5000 pages. Also, I can't see how we had that many "lost pages". We may not run CHECKD as often as we should but we run it often enough so that there wouldn't be that many lost pages. -- Nat Mishkin ------- 19-Oct-81 09:41:30-EDT,433;000000000000 Mail-from: SU-SCORE rcvd at 19-Oct-81 0941-EDT Mail-from: ARPANET site MIT-XX rcvd at 19-Oct-81 0637-PDT Date: 19 Oct 1981 0935-EDT From: Steve Berlin Subject: Re: Stalled Forks To: tops-20 at SU-SCORE We sometimes get the condition you describe when a user resets a multi-section fork, then creates any new fork. Eventually a fork-lock timeout occurs (usually) and the new process continues. ------- 19-Oct-81 13:09:59-EDT,770;000000000000 Mail-from: SU-SCORE rcvd at 19-Oct-81 1309-EDT Mail-from: ARPANET site RUTGERS rcvd at 19-Oct-81 1003-PDT Date: 19 Oct 1981 1303-EDT From: HEDRICK at RUTGERS (Mngr DEC-20's/Dir LCSR Comp Facility) Subject: Re: Rebuilding file system To: NWM at MIT-XX cc: tops-20 at SU-SCORE In-Reply-To: Your message of 18-Oct-81 1615-EDT Are you sure your swap space is what you think it is? There are some problems about when swap space is octal and when it is decimal, and it is very easy to get numbers that are different than what you expected. We have a program, PHOME, that prints disk parameters from the home blocks. It turns out to be very useful in figuring out what changes you have really made. You are welcome to FTP s:phome.mac. ------- 19-Oct-81 16:33:20-EDT,741;000000000000 Mail-from: SU-SCORE rcvd at 19-Oct-81 1633-EDT Mail-from: ARPANET site DEC-MARLBORO rcvd at 19-Oct-81 1325-PDT Date: 19 Oct 1981 1619-EDT From: Kevin Paetzold To: TOPS-20 at SU-SCORE, weiner at RADC-MULTICS, weiner.ball at RADC-TOPS20, metzger at RADC-TOPS20, admin at RADC-TOPS20, ata at RADC-MULTICS Reply-to: Paetzold at DEC-MARLBORO DTN: 231-7430 Mail-Stop: MR1-2/L10 Telephone: 617-467-7430 Subject: My network mail address Message-ID: I have finally changed my mail address to DEC-MARLBORO from RADC-TOPS20. My network mail address is now PAETZOLD@DEC-MARLBORO. Please send all mail for me to PAETZOLD@DEC-MARLBORO. -------- 19-Oct-81 18:53:35-EDT,307;000000000000 Mail-from: SU-SCORE rcvd at 19-Oct-81 1853-EDT Mail-from: ARPANET site SRI-KL rcvd at 19-Oct-81 1546-PDT Date: 19 Oct 1981 1541-PDT From: Chris Ryland Subject: Re: Stalled Forks To: BERLIN at MIT-XX, tops-20 at SU-SCORE In-Reply-To: Your message of 19-Oct-81 0635-PDT ------- 19-Oct-81 20:43:18-EDT,467;000000000000 Mail-from: SU-SCORE rcvd at 19-Oct-81 2043-EDT Mail-from: ARPANET site WASHINGTON rcvd at 19-Oct-81 1736-PDT Date: 19 Oct 1981 1726-PDT From: Joe Kelsey Subject: Spooled terminals To: tops-20 at SU-SCORE cc: Joe at WASHINGTON Does anyone have a version of 180SPL which has been modified for the new Release 4 ORION/OPR operator interface? I would like to put a Printronix on a serial line, and need a spooler for it. /Joe ------- 19-Oct-81 23:12:31-EDT,3011;000000000011 Mail-from: SU-SCORE rcvd at 19-Oct-81 2312-EDT Mail-from: ARPANET site SRI-KL rcvd at 19-Oct-81 2006-PDT Date: 19 Oct 1981 1918-PDT From: Chris Ryland Subject: ultra cheap & easy front-ends To: TOPS-20 at SU-SCORE (Sorry for previous blank message: that was a mailsystem screwup.) This is a simple announcement about easy-to-connect front-ends which might be of interest to some of you. We, at Fairchild, needed to connect up our -20 to our local Chaosnet (for Lisp Machine and VAX interconnectivity), and needed to do it quickly. I started the usual "fake" DN20 construction job (cf earlier message from Randy Frank and myself about rolling your own DN20), but soon found DEC to be totally wedged about it (at least out here): Field Service will no longer be helpful about getting the few odd parts needed to build a complete DN20 lookalike. All is far from lost. I ordered a standard DTE set (M8552, M8553, M8554) from DEC Direct Sales (call them in Nashua, and they'll take a phone order, and bill you), as well as two 15' Unibus cables (I believe they're called BC-11A-15's). That seemed to go well, and they promised one- month delivery for all the boards and cables; however, I got a call back from them after a week, reporting that one of the boards was going to be 6 months coming. I told them to cancel the order, in that case, and they got back to me and promised 6 weeks instead. Sure enough, the boards came. Then, with a completely vanilla 11/34, ordered from Newman Used (with an expansion backplane, which is necessary to avoid having to terminate the Unibus inside the -10), we cabled it up in the obvious way, pulling +5v from the Unibus backplane to the molex connector associated with the -10 side of the DTE (this is to keep the Unibus crobar up). Finally, I made some simple changes to DTESRV to notice a "dead" front-end ringing the -10's doorbell, allowing a front-end to come up out of the blue. Coupled with some modifications to the standard MIT Chaosnet/LCSnet/Internet (and Ethernet) front-end software, this arrangement allows us to have a totally independent front-end (which is booted and dealt with entirely through a serial line, and all about as fast as using the DTE as a boot device). The Yale folks have adapted this software setup to LSI-11's, so with little work, assuming you're using the MCB (DECnet) front-end communications protocol (it would be trivial to make it work with the RSX20F protocol), you can have a very cheap ($5K for the LSI-11/02 and $3K for the DTE boards) front-end. (As BBN has already done.) Not only that, but the -11 runs independently of the -10, and only has to be reloaded when it crashes. Our network front-end -11 has been up for a month now, and the -10 has been reloaded many times in that period. If you want gory details, I'll be putting together yet another "roll your own (even cheaper) DN20" document which I'll make publicly FTPable. ------- 19-Oct-81 23:18:50-EDT,514;000000000000 Mail-from: SU-SCORE rcvd at 19-Oct-81 2318-EDT Mail-from: ARPANET site UTAH-20 rcvd at 19-Oct-81 2008-PDT Date: 19 Oct 1981 1845-MDT From: Randy Frank Subject: Re: Spooled terminals To: JOE at WASHINGTON, tops-20 at SU-SCORE In-Reply-To: Your message of 19-Oct-81 1826-MDT Our LPTSPL handles async terminals (it's not a separate version; it's incorporated into the standard lptspl, and does special things if the device type is a tty). Let me know if you want it. Randy ------- 20-Oct-81 10:01:31-EDT,636;000000000000 Mail-from: SU-SCORE rcvd at 20-Oct-81 1001-EDT Mail-from: ARPANET site SANDIA rcvd at 20-Oct-81 0653-PDT Date: 20 Oct 1981 0747-MDT From: Norm Samuelson Subject: Re: Spooled terminals To: JOE at WASHINGTON, tops-20 at SU-SCORE In-Reply-To: Your message of 19-Oct-81 1826-MDT I have modified LPTSPL to work with EITHER a TTY or a real LPT. To make it work I simply DEFINE PLPT1: TTY2: and run two LPTSPLs, then start both printer 0 and printer 1. It is a simple change in LPTSPL and I will be glad to give it away to anyone who wants it. It will be in directory DIST: at SANDIA. - Sam - ------- 20-Oct-81 17:25:05-EDT,1207;000000000000 Mail-from: SU-SCORE rcvd at 20-Oct-81 1725-EDT Mail-from: ARPANET site UTAH-20 rcvd at 20-Oct-81 1416-PDT Date: 20 Oct 1981 1512-MDT From: C-GRISS at UTAH-20 Subject: Re: Spooled terminals To: JOE at WASHINGTON cc: Tops-20 at SU-SCORE In-Reply-To: Your message of 19-Oct-81 1826-MDT Joe, I have a hacked LPTSPL which I use to drive a printronix with a XON/XOFF interface. Its (ala all LPTSPL's) inefficient, but does the job quite well. There are a few patches to some of the other components too. There are one/two bugs also. The hacks are different enough so that the software dispatch bug reports will probably not apply. In essence I needed to allow it to work from top of form due to graphics requirements, and thusly needed to add a SKIP command to the LPFORM.INI, and thereby having to re-organise LPTSPL because of the way it handled its auto perforation skip. I also needed to add a .PLT file type which lets the plotting software control tof and perforation skipping. At some point, I'm gonna pull out the guts, and replace it with efficient code. Youd be welcome to the code and mods. If youre interested send me mail/phone me at (801)581-5256 Cedric ------- 21-Oct-81 01:47:48-EDT,674;000000000000 Mail-from: SU-SCORE rcvd at 21-Oct-81 0147-EDT Mail-from: ARPANET site SRI-KL rcvd at 20-Oct-81 2147-PDT Date: 20 Oct 1981 2146-PDT From: Chris Ryland Subject: Re: v4a? To: NWM at MIT-XX, tops-20 at SU-SCORE In-Reply-To: Your message of 20-Oct-81 1921-PDT I don't know about V4A, but the latest I've heard about R5 is that it's becoming a disaster: DECnet Phase III is being yanked out, and that was the only truly new feature of 5, other than bug fixes and extended addressing (apparently, RP07 support is also being yanked due to problems). Of course, someone like Judy should straighten us out if we're gossiping mistakenly. ------- 21-Oct-81 01:51:25-EDT,351;000000000000 Mail-from: SU-SCORE rcvd at 21-Oct-81 0151-EDT Mail-from: ARPANET site MIT-XX rcvd at 20-Oct-81 2106-PDT Date: 20 Oct 1981 2221-EDT From: Nat Mishkin Subject: v4a? To: tops-20 at SU-SCORE I have heard references to TOPS-20 v4A. I thought the next release was going to be v5. Is my source of information confused? ------- 21-Oct-81 04:38:33-EDT,1665;000000000000 Mail-from: SU-SCORE rcvd at 21-Oct-81 0438-EDT Date: 21 Oct 1981 0132-PDT From: Mark Crispin Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Subject: TOPS-20 4A To: TOPS-20 at SU-SCORE It would have been 4.1, since evidentally marketing decided that minor version numbers should be octal numbers instead of letters. Anyway, 4.1 got canned a while ago; Peter Hurley said a few DECUS symposia ago that he didn't want to do 4.1 because it would have delayed 5 the way 3A delayed 4. I know that 5 has some significant fixes to the monitor as well as a lot of neat functionality added to the EXEC; I believe that DEC intends to make multi-forking available as an option although the distributed EXEC will still be non-MF. I guess it's pretty well-known that 5 will have more extended addressing support; Judy Hall discussed the new functionality in the TOPS-20 Extended Addressing session at the last symposium in Miami. The monitor enhancements would probably only be of concern to system wizards. I can't imagine why RP07 support would be yanked out. The last I heard, several months ago, was that it was done and worked just fine. However, I got the strong feeling at Miami that marketing was being an obstacle on RP07's, perhaps because a lot of customers who would otherwise buy RP20's would buy RP07's instead. It's a safe assumption that there won't be an RP07 LIR for release 4! I have no comment regarding DECnet Phase III. I'm not going to spread any rumors on this one! -- Mark -- ------- 22-Oct-81 01:29:51-EDT,2533;000000000000 Mail-from: SU-SCORE rcvd at 22-Oct-81 0129-EDT Mail-from: ARPANET site RUTGERS rcvd at 21-Oct-81 2218-PDT Date: 22 Oct 1981 0109-EDT From: HEDRICK at RUTGERS (Mngr DEC-20's/Dir LCSR Comp Facility) Subject: in case anyone is interested To: admin.mrc at SU-SCORE Remailed-date: 21 Oct 1981 2224-PDT Remailed-from: Mark Crispin Remailed-to: TOPS-20 at SU-SCORE Some time ago we had to figure out what to do about remote printers that were done using asynch lines rather than DECnet. We didn't think all that SET LOCATION stuff could be made to work without DECnet, and so came up with a kludge using unit numbers. It now turns out that two simple patches would have allowed us to use the more elegant DECnet node code. Although it is probably too late for us, I record these for the benefit of anyone else that may find it useful. Once these are done, a user merely does SET LOCATION FOO:: and all of his printouts come out at location FOO::. In OPR, START PRINTER 0 /NODE:FOO::/DEV:TTY123: will specify which printer is to be used for FOO::. (Of course you have to use a version of LPTSPL that knows about terminals, but that would be the case anyway.) In QSRNET.MAC old: NODE.3: MOVE S1,NETCOL(AP) ;GET THE NODE ID IN S1 MOVE S2,AP ;GET THE ENTRY ADDRESS MOVE AP,NETSTS(AP) ;GET THE STATUS BITS TXNE AP,NETONL ;IS IT ONLINE ??? $RETT ;ONLINE !! $RETF ;OFFLINE !!! new: NODE.3: MOVE S1,NETCOL(AP) ;GET THE NODE ID IN S1 MOVE S2,AP ;GET THE ENTRY ADDRESS MOVX AP,NETNSV+NETONL ;GET VALID STATUS+ONLINE MOVEM AP,NETSTS(S2) ;SAVE IT $RETT ;ONLINE !! This has the effect that merely mentioning a node in OPR causes it to appear magically online. Normally a node only appears when DECnet detects it coming on line. We don't require real nodes, only things that QUASAR thinks are nodes, so this is sufficient. The only other change needed is to make LPTSPL know that it should treat nodes using its normal methods, rather than trying to talk to them with DECnet. In LPTSPL.MAC old, SETU.2+26: MOVE S1,SUP.NO(M) ;GET THIS GUYS NODE NAME CAMN S1,CNTSTA ;IS IT A LOCAL LPT ??? JRST SETU.3 ;YES,,SKIP THIS new: JRST SETU.3 or possibly just comment out the code between here an SETU.3 It is my guess that minor modifications of this code could be used at sites that have real DECnet or IBM remote support, to make remote asych printers look real the same as real DECnet and IBM nodes. ------- 22-Oct-81 13:08:07-EDT,571;000000000000 Mail-from: SU-SCORE rcvd at 22-Oct-81 1308-EDT Mail-from: ARPANET site BBNG rcvd at 22-Oct-81 1004-PDT Date: 22 Oct 1981 1304-EDT Sender: DIPACE at BBNG Subject: More on RP07s From: DIPACE at BBNG To: tops-20 at SU-SCORE Message-ID: <[BBNG]22-Oct-81 13:04:41.DIPACE> We(BBN) will be receiving several RP07s in a few weeks. We are a field test site for them. The software is in the form of an "LIR" to release 4. Dec is using them on its marketing demo machines,but that has only been for three(3) weeks. Mark could you add my name to your tops20 list ? 22-Oct-81 13:26:00-EDT,378;000000000000 Mail-from: SU-SCORE rcvd at 22-Oct-81 1325-EDT Date: 22 Oct 1981 1023-PDT From: Ted Markowitz Subject: RP07 info To: tops-20 at SU-SCORE Does anyone have some detailed specs on the RP07? Speed, storage, price/bit, etc.? We're looking at getting an RP20 this fiscal year and I'd like to examine the RP07 as an alternative. Thanks. --ted ------- 22-Oct-81 13:39:56-EDT,421;000000000000 Mail-from: SU-SCORE rcvd at 22-Oct-81 1339-EDT Mail-from: ARPANET site UTAH-20 rcvd at 22-Oct-81 1035-PDT Date: 22 Oct 1981 1131-MDT From: Randy Frank Subject: Re: RP07 info To: G.TJM at SU-SCORE, tops-20 at SU-SCORE In-Reply-To: Your message of 22-Oct-81 1123-MDT My understanding of the rp07 pricing is that the current list price is $38,000, and current rh20 pricing is $19,000. ------- 22-Oct-81 14:26:52-EDT,549;000000000000 Mail-from: SU-SCORE rcvd at 22-Oct-81 1426-EDT Mail-from: ARPANET site SRI-KL rcvd at 22-Oct-81 1120-PDT Date: 22 Oct 1981 1118-PDT From: Chris Ryland Subject: RP07 update; RP20 costs To: tops-20 at SU-SCORE I hear from DEC people that the RP07 is definitely in R5, but that DECnet may be dropped to get R5 out in a timely fashion (mostly for RP07 support). Randy, I think Ted asked for RP20 pricing vs the RP07; the RP20 is vaguely $45K, but requires the $100K IBM channel adaptor (still called the DX20?) ------- 22-Oct-81 14:40:48-EDT,520;000000000000 Mail-from: SU-SCORE rcvd at 22-Oct-81 1440-EDT Mail-from: ARPANET site UTAH-20 rcvd at 22-Oct-81 1135-PDT Date: 22 Oct 1981 1232-MDT From: Randy Frank Subject: Re: RP07 update; RP20 costs To: RYLAND at SRI-KL, tops-20 at SU-SCORE In-Reply-To: Your message of 22-Oct-81 1218-MDT Chris is right on RP20 pricing, except that the $100K is for both the IBM channel adapter (DX20) combined with the STC disk controller. Thus the first drive is $145K, with add on drives costing $45K. ------- 25-Oct-81 21:48:54-EST,2528;000000000000 Mail-from: SU-SCORE rcvd at 25-Oct-81 2148-EST Mail-from: ARPANET site RUTGERS rcvd at 25-Oct-81 1846-PST Date: 25 Oct 1981 2139-EST From: WATROUS at RUTGERS (Don Watrous) Subject: Early mischief night this morning To: TOPS-20 at SU-SCORE If anybody has a batch job which runs at midnight, then submits itself /AFTER:TODAY to run the next morning at midnight, I'll bet it ran a good number of times this morning! And if that program submits another to run right away...it'll look like rabbit time! That was the situation around here this morning. The reason? The EXEC, in figuring out times relative to TODAY has to figure out 0000 (midnight) for today and tomorrow. To do this, it takes the current date/time adds 24 hours, outputs to string space the date of that date/time, appends to that "0:0:0" and reads back the date/time to get tomorrow morning at 0000. It then subtracts 24 hours to get midnight of this morning. Unfortunately, today had 25 hours in it. Therefore, 00nn plus 24 hours becomes 23nn, not quite making it to tomorrow. Thus, tomorrow becomes today and dates relative to TODAY are screwed up for that one hour window. The cure? Convert to real day numbers using ODTNC/IDCNV rather than hoping the current day has the usual number of hours. File 1) S:<4-EXEC>EXECSU.MAC.57,25-Oct-81 20:23:48 File 2) S:<4-EXEC>EXECSU.MAC.52,21-Oct-81 02:23:33 1)9 move b,a ;this is really TODAY 0000 now 1) HRROI A,STRNG0 ;WRITE TO SCRATCH **** 2)9 MOVSI B,1 2) ADD B,A ;GET TOMORROW SAME TIME IN A 2) HRROI A,STRNG0 ;WRITE TO SCRATCH ************** 1)9 MOVEM B,TODAY 1) setz d, ;don't supply any bits 1) odcnv ;break into real "days" 1) hlrzs c ;day of month to right half 1) hrlzi c,1(c) ;add one and return to left half 1) txz d,ic%dsa ;don't force daylight savings time 1) idcnv ;get internal date/time of tomorrow 0000 1) erjmp .+2 ;day of month too large 1) jrst gottom ;success 1) setz c, ;ok, make it first day of month 1) addi b,1 ; and bump month 1) idcnv ;try again 1) erjmp .+2 ;month is not less than 12 1) jrst gottom ;success 1) hlrzs b ;year to right half 1) hrlzi b,1(b) ;next try first month of next year 1) idcnv ;last try 1) ercal jerr ;punt 1) gottom: movem b,tomoro ;save tomorrow 1) MOVX A,CM%IDA+CM%ITM **** 2)9 MOVEM B,TOMORO ;REMEMBER VALUE FOR TOMORROW 2) SUB B,[1B17] ;CREATE BEGINNING OF TODAY 2) MOVEM B,TODAY 2) MOVX A,CM%IDA+CM%ITM ************** ------- 2-Nov-81 13:46:07-EST,1393;000000000000 Mail-from: SU-SCORE rcvd at 2-Nov-81 1346-EST Mail-from: ARPANET site BBND rcvd at 2-Nov-81 1019-PST Date: 2 Nov 1981 1318-EST From: EONEIL at BBND Subject: Archive saveset misnumbering To: TOPS-20 at SCORE The saveset misnumbering problem, which has been troubling us and other sites by causing retrieval failures, turns out to result from a sorry combination of my original (bad) code and DEC's modification of it. Obviously, I should never have put SOS TAPNO in ARCINI-- the culprit, but rather should have set TNSF, the tape-no-set flag, to compensate for the later AOS TAPNO done in DNEWV. All you have to do to fix the problem is remove the SOS TAPNO and add TXO F,TNSF at ARINI1. In case you're curious how this could corrupt the saveset number, note that it resides in the LH of TAPNO. A leftover set TNSF first causes a SOS TAPNO without the AOS happening in DNEWV, leaving the RH of TAPNO decremented, say from 1 to 0. Then the next saveset written (with TNSF off) has SOS TAPNO, set LH of TAPNO, then AOS TAPNO in DNEWV--the AOS causes overflow from the RH into the LH, leaving the LH off by one. A sneaky bug, showing up at the earliest in the third saveset written. Tapes already written with bad saveset numbers can be read with the help of a workaround reported by Watrous at Rutgers to this mailing list on 23-Apr-81. --Betty ------- 5-Nov-81 15:36:03-EST,556;000000000000 Mail-from: SU-SCORE rcvd at 5-Nov-81 1535-EST Mail-from: ARPANET site MIT-XX rcvd at 5-Nov-81 1209-PST Date: 5 Nov 1981 1519-EST From: Steve Berlin Subject: An apparent bug in DTESRV To: tops-20 at SU-SCORE It look to me as though the RETSKP at DTEQ12 + 9 should be a RET, indicating that the packet is not getting queued. I don't know what ramifications this might have, but we have been having periodic problems when front-end devices crash, including buffers that don't get released properly. -- Steve ------- 7-Nov-81 07:43:43-EST,3117;000000000000 Mail-from: SU-SCORE rcvd at 7-Nov-81 0743-EST Date: 7 Nov 1981 0437-PST From: Mark Crispin Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Subject: microcode bug in ADJBP? To: TOPS-20 at SU-SCORE, REG at SU-AI, Moon at MIT-MC I recently tried to write an ADJBP emulator, and in debugging it I noticed an inconsistancy between my emulator and the KL's implementation of ADJBP when fed a pathological byte pointer. I don't think my emulator does the right thing, but certainly what the KL is doing is totally random! I think it should set Trap 1, Overflow, and No Divide, since there is no way that that my sample byte point could specify a valid byte. I left my emulator's code the way it was, since the KL returned gubbish too and at least my emulator's gubbish made some sense (e.g. the results are always normalized, word alignment is preserved, and it bears some resemblance to what IBP does). I did write a supposed fix (under the REPEAT 0 in the code example below), which I think correctly implements the defined ISP. Is this a for-real microcode bug? Comments, anybody? With a byte pointer of 454400,,20, An adjustment count of Returns 0 454400,,20 1 14400,,20 2 454400,,21 3 14400,,21 4 454400,,22 My ADJBP emulator returns: 0 14400,,17 1 14400,,20 2 14400,,21 3 14400,,22 4 14400,,23 The code for the emulator follows: %ADJBP: HRRZ T,.JBUUO ;Get EA of ADJBP CAIGE T,20 ;An AC? SKIPA T,UUOACS(T) ;Yes, get from saved AC's MOVE T,(T) ;Else get from memory LDB U,[POINT 4,.JBUUO,12] ;U := AC argument LDB V,[POINT 6,T,11] ;V := S field of byte pointer LDB W,[POINT 6,T,5] ;W := P Field of byte pointer REPEAT 0,< ; The following code normalizes byte pointers whose P field is larger than ;36. The case of P=36 is deliberately not normalized here, since it is a ;special case and is not equivalent to P=0. CAIG W,^D36 ;Pointer need normalizing? JRST %ADJB0 ;No SUBI W,^D36 ;Yes, do so SUBI T,1 ;Normalize address as well %ADJB0: >;REPEAT 0 JUMPE V,[MOVEM T,UUOACS(U) ;If S=0, ADJBP copies C(E) to AC RET] MOVEI A,^D36 ;Compute bytes/word using formula: SUBI A,(W) ; ((36 - P) / S) + (P / S) IDIVI A,(V) MOVEI B,(W) IDIVI B,(V) ADDI A,(B) ;A := bytes/word JUMPE A,CPOPJ ;Should set Trap 1, Overflow, No Divide MOVE B,UUOACS(U) ;B := adjustment argument IDIV B,A ;Divided by bytes/word ADD T,B ;Quotient is added to BP's EA IMULI C,(V) ;Number of bits to adjust SUB W,C ;Adjust P field by specified # of bits IMULI A,(V) ;A := bits used/word JUMPL W,[ADD W,A ;Moved up a word, add a word of bits AOJA T,%ADJB1] ;Move up a word and continue CAIGE W,^D35 ;Moved back a word? JRST %ADJB1 ;No, adjustment within a word SUB W,A ;Subtract a word of bits SUBI T,1 ;Move back a word %ADJB1: DPB W,[POINT 6,T,5] ;Set P field in byte pointer MOVEM T,UUOACS(U) ;Set byte pointer RET ;And done ------- 7-Nov-81 16:31:23-EST,518;000000000000 Mail-from: SU-SCORE rcvd at 7-Nov-81 1631-EST Mail-from: ARPANET site RUTGERS rcvd at 7-Nov-81 1321-PST Date: 7 Nov 1981 1611-EST From: HEDRICK at RUTGERS (Mngr DEC-20's/Dir LCSR Comp Facility) Subject: Re: microcode bug in ADJBP? To: Admin.MRC at SU-SCORE cc: TOPS-20 at SU-SCORE, REG at SU-AI, Moon at MIT-MC In-Reply-To: Your message of 7-Nov-81 0737-EST Does your emulator properly emulate the randomness that pops up now and then when using ADJBP in with extended (two-word) byte pointers? ------- 10-Nov-81 14:48:44-EST,664;000000000000 Mail-from: SU-SCORE rcvd at 10-Nov-81 1448-EST Mail-from: ARPANET site USC-ISIB rcvd at 10-Nov-81 1144-PST Date: 10 Nov 1981 1142-PST Sender: JGOLDBERGER at USC-ISIB Subject: PA2050 (2040?) From: Joel Goldberger Reply-To: JGOLDBERGER at USC-ISIB To: Tops-20 at SU-SCORE Message-ID: <[USC-ISIB]10-Nov-81 11:42:49.JGOLDBERGER> Who all has TENEX/TOPS-20 compatibility packages and what are the features (misfeatures) of each. We have one here at ISI that is quite old, though functional that includes COMND/RDTTY/TEXTI/ TBLUK/TBADD/TBDEL and ADJBP. Before we try to regenerate one with the latest COMND module I thought to query the field. Joel 11-Nov-81 11:07:39-EST,483;000000000000 Mail-from: SU-SCORE rcvd at 11-Nov-81 1107-EST Mail-from: ARPANET site CMU-20C rcvd at 11-Nov-81 0805-PST Date: 11 Nov 1981 1102-EST From: WOHL at CMU-20C Subject: Tops-20 on KL with external channels? To: tops-20 at SU-SCORE We have this old KL here (CMUA). The processor itself has been upgraded so it should be able to run the current microcode. It does have external channels however. Does anybody have experience running TOPS-20 on such a beast? Aaron ------- 11-Nov-81 11:49:09-EST,476;000000000000 Mail-from: SU-SCORE rcvd at 11-Nov-81 1149-EST Mail-from: ARPANET site UTAH-20 rcvd at 11-Nov-81 0847-PST Date: 11 Nov 1981 0941-MST From: Randy Frank Subject: Re: Tops-20 on KL with external channels? To: WOHL at CMU-20C, tops-20 at SU-SCORE In-Reply-To: Your message of 11-Nov-81 0902-MST I think that the KL at SRI has (or used to have) both external memory and external channels running tops-20. You might check with someone there. ------- 13-Nov-81 15:42:41-EST,746;000000000001 Mail-from: SU-SCORE rcvd at 13-Nov-81 1542-EST Mail-from: ARPANET site RUTGERS rcvd at 13-Nov-81 1238-PST Date: 13 Nov 1981 1537-EST From: Roy Marantz Subject: DNxx and system crashing To: tops-20 at SU-SCORE We're finishing installation of an "erector set" DN20. I have a few questions about what I should expect from it. 1) Does anyone have any diagnostics for a DTE connected to an 11 that the 20 can't reboot? 2) Should the 11 be able to do a bus init (ie reboot...) and/or be powered up and down without effecting the 20? 3) Has anyone used the DTESRV routines to talk to a non-RSX20F, non-DN87 protocol FE? Any ideas, comments, hints, or whatever will be appreciated. Thanks. Roy ------- 13-Nov-81 17:44:10-EST,1656;000000000000 Mail-from: SU-SCORE rcvd at 13-Nov-81 1744-EST Mail-from: ARPANET site UTAH-20 rcvd at 13-Nov-81 1434-PST Date: 13 Nov 1981 1528-MST From: Randy Frank Subject: Re: DNxx and system crashing To: MARANTZ at RUTGERS, tops-20 at SU-SCORE In-Reply-To: Your message of 13-Nov-81 1337-MST 1) it is possible to load 11 diagnostics either through the DTE, or through the async line connecting the primary front-end DLn: to the DN20 console. The stuff to do all of this is on the KLAD pack. 2) you can do almost anything to the 11 (power, init, kick, curse at...) without effecting the 20. Even when active, you can screw up DTE protocol from the 11 end with infinite variation without bothering the KL; the worst that the KL will do is declare the dn20 dead. It's incredibly robust - one of the more impressive parts of the interface. In the course of debugging our front-end code, we have managed to screw up protocol in more ways than can be imagined, and it has NEVER caused the KL to crash, although we have gotten virtually every BUGCHK DN20xx in the book. 3) Our software currently uses 20F protocol. We have found some bugs in DTESRV, but they only appear if you have TTYSRV modified to put tty lines on secondary front-ends. With respect to 1), if your favorite field service tech can't help you load diags from over the async line, I can look up how to do it. Haven't done it in ages, so I don't remember off the top of my head. Of course, you can also use DNLOAD with the DLOAD command to load diagnostics, assuming you can talk thru the DTE. Randy ------- 16-Nov-81 17:06:46-EST,830;000000000001 Mail-from: SU-SCORE rcvd at 16-Nov-81 1706-EST Mail-from: ARPANET site UTEXAS-20 rcvd at 16-Nov-81 0637-PST Date: 16 Nov 1981 0836-CST From: CC.LOOMIS at UTEXAS-20 Subject: RSX-20F crashes To: Admin.MRC at SU-SCORE Remailed-date: 16 Nov 1981 1359-PST Remailed-from: Mark Crispin Remailed-to: TOPS-20 at SU-SCORE Our RSX-20F front-end has been crashing two or three times a day with T04's or buffer overruns (B02/BO3). The trap-4s appear to be caused by trashed linked lists or registers when -20F attempts to schedule a task, i.e. linked list insertion. Routine .D.QIO seems to be the culprit or is always closely involved. The buffer overruns usually occur after send-all's, although we haven't verified that that is the exact cause. Has anyone seen/fixed similar problems? ------- 17-Nov-81 13:09:29-EST,558;000000000000 Mail-from: SU-SCORE rcvd at 17-Nov-81 1309-EST Mail-from: ARPANET site SRI-KL rcvd at 16-Nov-81 1654-PST Date: 16 Nov 1981 1506-PST From: Richard R. Cower Subject: Recent UNIX article To: Admin.mrc at SU-SCORE Remailed-date: 17 Nov 1981 0955-PST Remailed-from: Mark Crispin Remailed-to: tops-20 at SU-SCORE Mark, I think the folks on the 20 mailing list might like to see: NOV. 81 DATAMATION The Trouble with UNIX by Donald A. Norman ps...it is not pro-UNIX. ..thanks...Rich Cower ------- 18-Nov-81 12:55:34-EST,1696;000000000000 Mail-from: SU-SCORE rcvd at 18-Nov-81 1255-EST Mail-from: ARPANET site UTAH-20 rcvd at 17-Nov-81 2216-PST Date: 17 Nov 1981 2308-MST From: Randy Frank Subject: disk damage - explanation? To: tops-20 at SU-SCORE cc: LEPREAU at UTAH-20 We just experienced some logical damage to files on PS: which I am wont to provide a reasonable explanation. To the best that we can tell, some hardware went crazy this afternoon (disk drive or RH20). The net effect (to the best that we can tell) is the several files had a few bits changed. However, what's difficult to understand is: 1) there appears to be no damage to the file sys database (checkd check bittable reports no problems, no lost pages) 2) the files that we have found damaged are all files that were opened read/execute (not write), e.g., system:exec, sys:emacs, etc. They all had the bit 20,,000000 turned on on the first word of a page. My problem in figuring out a logical explanation is the following: 1) if the drive or RH were really just spraying bits over the disk in ramdom places (a theory I don't believe), one would expect some index blocks or directories to have been damaged. 2) if the problem occurred during writing a block to disk (a more likely explanation), why should system:exec have been re-written. It has always been my understanding that DDMP only writes pages from swapping space back to disk if they have been written. Am I wrong? Is there any way that a file that is open read/execute can have pages written from swapping space back to the disk? Any illuminating theories would be welcome. I'm stumped. ------- 18-Nov-81 13:00:03-EST,680;000000000000 Mail-from: SU-SCORE rcvd at 18-Nov-81 1259-EST Mail-from: ARPANET site SU-SCORE rcvd at 18-Nov-81 0724-PST Date: 18 Nov 1981 0723-PST From: Ted Markowitz Subject: Re: disk damage - explanation? To: FRANK at UTAH-20, tops-20 at SU-SCORE cc: LEPREAU at UTAH-20 In-Reply-To: Your message of 17-Nov-81 2208-PST DDMP does only write back changed pages. Are you sure that the reason could only be hardware? I can't quite see the mechanism but, can you completely discount some piece of software from being the culprit? --- perhaps archiving, DUMPER, etc., that would in it's normal course of operation munge around the file system. --ted ------- 18-Nov-81 13:01:10-EST,516;000000000000 Mail-from: SU-SCORE rcvd at 18-Nov-81 1301-EST Mail-from: ARPANET site AFSC-HQ rcvd at 18-Nov-81 0827-PST Date: 18 Nov 1981 1125-EST From: Chuck Perilli Address: HQ AFSC/ACDPS, Andrews AFB, DC 20334 Phone: (301)981-4002; AUTOVON: 858-4002 Subject: CROSS To: TOPS-20 at SU-SCORE We are having a few problems trying to use the CROSS assembler (for 8080 code) and would appreciate hearing from anyone willing to answer a number of questions we have. Thanks. ---Chuck ------- 18-Nov-81 23:22:36-EST,16282;000000000000 Mail-from: SU-SCORE rcvd at 18-Nov-81 2322-EST Mail-from: ARPANET site RUTGERS rcvd at 18-Nov-81 2010-PST Date: 18 Nov 1981 1535-EST From: HEDRICK at RUTGERS (Mngr DEC-20's/Dir LCSR Comp Facility) Subject: how to do a refresh To: tops-20 at SU-SCORE Every time we do a refresh, it is a crisis. The instructions in the operator's manual are laughably incomplete. Each time we think we have remembered everything, we find something more. Since many of the rest of you may be in a similar situation, I thought you might find it helpful to see our current list of instructions. Note that some of these are site-dependent. For example, we have two drives that are connected to the front end. We also have one more drive than the number of packs in PS:. This allows us to bring up a backup (one-pack) system on the extra drive (which we call S:) and mount PS: as a mountable pack. This allows much more flexibility than trying to do everything running from PS:. Some of the following instructions would not work if you had to run from the system you were saving or restoring. If you are interested in a more complete list of our procedures, you can look at opr.doc. However things change around here so fast that almost anything in there could be out of date. ======================================================= 5.9 Doing a refresh Refreshes are done most often when something is wrong with the file system. That is why this section is in the chapter on problems. However refreshes are also done about once a year as preventive maintenance. A refresh will cause all files to be stored contiguously. This speeds up file access. It will also often get more disk space. Aside from the regular preventive maintenance, refreshes are done for two kinds of reasons: - There has been hardware trouble. This resulted in damage to the file system, i.e. BUGxxx's of the DIRxxx sort, or messages from CHECKD. The refresh will cure these problems. However it will not cure the hardware problem that caused them. You should make sure that the hardware is solid before doing a refresh. If you don't, you will be in big trouble. - You are having swapping crashes, i.e. crashes beginning with SWP (e.g. SWPUPT). If DEC believes that the problems is a bad disk pack, they may ask for a refresh. The refresh will cure this because you will end up putting the data onto a new (presumably undamaged) disk pack. You should be fairly sure that it is in fact the fault of the disk pack itself before doing such a refresh. A refresh consists of two steps: writing all files onto tape, and reading them back onto fresh disk packs. When possible, you should bring down the system and dump the disks onto tape. If you can do this, you will have all files up to date. If the system is in such bad shape that you can't do this, you will have to use the most recent full dump of the system. In that case, you will lose all files that have not been dumped. When dumping the system to tape, we normally boot the system from S:, and mount PS: as a mountable structure. Here is how to do that. In the following instructions, if you try to do MOUNT X:/STR:PS: and it doesn't work, try killing and restarting MOUNTR: ^ESPEAK KILL MOUNTR RUN SYS:MOUNTR ^Z Here is how to save the system on tape. You should do this if you can, i.e. if PS: is still readable. - You must kill RFTP on the other system. Since we are going to bring up S: calling it PS:, file transfers and mail could end up going the wrong place. Do this on the other system: ^ESPEAK 1 KILL EXPORT KILL IMPORT KILL RMAILR ^Z - Stop the system: ^ECEASE, ^\, SHUT - Turn off PS:. PS: must be turned off in order to boot from S:. If PS: is turned on, the system will always use it. - Make sure S: is mounted on a drive that has access to the PDP-11 front end (drives 0 or 1). Move the plugs so it is called drive 0. - Now do ENABLE/DISK. It will say UNIT NOT FOUND, and prompt you with BOOT>. At this point type S:. this is telling it to take the monitor from S: instead of PS: as usual. - It will now say it can't find PS, and ask you what disk to use. Say S: (in upper case). - The system will now come up. - Now turn on PS: and mount it. - Make sure you are logged in as OPERATOR, since passwords will not be put on the tape otherwise. Being a wheel is not sufficient. - ENABLE - Say MOUNT STRUCT X:/STR:PS: This will mount PS:, but call it X:. - Use REV to set SYSTEM-DATA.BIN.0 so you can save it. Normally a bit is turned on which will prevent DUMPER from dumping this file. If you forget this, all accounting data from the current month will be lost. Say REV SYSTEM-DATA.BIN.0. Rev will show you that file. Now type SET SAVED and then two carriage returns. - Now save the system as you would for a weekly backup. However of course you have to say SAVE X:<*>*.*.*, since PS: is now called X:. Don't forget to say X:. - Create a list of directory parameters. This is not strictly necessary, since this is a part of the DUMPER tape, but it proves to be useful for certain error recovery situations. DLUSER DLUSER>STRUCTURE X: DLUSER>DUMP filename where filename is a file on PS: (since it won't do you any good to put the listing on the structure you are about to recreate!). - Now you are going to have to create a list of files that are marked so that they are not saved by a normal DUMPER. These are files which because of contractual commitments to vendors we do not allow to show up on normal backup tapes. Shortly, we will have an option in DUMPER to do this automatically. At the moment you will have to produce a list of these files, and then either change the bit by hand using REV or produce a control file to do it automatically. PHOTO Log file: NOSAVE.LOG EXEC NOSAVE.MAC Files to check: X:<*>*.*.* ;; will output a list of these files POP ;; you now have a list of them in NOSAVE.LOG You should now edit NOSAVE.LOG and turn the list into a set of REV commands that do SET SAVED for each one. However you must omit the following files. - all files - simply saves time - all files - attempting to restore them could cause real trouble DUMP.EXE - this file must be recreated specially Once you have set the files to allow them to be saved, you then dump them with DUMPER. Since there are usually a limited number of directories involved, we usually just save the whole directory for each directory having such a file. e.g. SAVE X:,X:,X:... Once you have the tapes written, DEC may want to look at the drives and verify that they are properly aligned. Here is how to refresh PS: from tape. We hope that you were able to save PS: on tape using the procedure above. However if PS: was not readable, you will have to use the regular backup tapes. In that case you will start here. If you have already booted the system from S:, do not stop and restart the system. - You must kill RFTP on the other system. Since we are going to bring up S: calling it PS:, file transfers and mail could end up going the wrong place. Do this on the other system: ^ESPEAK 1 KILL EXPORT KILL IMPORT KILL RMAILR ^Z - Stop the system: ^ECEASE, ^\, SHUT - Turn off PS:. PS: must be turned off in order to boot from S:. If PS: is turned on, the system will always use it. - Make sure S: is mounted on a drive that has access to the PDP-11 front end (drives 0 or 1). Move the plugs so it is called drive 0. - Now do ENABLE/DISK. It will say UNIT NOT FOUND, and prompt you with BOOT>. At this point type S:. this is telling it to take the monitor from S: instead of PS: as usual. - It will now say it can't find PS, and ask you what disk to use. Say S: (in upper case). - The system will now come up. - ****START HERE IF YOU HAVE ALREADY RELOADED THE SYSTEM FROM S:. However if you skip the steps above, please verify that you have killed EXPORT, IMPORT, and RMAILR. - Make sure you are logged in as OPERATOR. - ENABLE - Now you must generate a new PS:. Do not use the same disk packs that PS: was on before. Use new packs, or packs from a previous copy of PS:. Put these packs on the drives and turn them on, but do not do a MOUNT command. Make sure that the pack that will be called "PS: volume 0" is on a drive connected to the PDP-11. Move the plugs to make this drive 1. - Run CHECKD. Say CREATE PS: to it. It will then ask you some questions: - How many packs in the structure: This is currently 3 - Name the drives: Type ? for list of drives. Usually S: will be on one drive, and you want all the rest of them. You need to type channel, unit. The output from ? will show you what these are. - How much swap space: The system manager must tell you how much this is. Currently type 15105. - How much front end space: Hit carriage return. - CHECKD has now created a new structure. It is now ready for mounting. MOUNT STR X:/STR:PS: - If you have problems with CHECKD, make sure that none of the drives are associated with structures that the system thinks are mounted. It is safest if you bring the system up with the drives spun down, and then spin them up with the new packs on them. There is an alternate procedure for creating a structure that is sometimes useful in odd situations. It involves starting the monitor at a special start address. Consult a system programmer before doing this. - Make sure that account validation is disabled. SDDT 1/ junk .SFAVR 2/ junk 0 SMON$X ;the $ represents an escape ^Z - Run DUMPER. Say TAPE tapename: CREATE ACCOUNT TAPE SUPERCEDE ALWAYS RESTORE X:<*>*.*.* X:<*>*.*.* You cannot default the output specification in RESTORE, since it defaults to the wrong thing. These commands should be used for DUMPER even if you follow the instructions in the operator's guide. If you had to use an existing backup tape, you will probably have to say RESTORE PS:<*>*.*.* X:<*>*.*.*. Or you can try DEF PS: X:. before running DUMPER. While dumper is running, you should get messages "Creating directory X:" and "Loading files into X:". If not, something may be wrong. - DUMPER will leave some files deleted, for reasons that are hard to explain. Now do UNDELETE X:<*>*.*.*. - Now look at SYS:MAILBOX.TEXT. This includes a list of all users whose mail is to be forwarded. You must delete their mailboxes. To delete a mailbox, say REV MAIL.TXT.1 then SET NOT PERM and two crlf's. Then EDELETE MAIL.TXT.1. At some point a program will be created to do this for you. - Use REV to set SYSTEM-DATA.BIN.0 to its normal state. If you are restoring from a normal backup rather than doing a full refresh, this file will not be present, so you can skip this step. Normally a bit is turned on which will prevent DUMPER from dumping this file. If you forget this, you will get an error message every time you try to do a full backup. Say REV SYSTEM-DATA.BIN.0. Rev will show you that file. Now type SET NOT SAVED and then two carriage returns. - Restore files from the special tape of files that are normally not saved. Use the same procedure as for the initial restoration. Once you have restored them, you must set them to be NOT SAVED. This is the exact inverse of the procedure you used to set them SAVED before dumping them. That is, you use the file created by NOSAVE.MAC, editing it so that REV does SET NOT SAVED for each one. If you are restoring from a normal backup rather than doing a full refresh, you will have to find the special tape left over from the most recent refresh, or load them from some other source. You should still make sure that they are SET NOT SAVED. - Create DUMP.EXE. This must be done by the special program MAKDMP, since a pointer to this file must be put into the home blocks: MAKDMP Max size of dump file in K (512): 1024 (for red) 1280 (for green) - Create files in . We should leave about 4000 free pages on X:. If there are more, CONN X: EXEC JUNK.PAS JUNK>1000 JUNK>1000 ... JUNK>^C - Stop the system: ^ECEASE ^\ SHUT - Copy the front end system from S:. Instructions for this are in the software installation guide, except that you are copying from one disk to another instead of from floppies. Bascially you run PIP and copy from DB0: to DB1:. (DB0: is the S: front end and DB1: is the PS: front end.) The software installation guide is currently in the red notebooks, volume 14, chapter 4. - Now move PS: to the desired drives. Volume 0 must be on a drive connected to the PDP-11 front end, and the plugs must be moved so it is unit 0. - Do ENABLE/DISK and come up as usual. However answer Yes to CHECKD? CHECKD will rebuild symbol tables for most directories. If it finds any other problems, you are in trouble. Probably you have hardware problems. - Restart RFTP on the other system: ^ESPEAK 1 RUN EXPORT RUN IMPORT RUN RMAILR ^Z If you lose the file system so completely that you can't dump it to tape, then you will have to do a refresh from the most recent normal system saves. Follow the above instructions, using the most recent full copy of PS: and then the most recent incremental. The instructions indicate the steps that must be changed if you are working from a backup instead of doing a full refresh. If you can't use S:, you will have to boot using the most recent system disaster tape and the front end floppies. See the operator's guide and the software installation manual. Aside from the fact that you can't use any software on S:, the procedures are similar to those shown above. We recommend avoiding this if at all possible. We should have three complete systems: red, green, and S:. If S: is usable, you can follow the procedures above. If either red or green is usable, you can restore S: from tape. Note that SYSTEM-DATA.BIN will not appear on the normal system saves. This means that you will lose billing information from the first of the month to the time of the refresh. There is a backup billing system, whose data may possibly allow you to do some billing. See the explanation of accounting. ------- 19-Nov-81 17:00:59-EST,1174;000000000000 Mail-from: SU-SCORE rcvd at 19-Nov-81 1700-EST Mail-from: ARPANET site DEC-MARLBORO rcvd at 19-Nov-81 1353-PST Date: 19 Nov 1981 1305-EST From: Kevin Paetzold To: TOPS-20 at SU-SCORE Reply-to: Paetzold at DEC-MARLBORO DTN: 231-7430 Mail-stop: MR1-2/L10 Telephone: 617-467-7430 Subject: A NOTE ON REFRESH'S Message-ID: QUITE OFTEN AFTER A REFRESH YO MAY NOTICE A DECREASE IN PERFORMANCE WITH VERY DISK INTENSIVE APPLICATIONS. ONE OF THE FEATURES OF A REFRESH IS THAT MOST OF THE PAGES NEAR THE MIDDLE OFF THE DISK GET USED UP. MOST SYSTEMS HAVE A SET OF QUITE SMALL FILES THAT GET READ, WRITTEN AND REWRITTEN A LOT. (EG. TMP FILES ETC...) WTHESE SMALL SHORT LIVED FILES WILL BE FORCED TO LIVE ON THE OUTER AREAS OF THE DISK (STATISTCALLY) AND IT WILL NORMALLY TAKE LONGER STATISTICALLY TO GET AT THEM. ONE WAY AROUND THIS IS TO CREATE A VERY LARGE FILE (10000 OR 20000) PAGES) ON THE STRUCTURE BEFORE RESTORING THE STRUCTURE. AFTER THE RESTORE IS COMPLEETED THEN THE HUGE FILE IS DELETED, FREEING UP LOTS OF SPACE IN THE MIDDLE OF THE DISK. -------- 20-Nov-81 14:44:37-EST,596;000000000001 Mail-from: SU-SCORE rcvd at 20-Nov-81 1444-EST Mail-from: ARPANET site SRI-KL rcvd at 20-Nov-81 1135-PST Date: 20 Nov 1981 1001-PST From: Chris Ryland Subject: RSX20F on-line debugging To: tops-20 at SU-SCORE Did anyone ever get FEDDT to work on a live, snarling RSX20F? I've seen lines go softwarily dead on the FE and would like to poke them back to life without figuring out octal addresses, etc. Using FEDDT with the $$O (open -11 memory via an FE device) always seemed to crash it (or other, secondary FEs). I suppose one of us should fix this... ------- 20-Nov-81 16:23:31-EST,000001271;000000000001 Date: 20 Nov 1981 1623-EST From: HEDRICK Subject: [J. Q. Johnson : Re: Patch for shared disks] To: tops-20 Mail-from: SU-SCORE rcvd at 20-Nov-81 1511-EST Date: 20 Nov 1981 1209-PST From: J. Q. Johnson Subject: Re: Patch for shared disks To: HALL at DEC-MARLBORO cc: hedrick at RUTGERS In-Reply-To: Your message of 20-Nov-81 1125-PST Thanks for the write-register patch. It turns out that this was probably NOT our problem with shared disks, since after installing our patch we still got j0nruns. We have currently given up and gone to a workaround by switching the shared disk to a less frequently used structure; the drop in "legitimate" disk accesses corresponded to a dramatic decrease in j0nruns. Note that we swapped packs, not drives, so if there's a dcl problem we'd still be seeing it. Anyway, I'll install Tony's version of the patch, complete with counter, and give you a report (remind me in a week or so) on its effectiveness. I never did any analysis of this problem myself, but only relied on Kashtan's observations, coupled with Len Bosack's belief that this might be a likely type of normally unnoticed hardware failure. ------- --------------- ======== 20-Nov-81 16:34:34-EST,00000001665;000000000000 Date: 20 Nov 1981 1634-EST From: HEDRICK Subject: [HALL at DEC-MARLBORO: Patch for shared disks] To: TOPS-20 Mail-from: DEC-MARLBORO rcvd at 20-Nov-81 1426-EST Date: 20 Nov 1981 1425-EST From: HALL at DEC-MARLBORO To: admin.mrc at SU-SCORE, Admin.jqj at SU-SCORE cc: hedrick at RUTGERS, hall at DEC-MARLBORO Subject: Patch for shared disks Message-ID: Hi, guys. Chuck Hedrick and I are having a mail exchange about his shared disks. He forwarded a patch that you had given him, in which you write the control register in order to grab a port. I asked Tony Wachs to look at the patch, and he gave me some information. He's going to continue looking into this, but meanwhile he wants you to install a patch to gather some data. OK with you? TOPS-10 does, it turns out, write a register in this case, although Tony says he had no real reason to choose that. But he isn't crazy about your choice of register. He picked the serial number register because it's not really writable. And he's not convinced that all this is necessary. So he proposes the following: At RP4ATU+3 change JRST ATNXIT to JRST FFF FFF/ AOSA .+1 COUNT: 0 JRST ATNXIT and at RP4CN2+1 replace the CALL WTREG with a JFCL. He says a positive COUNT will indicate that your hardware is doing what he expects it to do. Got that? By the way, I never got a single comment about the extended addressing patches that I sent to you for distribution. Does that mean they work, they don't work, or no one tried them? Who's going to DECUS? -------- --------------- ======== 20-Nov-81 21:42:32-EST,674;000000000001 Mail-from: SU-SCORE rcvd at 20-Nov-81 2142-EST Mail-from: ARPANET site UTEXAS-20 rcvd at 20-Nov-81 1837-PST Date: 20 Nov 1981 2030-CST From: Edward C. Pattermann Subject: FE Hacking To: tops-20 at SU-SCORE What is the best way that one can learn RSX20F (masochistic, I know), and the details of FE hacking? Is this taught in any DEC classes ? Is the 'RSX20F System Reference Manual' the only documentation? Is "hands-on" experience the only way? I would really appreciate any advice people can give on the best way to become a FE hacker. Unfortunately, we are embarking on this dastardly journey. Thanks, Ed ------- 23-Nov-81 10:32:11-EST,1044;000000000010 Mail-from: SU-SCORE rcvd at 23-Nov-81 1032-EST Mail-from: ARPANET site BBND rcvd at 23-Nov-81 0722-PST Date: 23 Nov 1981 1024-EST From: EONEIL at BBND Subject: re: How to do a refresh To: tops-20 at SU-SCORE I was horrified to see DUMPER's SUPERCEDE ALWAYS in this authoritative document. It was the cause of our worse restore ever. It forces files from tape to disk regardless of write dates, etc., changing generation numbers as necessary to do it. For example, a busy MAIL.TXT gets written to each incremental, and all these copies come back. I had to clean up multiple copies for 700 mailboxes on the system before we could bring up the system (mail would have been delivered to the wrong copy), and then we had to restore most important directories over again. The massive duplication meant we ran out of disk space and had to delete many directories: SUPERCEDE ALWAYS + INCREMENTALS =>DISASTER! We had already installed a SUPERCEDE UNLESS option which attempts to do a better job than SUPERCEDE OLDER, the 23-Nov-81 12:07:05-EST,895;000000000000 Mail-from: SU-SCORE rcvd at 23-Nov-81 1206-EST Mail-from: ARPANET site RUTGERS rcvd at 23-Nov-81 0903-PST Date: 23 Nov 1981 1143-EST From: WATROUS at RUTGERS (Don Watrous) Subject: re: How to do a refresh To: EONEIL at BBND, tops-20 at SU-SCORE In-Reply-To: Your message of 23-Nov-81 1024-EST If you specify RESTORE X:<*>*.*.* X:<*>*.*.*, you won't get duplicate copies of MAIL.TXT and the like. (DUMPER's default output in this case is <*>*.*.-1, which \will/ change generation numbers and create duplicate copies of files which have been updated using the same generation number.) Still in this case, files which were on the disk at the time of the full dump, but not at the time of the incremental will reappear. (We're trying to figure a way around this now, by somehow keeping a list of files which either did or did not exist at the time of the imcremental.) ------- 23-Nov-81 17:10:21-EST,1116;000000000000 Mail-from: SU-SCORE rcvd at 23-Nov-81 1710-EST Mail-from: ARPANET site RUTGERS rcvd at 23-Nov-81 1400-PST Date: 23 Nov 1981 1337-EST From: HEDRICK at RUTGERS (Mngr DEC-20's/Dir LCSR Comp Facility) Subject: re: How to do a refresh To: EONEIL at BBND cc: tops-20 at SU-SCORE In-Reply-To: Your message of 23-Nov-81 1024-EST No, the idea is supercede always restore <*>*.*.* <*>*.*.* This forces the same generation numbers to be used on the output as the input. Without the explicit output spec, it default to restore <*>*.*.* <*>*.*.-1, which gave the problem you observed. I typically update files in place, i.e. without bumping the generation number. It sounds like in your system I would not get the new version from the incremental. Is that true? ------- NET-MAIL-FROM-HOST:SRI-NIC SU-SCORE g.bets Mail-from: ARPANET site SRI-NIC rcvd at 23-Nov-81 1400-PST Date: 23 Nov 1981 1128-PST From: Francine Perillo Subject: Last Thursday night To: g.bets at SU-SCORE cc: kdo at SU-SCORE Had a great time with you both last week. Love, Fran ------- 24-Nov-81 11:06:33-EST,548;000000000000 Mail-from: SU-SCORE rcvd at 24-Nov-81 1106-EST Mail-from: ARPANET site DEC-MARLBORO rcvd at 24-Nov-81 0803-PST Date: 24 Nov 1981 1102-EST From: Larry Campbell To: EONEIL at BBND, tops-20 at SU-SCORE Postal-address: "73 Concord St., Maynard, Mass. 01754" Subject: re: How to do a refresh Message-ID: <"MS5(2026)+GLXLIB1(1056)" 11778829421.26.71.10241 at DEC-MARLBORO> Regarding: Message from EONEIL at BBND of 23-Nov-81 1024-EST The letter C does not appear in the correct spelling of SUPERSEDE. -------- 24-Nov-81 15:33:44-EST,1256;000000000001 Mail-from: SU-SCORE rcvd at 24-Nov-81 1533-EST Mail-from: ARPANET site RAND-AI rcvd at 24-Nov-81 1220-PST Date: 24 Nov 1981 1220-PST Sender: WESCOURT at RAND-AI Subject: J0NRUN after ^ECEASE From: Keith Wescourt Reply-To: Wescourt at RAND-AI To: TOPS-20 at SCORE Message-ID: <[RAND-AI]24-Nov-81 12:20:58.WESCOURT> Frequently, after issuing a ^ECEASE in advance (more than an hour) of a shutdown, we have had the system stop with a J0NRUN BUGHLT and automatically reboot itself. When it has happened before, it usually occurred within a few minutes of the scheduled shutdown, so that users were seldom effected. Today, it happened 30 minutes before the shutdown and did affect users adversely. Has anyone seen this before, and if so is there a known fix? We have the following DDT auto patch, supplied by DEC, installed in our monitor. We are not a source site, so I can't determine what it is supposed to do or whether it bears on the types of JONRUN problems I've described. <4-PATCHES>J0NRUN-RSX20F-KL-4-MON.ATO.1 ;;;;;SPR# 20-14651,EDIT# 240,SD 15-OCT-80 ;;;;; FOR KL ONLY CONN A ENA GET MONITR ST 140 DTESRV: DTEQ12+31/JRST FFF SKIPN NSKED SKIPN FORKX JRST DTEQ12+32 JRST DTEQ12+33 FFF: ^Z SAVE ^X 24-Nov-81 16:55:38-EST,773;000000000001 Mail-from: SU-SCORE rcvd at 24-Nov-81 1655-EST Date: 24 Nov 1981 1350-PST From: Mark Crispin Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Subject: Re: J0NRUN after ^ECEASE To: Wescourt at RAND-AI, TOPS-20 at SU-SCORE In-Reply-To: Your message of 24-Nov-81 1220-PST Keith - You need one of the various patches to SOBE% to return output buffer non-empty if a TTMSG is pending on an NVT. The problem is that fork 0 is trying to deliver a TTMSG to an NVT and it is getting hung doing so because TTMSGs don't start output on release 4. Actually, a better idea is to have timeouts on TTMSGs, but that may be too difficult to patch. -- Mark -- ------- 24-Nov-81 17:09:43-EST,824;000000000000 Mail-from: SU-SCORE rcvd at 24-Nov-81 1709-EST Mail-from: ARPANET site SANDIA rcvd at 23-Nov-81 1351-PST Date: 23 Nov 1981 1231-MST From: Norm Samuelson Subject: TOPS-20 hang To: mrc at SANDIA Remailed-date: 24 Nov 1981 1403-PST Remailed-from: Mark Crispin Remailed-to: TOPS-20 at SU-SCORE I have been experiencing a problem in TOPS-20 which I have not been able to figure out yet. Lots of jobs have been hung trying to logout. The terminal is dead. At the same time, ORION is hung in an i/o wait doing a TTMSG at SNDTTY+2. Is there any way to look at the ACs of a SYSJOB fork? I would like to know what ORION is trying to tell me. Or should I run ORION over a PTY so I can talk to it? Any suggestions or hints would be appreciated. - Sam - ------- 1-Dec-81 22:05:00-PST,2293;000000000000 Mail-from: ARPANET site RUTGERS rcvd at 1-Dec-81 2153-PST Date: 2 Dec 1981 0045-EST From: WATROUS at RUTGERS (Don Watrous) Subject: More on archiving speedup To: Tops-20 at SU-SCORE Some modifications to the archiving speedup I sent to this mailing list a while back: First of all, I seem to have dropped a signifigant 0 while stealing code from the mailer. In DUMPER at OPNFL1-3 and PASS2A-4, and in EXECIN at FLGLUP-1, MOVSI ac,-100 should be changed to MOVSI ac,-1000. (Has anybody but Randy Frank noticed that some directories weren't getting archived?) Also pointed out by Randy: It was possible to rename a file being archived to a directory which wasn't flagged in ARCHIVE-REQUESTS.BIN. The solution, simply enough, was to check if the file being renamed was panding archive, and if so flag the target directory in A-R.BIN. Unfortunately, the monitor was very sensitive to where the code was placed, and DDT was uncooperative with the debugging effort, so it took me a while to get it right. (Does anybody either have or plan on a DDT which works in sections other than 0?) Anyway, if you've already installed the code, a difference file of new changes follows. (If you still haven't put in the changes, I've updated the files here on , so pick up a fresh copy!) Don File 1) JSYSF.MAC.28,25-Nov-81 03:28:14 File 2) JSYSF.MAC.23,13-Oct-81 10:49:08 [At FLAGIT+2] 1)6 jrst flagi0 1) flagt2: stkvar > 1) xctu [ move t1,2] ; get jfn 1) flagi0: movem t1,filjfn **** 2)6 movem t1,filjfn ************** [At .RNAMF+1] 1)116 trvar 1) CAMN 1,2 ;BE SURE NOT SAME JFN **** 2)116 CAMN 1,2 ;BE SURE NOT SAME JFN ************** [At .SACTF-8 (after CALL @REND and ERUNLK)] 1)116 move jfn,(p) ; get new jfn 1) call getfdb ; get fdb for same 1) erunlk(,) 1) load a,fbbbt,(a) ; get bits 1) movem a,arcbts ; save'm here 1) call ustdir ; free directory 1) POP P,JFN **** 2)116 POP P,JFN ************** [And a few lines down...] 1)116 move a,arcbts ; get saved bits 1) txne a,ar%rar!ar%riv ; file going away? 1) call flagt2 ; yes, flag it 1) AOS -1(P) **** 2)116 AOS -1(P) ************** ------- 2-Dec-81 10:21:15-PST,1822;000000000000 Mail-from: ARPANET site RUTGERS rcvd at 2-Dec-81 1010-PST Date: 2 Dec 1981 1305-EST From: WATROUS at RUTGERS (Don Watrous) Subject: Hold the presses on archiving speedup To: Tops-20 at SU-SCORE The patch for RNAMF to mark ARCHIVE-REQUESTS.BIN for archived files I sent out this morning has a bug in it. In order to do a skip return, the RNAMF jsys manipulates the stack directly, then JRSTs to MRETN rather than use the routine SKMRTN which was set up for just that purpose. My introduction of the TRVAR sabotaged RNAMF's bogus return. (The EXEC didn't suffer from RNAMF not skipping, since it uses ERJMP.) The corrected differences follow. This patch has been tried in MDDT, the source is being assembled right now. Don File 1) JSYSF.MAC.28,25-Nov-81 03:28:14 File 2) JSYSF.MAC.23,13-Oct-81 10:49:08 [At FLAGIT+2] 1)6 jrst flagi0 1) flagt2: stkvar > 1) xctu [ move t1,2] ; get jfn 1) flagi0: movem t1,filjfn **** 2)6 movem t1,filjfn ************** [At .RNAMF+1] 1)116 trvar 1) CAMN 1,2 ;BE SURE NOT SAME JFN **** 2)116 CAMN 1,2 ;BE SURE NOT SAME JFN ************** [At .SACTF-8 (after CALL @REND and ERUNLK)] 1)116 move jfn,(p) ; get new jfn 1) call getfdb ; get fdb for same 1) erunlk(,) 1) load a,fbbbt,(a) ; get bits 1) movem a,arcbts ; save'm here 1) call ustdir ; free directory 1) POP P,JFN **** 2)116 POP P,JFN ************** [And a few lines down...] 1)116 move a,arcbts ; get saved bits 1) txne a,ar%rar!ar%riv ; file going away? 1) call flagt2 ; yes, flag it 1) smretn ; have to clear up from TRVAR 1)117 ; Set account for file **** 2)116 AOS -1(P) 2) JRST MRETN 2)117 ; Set account for file ************** ------- 3-Dec-81 11:34:12-PST,649;000000000001 Mail-from: ARPANET site UTEXAS-20 rcvd at 3-Dec-81 1122-PST Date: 3 Dec 1981 1318-CST From: Edward C. Pattermann Subject: Owners of directories To: tops-20 at SU-SCORE I want TOPS-20 to identify the owner of a sub-directory to be the owner of the top-level directory. For example, my login dir is PATTERMANN. If I create a sub-dir called PATTERMANN.LISP, TOPS-20 does not give me owner access to PATTERMANN.LISP, although that is what makes sense in this case. Does anyone know of a way I can make this happen? Is there a patch that will work? Is there something here I am missing? Thanks, Ed ------- 3-Dec-81 13:03:23-PST,2014;000000000000 Mail-from: ARPANET site RUTGERS rcvd at 3-Dec-81 1248-PST Date: 3 Dec 1981 1544-EST From: WATROUS at RUTGERS (Don Watrous) Subject: Re: Owners of directories To: G.ECP at UTEXAS-20, tops-20 at SU-SCORE In-Reply-To: Your message of 3-Dec-81 1418-EST This patch will allow a user who has connect without password access to a superior directory to connect to any subdirectories of that directory without a password. It still doesn't allow the files to be accessed without connecting to the directory. Hope it's of some use. Don File 1) S:<4-MONITOR>DIRECT.MAC.5,13-Oct-81 10:29:42 File 2) S:<4-MONITOR>DIRECT.DEC.1, 3-Jan-80 08:08:30 1)5 SUPCH0: MOVEM T1,SUPCDN ;SAVE DIRECTORY NUMBER **** 2)5 MOVEM T1,SUPCDN ;SAVE DIRECTORY NUMBER ************** 1)5 HRRZ T3,SUPCSP ;CHECK FOR ROOT-DIRECTORY 1) CAIN T3,ROOTDN ;IF SO, 1) JRST .+5 ; DO RETBAD 1) MOVE T2,SUPCBT 1) MOVE T1,SUPCSP ;CHECK SUPERIORS SUPERIOR 1) CAME T1,SUPCDN ;PREVENT AN INFINITE LOOP 1) JRST SUPCH0 1) RETBAD ;RETURN FAILURE **** 2)5 RETBAD ;RETURN FAILURE ************** File 1) S:<4-MONITOR>JSYSA.MAC.10,24-Oct-81 12:06:27 File 2) S:<4-MONITOR>JSYSA.DEC.1,24-Jan-80 09:45:24 [At ACCES5+4] 1)8 JRST .+2 ; NO, CONTINUE 1) JRST ACCES6 ; YES, PROCEED 1) ULKDIR ; UNLOCK THE DIRECTORY 1) HRR T1,Q2 ; GET DIRECTORY NUMBER 1) HRL T1,P5 ; GET STRUCTURE UNIQUE CODE 1) MOVX T2,DC%CN ; CHECK FOR ABILITY TO 1) CALL SUPCHK ; CONNECT TO SUPERIOR 1) JRST [ MOVEI T1,CNDIX1 ;NO. ASSUME INVALID PASSWORD **** 2)8 JRST [ MOVEI T1,CNDIX1 ;NO. ASSUME INVALID PASSWORD ************** 1)8 MOVEM T1,Q1 ; SAVE ERROR CODE 1) JRST ACCER0] 1) HRR T1,Q2 ; GET DIRECTORY NUMBER 1) HRL T1,P5 ; GET STRUCTURE UNIQUE CODE 1) CALL SETDIR ; RE-MAP THE DIRECTORY 1) RETBAD 1) ACCES6: STOR P5,JSUC ;NO. STORE CONNECTED STRUCTURE UNIQUE CODE **** 2)8 JRST ACCER3] 2) ACCES6: STOR P5,JSUC ;NO. STORE CONNECTED STRUCTURE UNIQUE CODE ************** ------- 5-Dec-81 09:59:53-PST,680;000000000000 Mail-from: ARPANET site SANDIA rcvd at 5-Dec-81 0947-PST Date: 5 Dec 1981 1046-MST From: Norm Samuelson Subject: XPASCAL - an eXtended Addressing version of PASCAL To: tops20 at SANDIA An extended addressing version of PASCAL, based on Hedrick's PASCAL compiler from Rutgers, is now available. It still has a minor bug or two, but it works for all the test cases I have. If you are interested the source and object files are all in directory XPAS: at SANDIA. Please read XPASCAL.DOC in that directory for more info. Please send any bug reports to Samuelson@SANDIA. I hope to have all known bugs out of it by New Years. - Sam - ------- 5-Dec-81 17:06:32-PST,769;000000000000 Mail-from: ARPANET site MIT-XX rcvd at 5-Dec-81 1656-PST Date: 5 Dec 1981 1956-EST From: Nat Mishkin Subject: Re: Owners of directories To: G.ECP at UTEXAS-20, tops-20 at SU-SCORE In-Reply-To: Your message of 3-Dec-81 1418-EST I have a patch to DIRECT which gives you owner access to subdirectories (i.e. the directory AND its contents) of both your login and connected directory. It makes life much nicer especially when you really use subdirectories heavily. I can't embed the patch in this msg since I'm here via a guest acct. I can supply a paper listing to anyone interested. Alternatively, you can wait until I (Yale) get on the net (hopefully within the next month). -- Nat Mishkin Yale Comp. Sci. Dept. ------- 6-Dec-81 05:27:26-PST,1248;000000000000 Mail-from: ARPANET site CMU-20C rcvd at 6-Dec-81 0521-PST Date: 6 Dec 1981 0818-EST From: WOHL at CMU-20C Subject: Re: Owners of directories To: NWM at MIT-XX, G.ECP at UTEXAS-20, tops-20 at SU-SCORE In-Reply-To: Your message of 5-Dec-81 1956-EST We made a change to direct to DIRECT here at CMU to allow users to give out owner access the same way group access is given. The 400000 bit in directory group numbers to give owner access. Clexec has an owner command that is the same as the directory-group command but turns on the 400000 bit for you, I DIR lists owners and directory group numbers seperatly so evan though it is a hack it looks nice to users. The redit is [cmuc]ps:DIRECT.DIF. It has two other changes: a) User group membership information is always looked up in the PS: list for domestic structures rather than the list for that structure. The idea here is that if you move some big project directory off of PS: you don't have to give everyone in the project a directory on the new structure just so they can access it. b) Dave put in a bunch of code to print out more information on DIRxxx bugchecks to help in diagnosing directory problems. Aaron ------- 9-Dec-81 00:36:29-PST,11833;000000000001 Mail-from: ARPANET site RUTGERS rcvd at 9-Dec-81 0017-PST Date: 9 Dec 1981 0307-EST From: HEDRICK at RUTGERS (Mngr DEC-20's/Dir LCSR Comp Facility) Subject: problems with dropped interrupts from disk; shared disks To: tops-20 at SU-SCORE The enclosed patch is for a somewhat subtle problem. Thus this is going to be an extremely long explanation. If you are not interested in reading it all, here is a synopsis: problem: all transfers hang on a disk drive which is shared between systems. (Note that this is an unsupported use of Tops-20.) Possible J0NRUN's in some cases even on standard systems, due to contention for PS0: between Tops-20 and the front end. diagnosis: (1) code in PHYH2 is unable to handle more than one attention interrupt at the same time. (2) hardware does not do what the code at RP4CON assumes it does. (3) race condition when code at RP4CON takes branch to RP4CN2 cure: the following patches. Now here are the gory details: We developed some software that uses a shared disk drive to transfer files and mail between two Tops-20 systems. The drive is mounted on one system, but not on the other, since the monitor can't handle sharing of file systems. The transfers are done using the DSKOP jsys to read and write pages into the swapping area. DSKOP does not require the drive to be mounted. Anyway, in the course of this we are trying to access the same drive from two different systems. There is monitor code to support this, as long as you don't try to share the file system. The code is normally used for sharing PS: volume 0 between Tops-20 and the front end. Before using the drive, the system that wants it "seizes" the drive. It then releases it when it is finished. If system A tries to seize the drive when system B has it, the hardware remembers the request. When the drive is freed by the system B, it is automatically allocated to system A, and an attention interrupt is generated to system A, so that the software knows it can proceed to use the drive. If a system seizes the drive and does not release it, the seizing times out after 1 second. The problem was that now and then one of the systems would "hang". I.e. all programs attempting to access the shared drive would go into I/O wait, and could not be ^C'ed. It appeared that the system had tried to seize the drive when the other system had it, but had failed to get the word when the drive was freed. We conjecture that if this had happened with PS: (which it could due to competition between Tops-20 and RSX-20F), you would get a J0NRUN. The first theory was that something was wrong with the hardware such that it did not seize the drive as documented. SRI and DEC seem to agree that one of the documented methods of seizing a drive (reading the control register) does not work all the time. They proposed a change to the code in PHYP4 that uses a different way of seizing the drive (writing to an illegal register) that seems to work all the time. I have been unable to verify that this problem happens at Rutgers. However I did find two software problems that could result in similar situations. One was a race condition in the code that handled the situation where the drive could not be seized. Fortunately the fix proposed by SRI and DEC for the hardware problem also fixes this race condition. The other problem is more complex. It turns out that it is possible to get attention interrupts for more than one unit on a given channel at the same time. Such interrupts apparently can mean any one of a number of things: that a seek is finished, that a transfer is finished, that a drive has gone on or off line, and (what is relevant here) that a shared drive which was previously seized by the other system has now become available to this system. I will refer to this as a "seize done" condition. Of these various kinds of attention interrupts, drive on line and drive off line can be processed locally by the low-level routine that diagnoses the interrupts. However seek done, transfer done, and seize done all require new I/O operations to be started, and so must be processed by the top-level module (PHYSIO). But the design of the code is that PHYSIO calls the interrupt handler, which returns a flag and some other data giving it at most one task to carry out. The effect is that if more than one of these done conditions occurs (on different drives) at the same time, only one is actually processed. I have no idea what the effects of this are on seek done and transfer done. However when a seize done lost the competition as to which should be processed, the result was that the drive became unusable. The low-level interrupt routine had marked it available, but PHYSIO lost the command to restart I/O. The real solution is to rewrite the relevant routines in PHYSIO and PHYH2 to process multiple interrupts at the same time. I have adopted a less elegant solution, but one which appears to work. There is a piece of code in PHYSIO that looks at each drive on the system one a second to see whether it needs any help. (This is the routine that prints %PROBLEM ON DEVICE ... .) If it finds a drive that was previously noted as unavailable, but which has just become available, it restarts pending I/O requests for that drive. This is just what we need done after we manage to get the shared drive. In fact when PHYP4 first discovers that it can't get the drive (at RP4CON), it does set the status bits in UDBSTS such that this once-per-second code will look at the drive. That would be sufficient, although it would result in relatively slow recovery of the drive. However when the seize done interrupt occurs, RP4ATU clears these bits, since it believes that the drive is now available, and that PHYSIO will restart the I/O on it. Thus if the interrupt is not handled, due to several interrupts interfering, the once per second code will not rescue the situation, since the bits that cause this code to look at the drive have been cleared. The solution I have adopted is to have RP4ATU not clear the unavailable bits. (Indeed I have RP4ATU verify that they are set.) Rather, I move the clearing of the bits up into NOATTN (in PHYH2), where it is finally determined that the interrupt is going to be handled properly. Thus in the case where the interrupt cannot be handled, the bits are still set in such a way that the once per second code rescues us. If this seems overly complex, the obvious alternatives do not work: - you might think we could just leave the unavailable bits set in all cases. However these bits would interfere with PHYSIO's attempt to restart I/O in the situation where it *is* able to handle the interrupt - you might think that we could simply ignore the seize done interrupts completely, and depend upon the once per second code to restart I/O in all cases. The problem with this is that it would badly slow down thruput with this disk. When the drive was being heavily used on both systems, we had a situation where exactly one disk access happened on each system each second. This is clearly too high a performance penalty. We need the interrupt handling in the cases where it works, in order to get reasonable performance. So the following patch moves the clearing of the unavailable bit up into PHYR2, where it is finally determined that the seize done is going to be handled. There is one remaining problem: The original code simply set LH(Q1) as a flag that something needed to be done. Unfortunately, by the time we get to the code in PHYR2, we can no longer tell which unit the request is for. The code there assumes that the request is for the most recent unit examined, and that the AC's are still set up for it. If there is more than one interrupt, this need not be the case. So we put the unit number + 1 into LH(Q1) as the flag. This allows us to check whether the AC's still have data pertaining to this unit. If not, we simply ignore the request and let the once per second code handle it. (The unit number + 1 is used to avoid a zero value, which would indicate nothing to do.) File 1) PHYH2.MAC.4, 8-Dec-81 23:26:40 File 2) PHYH2.MAC.1, 3-Jan-80 08:10:11 1)17 CAIG P4,0 ;[221] 1,,0 -special from RP4ATU 1) RETSKP ;AND LET PHYSIO DO ITS THING 1) ;[221] all of the code here is needed because the code here 1) ;[221] is unable to do anything interesting for more than one unit 1) ;[221] at a time. We could get attn done from one and another 1) ;[221] interrupt from another. The code here is designed to handle 1) ;[221] the case where RP4ATU has found that a shared drive is now 1) ;[221] available. Its sets Q1 to indicate that we should ask 1) ;[221] PHYSIO to restart I/O on that drive. This is fine, but if 1) ;[221] another kind of interrupt happened at the same time, it is 1) ;[221] possible that we will go to XFR and handle it, or that 1) ;[221] P1 could now be pointing to the UDB of a different unit. 1) ;[221] Thus the code here is designed to make sure that we are still 1) ;[221] set up for the same unit that RP4ATU found. If so, we set P4 1) ;[221] to -1, which is a flag to PHYINT to continue I/o on the unit. 1) ;[221] if not, we clear P4. In this case we are ignoring the fact 1) ;[221] that the shared drive is now available. Since the US.OIR 1) ;[221] bit is still set, the once a second code will eventually notice 1) ;[221] that the drive is back and restart I/O. RP4ATU set LH(Q1) to 1) ;[221] unit number+1. The +1 is to guarantee that it is non-zero, 1) ;[221] since zero is a null request. 1) HLRZ P4,Q1 ;[221] get unit number+1, from RP4ATU request 1) ADD P4,P1 ;[221] access below is CDBUDB+.P4-1(P1) 1) CAME P3,CDBUDB-1(P4) ;[221] compare current unit with RP4ATU's 1) JRST [ SETZ P4, ;[221] wrong unit, forget request 1) RETSKP] ;[221] 1) MOVSI T1,(US.OFS!US.OIR!US.OMS) ;[221] this is going to work, so 1) ANDCAM T1,UDBSTS(P3) ;[221] clear bits saying we're in trouble 1) SETO P4, ;[221] now ask for continuing I/O 1) RETSKP ;[221] from PHYINT 1) XFR: TRNN T1,CI.DON ;IS CONTROLLER BUSY? **** 2)17 RETSKP ;AND LET PHYSIO DO ITS THING 2) XFR: TRNN T1,CI.DON ;IS CONTROLLER BUSY? ************** File 1) PHYP4.MAC.5, 8-Dec-81 23:16:08 File 2) PHYP4.MAC.1, 3-Jan-80 08:10:13 1)9 RP4CON: MOVSI T2,DO.DT ;[221] WRITE RANDOM REGISTER - SIEZE PORT 1) CALL WTREG ;[221] IF IN A/B MODE 1) MOVSI T2,DO.DRC ;READ CONTROL REGISTER - SEE IF WE GOT IT 1) CALL RDREG ; IF IN A/B MODE **** 2)9 RP4CON: MOVSI T2,DO.DRC ;READ CONTROL REGISTER - SIEZE PORT 2) CALL RDREG ; IF IN A/B MODE ************** at RP4CN2+?? 1)9 ;[221] MOVSI T2,DO.DRC ;PICK A REGISTER TO WRITE 1) ;[221] CALL WTREG ;WRITE IT TO INDICATE ACCESS DESIRED 1) RET ;WE'LL BE INTERRUPTED WHEN DRIVE AVAILABLE **** 2)9 MOVSI T2,DO.DRC ;PICK A REGISTER TO WRITE 2) CALL WTREG ;WRITE IT TO INDICATE ACCESS DESIRED 2) RET ;WE'LL BE INTERRUPTED WHEN DRIVE AVAILABLE ************** 1)13 ;[221] device is now ours. But the code in PHYH2 may not be able to 1) ;resume the transfer. If not, will have to depend upon the operator 1) ;intervention stuff to do so. 1) RP4ATU: MOVX T1,US.OIR!US.OMS ;[221] DEVICE IS NOW OURS AGAIN, BUT ASSUME 1) IORM T1,UDBSTS(P3) ;[221] the worst - will need UNICHK to resume 1) HRLI Q1,1(Q1) ;[221] flag this special case for PHYH2 1) JRST ATNXIT ;JOIN COMMON EXIT **** 2)13 RP4ATU: MOVX T1,US.OFS!US.OIR!US.OMS ;DEVICE IS NOW OURS AGAIN 2) ANDCAM T1,UDBSTS(P3) ;SO MAKE UNIT ONLINE AGAIN 2) TLO Q1,-1 ;SET TO RESTART I/O 2) JRST ATNXIT ;JOIN COMMON EXIT ************** ------- 10-Dec-81 09:29:23-PST,718;000000000000 Mail-from: ARPANET site CIT-20 rcvd at 10-Dec-81 0918-PST Date: 10 Dec 1981 0918-PST From: DICK at CIT-20 Subject: Domestic Structure Access To: TOPS-20 at SU-SCORE I found, to my dismay and amazement, that the monitor does not recognize any correspondence between user group numbers and directory group numbers on domestic structures. I would imagine that this simple, yet basic, problem would have been noticed and fixed long ago by some of you folk out there. I presume that there exists a source mod for DIRECT.MAC that corrects this oversight in DIRCHK and/or ACCCHK. If anyone knows of such a fix I would appreciate a pointer to it. Patches are welcome too. Dick Lang ------- 10-Dec-81 15:43:59-PST,462;000000000000 Mail-From: ADMIN.MRC created at 10-Dec-81 15:28:17 Date: 10 Dec 1981 1528-PST From: Mark Crispin Subject: MPW program To: TOPS-20 at SU-SCORE Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Does anybody have the source for the MPW program? It generates pronouncable random strings for use as passwords. Please reply to EIBEN@DEC-MARLBORO. ------- 12-Dec-81 15:53:58-PST,1034;000000000000 Mail-from: ARPANET site SANDIA rcvd at 12-Dec-81 1545-PST Date: 12 Dec 1981 1644-MST From: Norm Samuelson Subject: Extended Addressing To: tops20 at SANDIA DEC is VERY interested in Extended Addressing. At DECUS they said that FORTRAN is their highest priority software engineering project, and that extended addressing support was definitely planned as part of the next release after v6. DEC has asked me to create a mailing list of users with an interest in extended addressing. If you want to be on that mailing list please let me know as soon as possible. The list will probably turn out to be a large subset of the TOPS20 mailing list at SCORE, but DEC specifically askd for another list, so that is what they will get. Also, it is already time to start planning for the next DECUS, which will be in Atlanta in May. I think it would be useful to have a session on extended addressing applications. If you would be interested in taking part please let me know. - Sam - ------- 12-Dec-81 16:40:04-PST,542;000000000000 Mail-from: ARPANET site SANDIA rcvd at 12-Dec-81 1633-PST Mail-from: ARPANET site UTAH-20 rcvd at 12-Dec-81 1728-MST Date: 12 Dec 1981 1727-MST From: Randy Frank Subject: Re: Extended Addressing To: Samuelson at SANDIA, tops20 at SANDIA In-Reply-To: Your message of 12-Dec-81 1644-MST I think Norm misunderstood DEC's statement on Fortran. I understood that next release after v6 will be Fortran 77, and release after that (r8) will be extended addressing. Anyone else who was there care to comment? ------- 12-Dec-81 21:26:14-PST,977;000000000000 Mail-From: ADMIN.MRC created at 12-Dec-81 21:15:12 Date: 12 Dec 1981 2115-PST From: Mark Crispin Subject: Re: Domestic Structure Access Sender: ADMIN.MRC at SU-SCORE To: DICK at CIT-20, TOPS-20 at SU-SCORE Reply-To: Admin.MRC at SU-SCORE Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) In-Reply-To: Your message of 10-Dec-81 0918-PST It is not a bug that groups are different across domestic structures, it is a feature. The idea of structures are that each should be allowed to have independent groups. Domestic vs. foreign means that FOO is the owner of BAR: as well as PS:. By doing ACCESS BAR: she can get the user groups that BAR: has the right for. It is a trivial routine in your ACJ to implementing global user groups, at least in so far as CONNECT/ACCESS works. Look at MRC:ACJ.MID for how SCORE's ACJ does it. -- Mark -- ------- 16-Dec-81 12:34:59-PST,580;000000000000 Mail-from: ARPANET site SUMEX-AIM rcvd at 16-Dec-81 1220-PST Date: 16 Dec 1981 1220-PST From: Eric Schoen Subject: Page mapping question To: tops-20 at SU-SCORE Can someone tell me why when I map a private page in a process into a page in a file, the process page disappears? This is not consistent with Tops-20's behavior in mapping pages from files into processes (i.e. the file page doesn't disappear). I can get around this problem by mapping the file page back into the process, but I think that should be unnecessary. Eric ------- 16-Dec-81 15:39:11-PST,583;000000000000 Mail-from: ARPANET site RUTGERS rcvd at 16-Dec-81 1525-PST Date: 16 Dec 1981 1823-EST From: Roy Marantz Subject: REFUSE SYSTEM-MESSAGES for terminals To: tops-20 at SU-SCORE Does anyone have a way to have some terminals set up so that they are by default refusing system-messages? We have a graphics display which should be set up that way and I noticed that when a tty line is reset (ie a job starts on it or a jfn is opened for the "first time") the monitor sets up the line to terminal type system-default.... Any ideas or help? Roy ------- 16-Dec-81 17:02:42-PST,422;000000000000 Mail-from: ARPANET site RUTGERS rcvd at 16-Dec-81 1651-PST Date: 16 Dec 1981 1948-EST From: Roy Marantz Subject: Re: REFUSE SYSTEM-MESSAGES for terminals To: Admin.MDP at SU-SCORE cc: tops-20 at SU-SCORE In-Reply-To: Your message of 16-Dec-81 1941-EST What is TTYINI? Also I don't think it will help because the monitor resets these parameters each time the line is reset. Roy ------- 16-Dec-81 17:02:50-PST,477;000000000000 Mail-From: ADMIN.MDP created at 16-Dec-81 16:41:55 Date: 16 Dec 1981 1641-PST From: Mike Peeler Subject: Re: REFUSE SYSTEM-MESSAGES for terminals To: MARANTZ at RUTGERS cc: tops-20 at SU-SCORE In-Reply-To: Your message of 16-Dec-81 1523-PST Roy, One way would be, if your system runs TTYINI on job startup, to add switches to it for receiving and refusing, and put the appropriate settings into SYSTEM:TTYINI.CMD. - mdp - ------- 17-Dec-81 07:01:33-PST,680;000000000000 Mail-from: ARPANET site AFSC-HQ rcvd at 17-Dec-81 0652-PST Date: 17 Dec 1981 0945-EST From: Chuck Perilli Postal-address: HQ AFSC/ACDPS, Andrews AFB, DC 20334 Phone: (301)981-4002; AUTOVON: 858-4002 Subject: Re: REFUSE SYSTEM-MESSAGES for terminals To: MARANTZ at RUTGERS cc: : ; In-Reply-To: Your message of 16-Dec-81 1948-EST What we did here was add the code to refuse system messages in the initialization routine of each of the graphics packages we use. Most graphics software has some initialize or startup routine that must be called before any other routines. This is not a very elegant fix, but it works. ---Chuck ------- 17-Dec-81 14:59:27-PST,246;000000000000 Mail-From: G.ELDRE created at 17-Dec-81 14:44:20 Date: 17 Dec 1981 1444-PST From: Tim Eldredge Subject: ADA for TOPS-10/20 To: tops-20 at SU-SCORE Does anyone have an ADA compiler/interpreter for the 10/20? ------- 17-Dec-81 15:25:38-PST,353;000000000000 Mail-from: ARPANET site SRI-KL rcvd at 17-Dec-81 1459-PST Date: 17 Dec 1981 1535-PST From: Richard R. Cower Subject: Re: ADA for TOPS-10/20 To: g.eldre at SU-SCORE, tops-20 at SU-SCORE cc: COWER at SRI-KL, kennard at SRI-KL In-Reply-To: Your message of 17-Dec-81 1444-PST yes...give me a call. 859-6336. ..rich ------- 17-Dec-81 15:25:39-PST,713;000000000000 Mail-from: ARPANET site RADC-TOPS20 rcvd at 17-Dec-81 1500-PST Date: 17 Dec 1981 1838-EST From: Mark Pratt To: g.eldre at SU-SCORE, tops-20 at SU-SCORE Reply-to: Pratt at RADC-TOPS20 Telephone: 315-330-4013 Subject: Re: ADA for TOPS-10/20 Message-ID: In-reply-to: Message from Tim Eldredge of 17-Dec-81 1744-EST We have an ADA compiler. It came from ECLB and is being developed by a contractor out there. I don't have a contact name but if you want I can find out for you. I don't really have anything to do with it but can find out from a user on my system. --Mark -------- 18-Dec-81 11:47:15-PST,521;000000000000 Mail-from: ARPANET site SRI-KL rcvd at 18-Dec-81 1137-PST Date: 18 Dec 1981 1002-PST From: Richard R. Cower Subject: ADA compiler To: tops-20 at SU-SCORE I"ve had more requests for this information than I care to answer individually. The ADA compiler I know of is from a company called INTERMETRICS, located somewhere in Mass. The contact there is Mike Ryer. It is written in SIMULA. I found out about it last week at a DOD meeting at DECUS, chaired by Lloyd Snow. ..Rich Cower ------- 18-Dec-81 13:28:37-PST,286;000000000000 Mail-from: ARPANET site SRI-KL rcvd at 18-Dec-81 1318-PST Date: 18 Dec 1981 1304-PST From: ROODE at SRI-KL (David Roode) Subject: Intermetrics address To: tops-20 at SU-SCORE 733 Concord Avenue Cambridge MA 02138 617 661 1840 I believe this is the ECLB compiler too. ------- 18-Dec-81 15:55:01-PST,492;000000000000 Mail-from: ARPANET site SRI-KL rcvd at 18-Dec-81 1539-PST Date: 18 Dec 1981 1538-PST From: Chris Ryland Subject: Re: Intermetrics address To: ROODE at SRI-KL, tops-20 at SU-SCORE In-Reply-To: Your message of 18-Dec-81 1304-PST Note that the Intermetrics Ada compiler is a toy compiler, and is also the world's slowest piece of software: it is written in Simula, compiles Ada to an internal tree language, and then interprets that (general) language. ------- 18-Dec-81 20:27:07-PST,3569;000000000000 Mail-From: ADMIN.MRC created at 18-Dec-81 20:18:39 Date: 18 Dec 1981 2018-PST From: Mark Crispin Subject: new release of MM/XMAILR/XMAILBOX Sender: ADMIN.MRC at SU-SCORE To: TOPS-20 at SU-SCORE cc: MMcM at SU-SCORE Reply-To: Admin.MRC at SU-SCORE Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) A major release of the MM mailsystem is hereby announced, with several functionality improvements and bugfixes. The bugfixes are especially important to anybody who has an MM with a version number above 650 or so. This release is MM version 663 (version of 12/18/81); accompanying it are XMAILR version 481 (version of 12/5/81) and XMAILBOX version 112 (version of 12/14/81). Among the interesting changes are: FROM and REPLY-TO commands which allow setting those fields in the message header in a more controlled way than USER-HEADERS allow. FROM sets up a default Reply-To of the alias sender, as well as forcing a Sender line of the physical sender. The SHOW command outputs the current MM.INIT variables to the terminal (it is literally CREATE-INIT redirected to TTY:). This is in response to a number of requests for this functionality. It is planned to get rid of the magic numbers and to have a more selective help facility in this area. MM.CMD is a new initialization file. It is run when MM is invoked as MM (as opposed to "MM SEND" or "MAIL" or "MM READ"). It contains ordinary MM commands. This uses the new MM "TAKE" facility (yes, there is now a TAKE command in MM); essentially, whenever MM is run as MM it does an implicit "TAKE MM.CMD" if the file exists. PS:MM.CMD at SCORE shows what MM.CMD files can be good for. You can have SET commands in MM.CMD, but it is recommended that MM.INIT be used to set MM variables instead (MM.CMD corresponds to EMACS.INIT much as MM.INIT corresponds to EMACS.VARS). A site-selectable option allows the system to select MM's style of file I/O; either by page-mapping the mail file in or by keeping a private copy in memory. Page-mapping is faster and cheaper on disk space (the private copy method requires twice as much space), although somewhat more dangerous if the system crashes at an awkward time. MM currently uses the page-mapping mechanism by default; some Tenex sites must use the private copy mechanism. We are working on making MM more careful to keep the disk copy consistant at all times. The next two changes apply only to sites which use the XMAILR mailer daemon instead of NMAILR: XMAILR now has code to write the origin of the message in a Mail-From: line for local recepients if the origin was not FTPSER (e.g. its writer is not OPERATOR). This is a modest attempt at message security but at the same time not get in the way of useful functionality (such as ALIAS). XMAILBOX has some code to protect itself against garbage indirect files (files with bad byte counts confused the hell out of it). I urge all MM sites to install this new release, which is located on MRC:*.MAC at SU-SCORE. Please report any problems with the new release by using MM's BUG command. If there are any local changes to MM which you have made but are not in this version, please try to get those changes to me. The best way to get your changes installed in the official MM is to send me a copy of the current SCORE MM.MAC (or MM.FAI) with your changes edited in. -- Mark -- ------- 21-Dec-81 10:04:56-PST,679;000000000000 Mail-From: G.TJM created at 21-Dec-81 09:46:04 Date: 21 Dec 1981 0946-PST From: Ted Markowitz Subject: Setting duplex To: tops-20 at SU-SCORE This question is in the same vein as the one on refusing messages. I'd like to have the monitor bring up jobs on specific ports as line-half-duplex. This will be used to help connect us to an SNA-network (don't laugh too hard... it wasn't my idea). So far the connections have been made (well sort of) but, the software in the IBM boxes chokes on full-duplex talking back to it. I've never heard of TTYINI either but, does it provide some functionality that would help in this case? --ted ------- 30-Dec-81 19:25:18-PST,277;000000000000 Mail-from: ARPANET site CIT-20 rcvd at 30-Dec-81 1906-PST Date: 30 Dec 1981 1906-PST From: Barry Megdal Subject: fortran-77 To: tops-20 at SU-SCORE Is an implementation of fortran-77 available for DEC-20's, and if so, from where? Thanks. -------