.NONUMBER .LM 0 ^PY^- .PAGE SIZE 58,85 .LM 10 .RM 75 .NO FILL .NO JUSTIFY # .SKIP 5 ^IC0000^IS328^GThe RSX Multi-Tasker^IS204^IC1000^G .SKIP ^IC0000^IS328^GOctober, 1987^IS204^IC1000^G .SKIP .CENTER ##^IS144^G"Every Beer a Wanted Beer ... Every Swig a Healthy Swig"^IS204^G .SKIP .CENTER Fine Realtime Commentary Since 1975 .SKIP 6 .CENTER ^&Table of Contents\& .SKIP 2 .TAB STOPS 65 Food for Thought RSX-1 The Editor's Corner RSX-1 ADA, DEC, DOD, IBM and other TLAs RSX-2 Submitting Articles to the Multi-Tasker RSX-3 And That's The Way Things Are RSX-3 Debugging Overlaid Tasks RSX-4 FCS Multi-Buffering - One of RSX's Best Kept Secrets RSX-7 How to Get That DECUS Support RSX-10 Memory on the PDP-11/44 Unibus RSX-14 More on Monitoring Task Status RSX-22 Rotating Lights for VT100 Terminals RSX-24 Spring 1987 Software Clinic RSX-27 Spring 1987 Symposium Tape Available RSX-31 .JUSTIFY .FILL .SKIP 12 .LM +5 .RM -5 Opinions expressed in the editorial section of the Multi-Tasker are those of the Editor. They do not represent the official position of the RSX SIG or that of DECUS leadership in general. .LM -5 .RM +5 .PAGE .COMMENT .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT Food for Thought .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT # .SKIP 7 .AUTOPARAGRAPH #######################^IC0000^IS328^GFood for Thought^IS204^IC1000^G .SKIP "It is not from the benevolence of the butcher, the brewer, or the baker that we expect our dinner, but from their regard to their own interest. We address ourselves, not to their humanity but to their self-love, and never talk to them of our own necessities but of their advantages." .SKIP 2 .NO FILL .NO JUSTIFY .INDENT 30 ^IS144^G- Adam Smith^IS204^G .RM +10 .INDENT 30 ^IC0000^IS144^G##An Inquiry Into the Nature and Causes of^IS204^IC1000^G .INDENT 30 ^IC0000^IS144^G###the Wealth of Nations^IS204^IC1000^G .RM -10 .FILL .JUSTIFY .COMMENT .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT The Editor's Corner .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT .SKIP 9 ######################^IC0000^IS328^GThe Editor's Corner^IS204^IC1000^G .SKIP .CENTER Bruce R. Mitchell .SKIP This is a pretty varied issue, more variety than we've seen for quite some time here at the Multi-Tasker, and there's one good reason for it: There is now a teeny-tiny, itsy-bitsy little flow ... but nonetheless a flow ... of new articles arriving at the plush M/T offices. It's barely enough to whet one's appetite for more, but it's more than I've seen since the memory of the Editor runneth not to the contrary. Well, it's about time! So there ^IS144^Gare^IS204^G a few wolves out there among the sheep, eh? Real Programmers who aren't afraid of a little ink on their fingers, or paper cuts from printouts! So threats are what it takes to get you to contribute articles, eh? Very well then! If you don't keep sending in more articles, I'll hold my breath until I turn green! Well, yes, we got articles. You bet. We got articles on debugging overlaid tasks (always a drag, but less so after you read this), articles on the mysterious FCS Multi-Buffering (and his man Kato) (ow! ow!), a spiffy task to rotate VT100 lights, some reports from the Spring Symposium (see, didn't I promise you?), and a top-notch technical paper on how to drive Field Service crazy by putting memory on the PDP-11/44 Unibus. (And much more, coming up after this commercial announcement.) The Editor is once again confounded. Despite moving the M/T offices in the middle of the night, changing all passwords, purchasing new locks, and adding yet another guard dog ... somehow ... we have yet another Justin L. Hewser article. This month Justin weighs in with some comments on "How to Get That DECUS Support". He must have blackmailed the original author, because it actually makes sense. Now, for those of you with hungry minds, how about a little editorial? This month's guest editorial is by Richard Neitzel. .TEST PAGE 5 .SKIP 2 .CENTER ----- ADA, DEC, DOD, IBM and other TLAs ----- Why are we being left behind? In my area of applications (Dept. of Energy defense related projects) the use of ADA for realtime critical systems is only a few years away (we're a little behind DOD). Currently, our standard platform for realtime is RSX on 11/73s. Unfortunately, when ADA comes, that goes. Why isn't DEC or a third party working on an ADA implementation for the 11-series? Granted, ADA development eats up system resources, but if it can be done on an 8086 (IBM XT), then it can be done on my 11/73. Even if it were to prove too much for the 11/73, why not have a cross-compiler that runs on a VAX? After all, there are cross-compilers for many other ADA targets, many of them 16 bit CPUs. It would be excellent if the code generated were RSX-compatible, so it could integrated into existing systems, but I would settle for a run-time only system on the PDP, similar to the way Micropower/Pascal is implemented. Why push me into a VAX solution if I need to go to ADA? Frankly, the dollar cost of that solution is such that we will probably drop DEC as our hardware vendor and go to 680x0 CPUs and the VMEbus. If there were a cost effective DEC solution we wouldn't change, but DEC apparently isn't interested. Too bad, since we have been buying 30 to 40 systems and associated software a year. Once we go to Motorola, we won't be buying VAXes for non-realtime either. I guess DEC is now just another way to spell IBM. Users unite, and let's throw the "DEC is IBM" rascals out. .SKIP .INDENT 30 Y'r obd't servant, .INDENT 30 Richard Neitzel .SKIP ^IS144^GAre you listening, up there in Marlboro? This is the users ... your ^&customers\& ...talking. Remember them? #--#The#Editor^IS204^G .TEST PAGE 5 .SKIP 2 .CENTER ----- Submitting Articles to the Multi-Tasker ----- Please submit machine readable media. RX01/2, RX50, 9 channel 800/1600 BPI magtape or paper tape are OK. Most media I can't read I can get converted; don't let that stop you. All RSX volume formats are acceptable, but I ^&can't\& read VMS Backup or ODS-2 stuff. You can also submit articles through the RSX bulletin board system. The dialin line is (612) 777-7664. Kermit 'em in and send them via MAIL to username MULTITASKER. Submissions which aren't machine readable may take longer to get into print. The editor is lazy and types mass quantities only once a month when progress reports are due. If you preformat in RUNOFF, please set page size 58,80; left margin 10; right margin 75; and, when changing margins, use incremental changes rather than absolute. The editor blesses you for the consideration. Send your articles and other submissions to the luxurious new Multi-Tasker offices c/o: .SKIP .NO FILL .NO JUSTIFY Bruce R. Mitchell Machine Intelligence and Industrial Magic PO Box 816 Byron, MN 55920 (507)#775-6268 .JUSTIFY .FILL .TEST PAGE 5 .SKIP 2 .CENTER ----- And That's The Way Things Are ----- _... this month in Pool Lowbegone, where the RSX systems that do real, manly work are strong, the bottom-line results are good-looking, and the number of Real Programmers is above average. .COMMENT .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT Debugging Overlaid Tasks .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT .TEST PAGE 15 .SKIP 6 #################^IC0000^IS328^GDebugging Overlaid Tasks^IS204^IC1000^G .SKIP .CENTER Dr. Adrian Bottoms .CENTER RSX SIG Chair - UK, Ireland, and Middle East Chapter .CENTER XDT Computer Systems Ltd. .CENTER 9 The Square .CENTER Keyworth, Notts.###NG12 5JT .CENTER England .SKIP Being a frequent developer of system utilities, I often find myself frustrated or balked by the 2 APR address space limitations of privileged tasks (I don't care to do a SYSGEN just to generate a 16K Exec). This has been somewhat alleviated by introduction of the /IP Taskbuilder switch, allowing use of APR7 to map the task rather than the I/O page without having to bear griping from INStall. However, privileged tasks which map APR6 around the system need access to the I/O page, reducing the task's available addressing space to a single APR, or 4 K words. This is often inadequate, particularly if the task needs to pull in FCS routines to manipulate Files-11 volumes. One of many ways of tackling this problem is to use the bane of every PDP-11 developer's life - overlays. "RSX Users Do It by Overlaying". (UNIX users do it in pipes! VMS users don't do it at all! ...) Retrofitting overlays to code developed without previous design for overlays can be a real pain. Contrariwise, fitting overlays to code designed with the thought of possibly needing overlays can be as simple as writing an ODL (Overlay Descriptor Language) file and re-Taskbuilding. The problem I want to tackle in this article is using ODT to debug code lying in an overlay segment. ODT works by replacing instructions in memory with BPT (000003) instructions which cause a vectored SST trap when executed. Overlays work by loading segments of code from the task image on disk into memory when they are required. It follows that if the segment to be debugged is not resident in memory when a breakpoint is set, no trap occurs when code in that segment is executed after being loaded. In other words, you can't set a breakpoint in a segment not currently resident in memory. These arguments also apply to memory resident overlays, since ODT cannot reach segments which are not currently mapped even if they have already been loaded. It is possible to set a breakpoint at the call site which results in the overlay load, and then step through all the overlay load code until the segment entry point is reached. This is tedious in the extreme. It is also possible to set a breakpoint in the overlay loading code immediately before transfer to the segment entry point. This also seems like hard work. There is a much simpler scheme. I used to tackle this problem by using conditional assembly to assemble in debug support code - a BPT instruction at the entry point of the overlay modules to be debugged. .sk .nf XFR::###.IF DF DBG###########; Overlay entry point ########BPT##################; Cause a trap to ODT. ########.ENDC################; DF DBG .f .sk The above code is turned on by defining the symbol DBG in the source file (DBG#=#0), and left out by leaving DBG undefined. This means reassembling and re-Taskbuilding every time there's a need to debug a module; and we all know how fast the Taskbuilder is, particularly when building overlaid tasks! It also has the side effect that module sizes change, which means that old listings and map no longer do, and trees are worth preserving. (I am worried about the trees, but the real reason is that trees grow faster than my printer prints). The neater solution comes in two parts, a neat neater solution, and a neater neater solution. .SKIP 1. The neat neater solution. Code at the entry points to modules is written in the following form: .sk .nf XFR::###DBGOVL###############; Overlay entry point. ########... ########... ########etc .f .sk In this case, the Taskbuilder GBLDEF is used to define the value of DBGOVL to either include or exclude the debugging support. In this way reassembling the module is avoided at the slight cost of making each module one word larger. Module sizes remain the same, so the need for new listings and maps is avoided. The GBLDEFs necessary to disable and enable debugging breakpoints appear as follows: .sk .nf GBLDEF=DBGOVL:240############; Exclude debugging (240 = "NOP") GBLDEF=DBGOVL:3##############; Include debugging (3 = "BPT") .f .sk Forcing breakpoints in causes a trap to ODT when control is transferred to the entry point of each overlay having this support built in to it. .SKIP 2. The neater neater solution. This is similar in concept but allows better control of which overlay loads cause ODT traps. As before, each segment needs some special code when it is written. .sk .nf ########.PSECT###CODE###I,RO,LCL,REL,CON # XFR::###NOP##################; Overlay entry point. ########... ########... ########etc .f In this case, Taskbuilding the code in the normal way simply results in normal task execution with the slight time penalty of the time it takes the processor to execute a NOP. However, when a trap to ODT is required on entry to the overlay segment, the Taskbuilder GBLPAT option is used. .sk .nf GBLPAT=CODE:XFR:3############; Force ODT on entry to overlay XFR .f .sk In this way it is possible to select which overlays trap to ODT when the task is built. It is even possible to use ZAP to turn traps on and off by locating the entry points in the task image (use the ZAP /LI switch) and changing them to BPTs. More complex schemes can be invented (I have) which can be patched at runtime with ODT to cause traps on entry to overlays. For example, each overlay can call a routine in the root to determine whether it should execute a BPT. In any case, once a BPT is executed, ODT breakpoints can be set in the code to be debugged since it is now memory resident. There is, of course, the overhead of re-Taskbuilding, and we all know that the Taskbuilder isn't the fastest ... but in general you will probably be rebuilding to include ODT anyway, so this is not so much of a problem. I hope that this article has shown that the best way of dealing with overlaid tasks is to plan for them in advance, both when designing the original code structure and when planning for debugging. It shows the value of leaving definition of certain items to as late a stage as possible in the various processes involved in building a task from the source. Remember always the system programmer's axiom that there is no problem in computing which cannot be solved by adding another level of indirection. .COMMENT .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT FCS Multibuffering ... One of RSX's Best Kept Secrets .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT .TEST PAGE 15 .SKIP 6 #^IC0000^IS328^GFCS Multi-Buffering ... One of RSX's Best Kept Secrets^IS204^IC1000^G .SKIP .CENTER Barton F. Bruce .CENTER Cambridge Computer Associates, Inc. .CENTER 222 Alewife Brook Parkway .CENTER Cambridge, MA###02138 .SKIP Tasks that never have to wait for I/O, and that have no noticeable idle time are easy to make. There are a few simple steps that can convert many of your programs to this mode. A task normally uses one 512-byte buffer for each file it has open. Having only a single buffer, the task often finds itself waiting for some I/O to complete. By simply making the buffer bigger, the number of times one waits decreases, but one still waits. By having a second buffer, one need never wait. But by having two large buffers, one never waits and the disk is not doing a dance across the floor. For writing, the other buffer should be free so that it may be "spilled over and into" when the current buffer is full. The current buffer is then written asynchronously while your task continues. Once written, this buffer becomes the empty spare. For reading, the exact opposite is desired. The other buffer must contain the preread next blocks from disk ready for use when the current buffer is emptied. All this sounds like a lot of complex housekeeping to help you lose data and grow grey hair. The simple truth is that FCS already has support for all this. You just have to turn it on. Everything else is the same. Your writes and reads look the same as before. If it is so good, why doesn't everyone always use this support? First, though support has claimed to be there for many years, it didn't always work. Second, the necessary buffer space may not be available in some tasks. Third, DEC hasn't advertised the virtues of doing this enough. Rather than write a lot more, I am going to say a few specific things and then give you a sample program to try. ACTFIL is NOT really the number of files you have open, but is actually the number of 512-byte (plus overhead) buffers you need. The Fortran 'READONLY' keyword, aside from obvious usage, also sets the bit that requests anticipatory read-aheads into extra buffers rather than the default write-behind action. Vanilla SYSLIB does not support multi-buffering. Big (ANSI mag tape) buffer support is there on M+, and is in ANSLIB on plain RSX-11M. DEC supplies modules to upgrade your SYSLIB, but do it in a separate library, as some modules are slightly larger and some other task may need the older small version. Three or more buffers works, but won't normally help, and takes space. It is better to use 2 bigger ones. Our example is written in F77 and reads and writes sequentially through its files and does some simple counting. First, make a multi-buffering version of SYSLIB, preferably somewhere convenient such as LB:[1,1]: .SKIP PIP MBFLIB.OLB = LB:[1,1]SYSLIB.OLB .BREAK LBR MBFLIB/RP = LB:[1,1]FCSMBF .SKIP And now make a great big huge gigantic text file to test with: .SKIP PIP YUK.TMP/BL:8000. = NL: .BREAK PIP YUK.TMP/UP = LB:[11,10]*.MAC (or whatever) .SKIP Create our simple demo program, SPEED.FTN: .SKIP .NO FILL .NO JUSTIFY Program SPEED Implicit Integer*2 (A-Z) Parameter BUFSIZ=4096 ! 8 X 512 -> USES actfil = 8 Parameter BUFCT=2 ! X 2 -> NEED actfil=16 C Later try the following to see how slow it is: C Parameter BUFSIZ=512, BUFCT=1 Parameter IN='YUK.TMP', OUT='YUKYUK.TMP' Integer*4 LINES,CHARS,CPL(0:255),COMNTS Character*255 BUF Data LINES, CHARS, CPL, COMNTS / 0,0,256*0,0 / Open (Unit=1, Name=IN, Blocksize=BUFSIZ, Status='OLD', + Buffercount=BUFCT, Readonly) Open (Unit=2, Name=OUT, Blocksize=BUFSIZ, Status='NEW', + Buffercount=BUFCT, Form='UNFORMATTED', + Carriagecontrol='LIST', Extendsize=-4000) Do 100 X = 1,1,0 ! Loop forever BUF(1:1) = ' ' ! Don't count comment twice ! if zero len line follows Read (1, 10, End=200) Q, BUF 10 Format (Q, A) LINES = LINES + 1 CHARS= CHARS + Q CPL(Q) = CPL(Q) + 1 ! Tally lines with char cnt If (BUF(1:1) .EQ. ';') COMNTS=COMNTS+1 ! Count comments Write (2) BUF(:Q) 100 Continue 200 Do 210 I = 0, 255 If (CPL(I) .NE. 0) Type *, CPL(I) ,' LINES ', I, ' LONG' 210 Continue Type *, COMNTS, ' COMMENT LINES' Type *, CHARS, ' BYTES,', LINES, ' LINES' Close (Unit=1) Close (Unit=2) End .JUSTIFY .FILL If you are using F77 V5.2, the /DS switch ensures I/D separation if you are unsure how your compiler's default was built. This demo hardly needs the extra space I/D separation gives, but real tasks may need it. Vanilla RSX (and non-I/D M+) folks should simply leave out the /ID in SPEED.TKB. Now assemble the little test program: .SKIP F77 SPEED, SPEED/-SP = SPEED/ID And make a TKB command file, SPEED.TKB : .SKIP .NO FILL .NO JUSTIFY SPEED/ID, SPEED/-SP = SPEED LB:[1,1]F77FCS/LB (or whatever your F77 library is) MBFLIB/DL / ; 16 for each big/multi buffered file, 1 for type * to terminal ACTFIL=33 ; allow records bigger than 128 bytes MAXBUF=255 / .JUSTIFY .FILL And now taskbuild and run it: .SKIP TKB @SPEED.TKB .BREAK RUN SPEED If you have console lights (11/70s) warn your operator that NO idle pattern at all does NOT mean you have crashed or are in a hard loop. If you like the speed this gives you, consider sending DEC an SPR suggesting the M+ FCSRES / FCSFSL be a multi-buffering version rather than simply a big-buffering one (they HAD to at least do that for ANSI tape support). .COMMENT .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT How to Get That DECUS Support .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT .TEST PAGE 15 .SKIP 6 #############^IC0000^IS328^GHow to Get That DECUS Support^IS204^IC1000^G .SKIP .CENTER Justin L. Hewser .CENTER RSX SIG Member-at-Large .CENTER Nocturnal Aviation Software, Ltd. (very) .SKIP 2 ^IS144^GThis article appeared mysteriously on the RSX BBS. Something seems familiar about it - as though I've seen the title before - but I can't quite put my finger on it. #--#The#Editor^IS204^G .SKIP Management asks one question more often of DECUS members than any other. We've all heard it at some time: "For what reason should we support your DECUS attendance / membership / activities?" As members we ^&know\& that we benefit significantly from being DECUS members, from attending symposia, and from serving in DECUS leadership positions. When asked to pin down those benefits, however, too often we fall back on "Ummmm ... well, there's lots of reasons, but the best one is that we benefit from it." Yeah, OK right. Now put yourself in management's position. Is "... we benefit ..." something usable to allocate money? Is it quantitative? Is it defensible in arguments before a funding committee? Look: We don't have to watch the bottom line other than making sure our current project doesn't go over budget. Managers, on the other hand, work in a world where everything is on a bottom-line basis. Good intentions don't matter there. If value received for investment x is greater than x, the investment is good. If not, the investment is bad. Companies that make bad investments do not stay in business, and managers who make bad investments do not remain managers. Guess what that means in terms of going to DECUS. You want management to be on your side in this issue. They'll back you up ^&if\& you give them the ammunition they need to show that DECUS activity is a good investment. Without their backing, you'll end up paying for that symposium trip yourself - which is OK, a fine tax writeoff, but not as nice as having the company pay for it. Well then, how do we show our managers that attendance at symposia, service in DECUS leadership, and DECUS membership in general are good corporate investments? There are three broad levels of participation in DECUS. They have already been mentioned: Membership, symposium attendance, and leadership. Cost progresses upward through these levels as involvement increases. More justification is therefore needed as each level is reached. Let's start with the easiest and work up to the more difficult. .TEST PAGE 4 .SKIP .CENTER Membership Simple DECUS membership is easy to justify. The money outlay is only $35 per year to receive the DECUS SIG newsletter. For that $35 bucks, the member receives up-to-date information on his specific area of interest and on many others as well. As problems crop up, the newsletters report them. All that is necessary is that the member read the newsletters once a month - let us say two hours per month. Does DECUS membership save two hours of time per month, and is it worth $35 per year? The money is throwaway petty cash for most companies, but 24 hours each year is not. Let's look at it differently. Does the average member get information from the SIG newsletters that saves 24 hours a year in otherwise lost time? Certainly. He is exposed to good coding techniques, methods of problem solving, other operating systems, available tools, and persons he can contact when he has a problem. DECUS membership is always a good investment, no matter how small the company. .TEST PAGE 4 .SKIP .CENTER Symposium Attendance Symposium attendance, whether regional or national, requires a larger commitment on management's part and proportionately larger justification on the member's part. The cost of attending a national symposium for a week runs close to $1,500 in hotel, registration and travel. There is also one week of the employee's time lost - an indirect cost which in many cases is larger than the direct cost. There are good justifications for attending symposia. Symposia expose attendees to the cutting edge of Digital's world. New hardware - generally unavailable through the local DEC office - is present for examination and trial. New software is on the display floor to be tried and evaluated. This is also not generally available through the local DEC office. Symposia allow users to meet other users working in similar environments and to discuss common problems. Solutions are exchanged. Contacts are made with other users which later prove useful in daily work. Problems are taken directly to DEC people working intimately with the item in question, and who may even be the implementer of the item. Sessions at symposia cover an amazingly wide variety of topics. From nine in the morning to seven and later at night, attendees see how to use software products, what new products are being announced, finds out how other users approach his site's problems, and - most amazing! - can stand at a microphone with a supportive crowd of other users and demand that Digital do something about ^&his\& problems. What is it worth to play with new software and hardware up to a year before it becomes generally available? How much is a solution to a problem that has wasted two weeks of a programming team's time worth? How much would it have been worth to have the solution ^&beforehand\&? Can you put a value on a tool that may not be used for a year, and then is available immediately without rooting around for it? More recently, what would the cost to ^&your\& company be if symposium attendees hadn't threatened to cancel million-dollar orders unless DEC recanted its software licensing policy? While small firms may find that symposium attendance may not justify the outlay, most companies find that sending at least one person to each symposium reaps benefits in time saved and problems solved. .TEST PAGE 4 .SKIP .CENTER Leadership Eventually, some members find that they have an interest in leadership within DECUS. As the level of personal involvement in DECUS grows, the number of participating members dwindles. From the 50,000 members of the U.S. chapter, to 8,000 annual symposium attendees, we find that participation falls to less than 500 people who run DECUS. The corollary of decreased participation, of course, is increased activity. For this level of participation, much justification is required. Leadership positions in the national organization require firm commitment from the member and good support from his employer. Consider the RSX SIG as an example. The SIG leadership spends, on average, 15 minutes each day tracking current issues on the DECUS leadership computer system, and 15 minutes on other DECUS-related business. Attendance at both symposia is almost mandatory, as these are the only times when all leadership is together. But since symposia are not ideal places for strategic planning, most SIGs also hold annual or semiannual "Woods" meetings. The money commitment from an employer is therefore in the $3,000 range yearly. Two weeks - perhaps more - each year are taken up by symposia and meetings, with an additional three weeks nibbled away in daily contacts. Five weeks, or ten percent of an employee's time, requires very good justification to pass muster with the "bean counters". It is hard to justify this level of commitment for more than one person from a single firm. The arguments given to justify attending symposia still hold, but more are required to make the additional commitments at this level palatable. There are two major justifications for supporting a member at leadership level. The first is that contacts developed through this level are extensive and deep. Both within the user community and within DEC, it becomes acceptable to call an acquaintance and pick his brain for half an hour on a thorny problem. This is a level of immediate support not purchasable from an outside consultant at reasonable price, or from DEC at ^&any\& price. Consider what basic DEC telephone support costs per month. The ability to call six experts in any field of DEC application and discuss a problem is valuable, yes; but the ability to call a product implementer directly, and not simply complain about service from DEC's telephone support, is beyond price. The second reason for supporting a member at this level is that it gives the member, and through him, his company, direct involvement with Digital. DECUS is a strong voice in the Digital world, and those who run DECUS speak clearly to Digital. When DECUS said that members weren't happy with software licensing, Digital lost no time backing down from its stand. When leadership members ask for new features or correction of problems, Digital listens. How could it be otherwise? Fifty thousand DEC users are influenced by DECUS newsletters. The members who run DECUS have the most "say" in how Digital reacts to users. Commitment at this level is not for all members, nor for all companies. There are conflicts; cases where members have the commitment, but their companies cannot support it. Even in the largest and best-funded computer operations, an individual's ongoing participation at this level can be hard to justify. Returns are diffuse, and difficult to value exactly. But at this level resides immediate "wizard level" expert advice, and the true power to influence Digital. .SKIP Here, then, are your justifications for being a DECUS member, and for participating actively in the organization. With them, you can increase your chances for success in obtaining your company's support for DECUS activity. .SKIP 2 Gotta run now, someone's banging on the door wanting to know why SYSTEM is logged in here at this hour of the night ... .SKIP .INDENT 30 Yr obd't servant, .INDENT 30 Justin L. Hewser .COMMENT .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT Memory on the PDP-11/44 Unibus .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT .TEST PAGE 15 .SKIP 6 #############^IC0000^IS328^GMemory on the PDP-11/44 Unibus^IS204^IC1000^G .SKIP .CENTER Barry G. Essig and Michael M. Tsuji .CENTER Grumman Aircraft Systems Division .CENTER M/S G01-14A .CENTER Bethpage, NY###11714-3582 .SKIP 2 .CENTER ABSTRACT .SK An interface to a multi-port memory from an existing system hosted by a PDP-11/34 running under RSX-11M was successfully transported to a PDP-11/44, thus upgrading the entire system. This experience can be directly applied to any multi-port memory systems implemented on a Unibus processor. .SKIP 2 I. Introduction Anyone reading the title of this paper might very well ask, "Why would anyone want to put memory on an 11/44 Unibus when the 44 already offers a physical address space of 4 megabytes?"## A fair enough question. In our case, we wanted to upgrade an existing three-processor mission simulator by replacing an 11/34 with an 11/44. What we had was a custom designed Unibus interface to the memory in another processor. This memory, which is used for sharing global data between processors, was made to appear as 32 Kb of the PDP-11/34's physical address space. Since we were restricted to the physical address space of 256 Kb in the 11/34, giving up 32 Kb for global data bases left us with the problem everyone faces sooner or later on an 11/34: Not enough memory to run tasks. Hence, it was decided to attempt porting this interface to an 11/44, and have the 44 run the existing 11/34-developed software with a minimum of changes, thereby preserving our hardware investment (one of the other processors is VERY expensive) and our software investment. Surprisingly, the hope turned to fact although there were more than a few problems. Rather than go into details about about the mission simulator and its hardware and software design (a subject for another audience), we will discuss the problems that were discovered in putting memory on an 11/44's Unibus and relate the things which must be done should anyone want to do this. First, some background on the differences between the 11/34 and 11/44 must be explained. .SKIP 2 II. Background .SKIP II.1 PDP-11/34 VS. PDP-11/44 The PDP-11/34 has a physical address space of 256 Kb, of which the top 8 Kb are reserved for the I/O page. In the 11/34, memory and peripherals are on the Unibus; it is the Unibus 18 address lines that restrict memory on the 11/34 to 256 Kb. In the 11/44, memory is on its own separate bus (the Private Memory Bus), and peripherals are on the Unibus. This scheme allows the 11/44 to have 22 address lines for a physical address space of 4 Mb. Of this 4 Mb, the lower 3840 Kb are for memory and the top 256 Kb are reserved for the Unibus. And, of the top 256 Kb, the top 8 Kb are reserved for the I/O page. This was to preserve compatibility. In the 11/44, when a 22-bit physical address is presented to the memory management unit, the most significant four bits are tested. If all four bits are set (17xxxxxx)*, the address is .FOOTNOTE 3 .LM 10 .RM 75 .SKIP ----------------------------------------------------------------- .BREAK * Addresses and UMR numbers are understood to be in octal. !END FOOTNOTE a Unibus address, and the least significant 18 bits are presented to the Unibus. If any of the 4 most significant bits are not set, then the 22-bit address is taken to be a main memory address. See Reference 1. To understand what must done to put memory on an 11/44's Unibus, an explanation of the Unibus Mapping Adapter is necessary. .SK II.2 Unibus Mapping Adapter (UMA) The Unibus Mapping Adapter (also referred to as the Unibus Adapter Module) permits a Unibus device to communicate with the memory of the 11/44. Anyone who understands how 16-bit virtual addresses are converted to 18-bit physical addresses via Page Address Registers in an 11/34 will understand how the UMA works (see Reference 1 for an explanation of memory management). In the case of a UMA, an 18-bit Unibus address must be converted to a 22-bit main memory address. To do this, the UMA divides the 256 Kb of Unibus space into 32 8-Kb "pages." (This is well documented in the PDP-11 Unibus Processors Handbook, reference 2.) For each page, there is a Unibus Mapping Register (UMR). UMR 0 maps 000000 to 017777, UMR 1 maps 020000 to 037777, and so on. The uppermost 8 Kb is reserved for the I/O page and is not mapped. When a Unibus address is presented, the UMA determines the page in which the address occurs and uses the contents of the corresponding UMR to map the 18-bit address to a 22-bit address. The UMR must be allocated and loaded with a main memory base address by software, usually an RSX driver. Thus, data coming in from a device can be routed to the task in main memory which requested it. The problem that arises when one tries to put memory on the 11/44 Unibus is that when an address is presented to the UMA to get to Unibus memory, the UMA takes that address and attempts to route the data back into main memory. If the base address in a UMR is 0, one is confronted with data intended for Unibus memory coming back into main memory and overwriting interrupt vectors! Fortunately, the 11/44 System User's Guide (see reference 3) tells how to avoid this. We modified a UMA by "disabling" UMRs 31 to 37. These registers map Unibus addresses 600000 to 757777, 192 Kb to 248 Kb. It is recommended in the System User's Guide that you always disable UMRs from the TOP DOWN. ("Disabling" is put in quotes because when we attempted to OPEN the I/O page location of the corresponding UMRs, they are readable and writable; no "invalid address" message is given. Therefore, disabling in this context means that mapping is disabled, not access to the registers themselves.) On the 11/44, this meant cutting six jumpers one the UMA board. On an 11/84, according to the System User's Guide, this can be accomplished by writing a register in the I/O page. .SK II.3 The 11/34 Software The reason these UMRs were chosen was that the interface unit was designed to decode addresses in that range (remember, it was designed for an 11/34). All our 11/34 software was linked to global common areas which overlapped this region. So all we had to do now was get our software to present to the memory management unit an address of 17600000 and higher, and the hardware would do the rest by stripping off the 4 MSBs and presenting the 11/44 Unibus with an address of 600000 and higher. Rather than create and install COM partitions beginning at address 600000, we would install them beginning at 17600000. So, the plan seemed easy enough to implement: modify the UMA, install COM partitions in Unibus space and run the software. Surprisingly, it IS that easy, but there were a few "gotchas" along the way. .sk III.Pre- and Post- SYSGEN .SK III.1 Pre-SYSGEN Considerations Since we had disabled 7 UMRs, we had to make sure that no RSX driver would attempt to use one of these UMRs. In Appendix B of the RSX-11M/M-Plus System Generation Manual (reference 4), it explains what safeguards must be taken for NPR drivers in systems with extended memory and memory management support. Specifically, there is a system parameter called N$$UMR that RSX uses to statically define UMRs. This parameter is in the file [11,10]RSXMC.MAC. After we did a PREPGEN, we examined this file. It turns out that the default value of N$$UMR is 5. By checking the values of U$$MRN, U$$MHI, and M$$MLO, we determined that the system would use UMRs 0 to 4. (U$$MRN is the I/O page address of the next available UMR, U$$MHI and U$$MLO together give the 18-bit Unibus address mapped by the highest UMR.) Since these values were in a safe range, we decided to stick with the defaults. .sk III.2 SYSGEN The SYSGEN procedure went smoothly and without any problems. .sk III.3 Post-SYSGEN Problems The first problem we had after we had SYSGENed the system using the modified UMA occurred when we tried to SAV the system image; SAV never rebooted the new system. Thinking that using the modified UMA during SYSGEN might have created a corrupted system, we tried the SYSGEN again with an unmodified UMA. This time SAV worked correctly. We then SAVed the system with the /WB switch. Performing a hardware boot of the system with the unmodified UMA also worked correctly. We then powered the system down and swapped UMAs. With a modified UMA in place, we tried to boot the newly SAVed system. The system again "hung." It appeared that the system hung when the secondary boot loader attempted to pass control to the entry point $SVENT in SAV. This was confirmed by turning on the TRACE macro in SAV and examining the boot with the modified and unmodified UMAs. This showed that we never got to $SVENT when we had the modified UMA in the system. We confirmed that we got to the secondary boot by counting the number of times the controller was initialized by the primary and secondary loaders and counting the number of times the A controller light went on and off. Rather than pass control to SAV to complete the boot process, the system seemed to go off into a state of limbo. We took a closer look at our SYSGEN procedures. During Phase II SYSGEN, we created several new partitions lower than the start of GEN. These were to hold MCRMU (the multiple user MCR task), TKTN (the task terminator), SHF (the shuffler), and the magnetic tape ancillary processors. The idea was to install and fix these tasks in memory to improve system performance by eliminating the time required to swap these tasks in and out of memory. This caused GEN to start at address 607600. When SAV /WB was issued on the virgin RSX system, with unmodified UMA, the system rebooted normally. VMR showed SAV in memory at address 607600, the beginning of GEN, with a high address of 615502. Note that SAV begins at a physical memory address above the highest Unibus address mapped by the UMA. We decided to remove the extra partitions we created in the SYSVMR command file and VMR a fresh system image. This lowered the start of GEN to 355600. This time, when SAV /WB was issued with an unmodified UMA, SAV was at address 355600. Now using the modified UMA, a successful hardware boot of the saved system was accomplished. It appeared from this that 600000 might be the thin line between booting and not booting. By looking at the SAV listings, we determined that VBN1, the first block of the task image, does the following: .SKIP .LM +3 .INDENT -3 o##Clears memory management register SR3, disabling Unibus mapping and 22-bit relocation .SKIP .INDENT -3 o##Sets the LSB of memory management register SR0, thereby enabling relocation .SKIP .INDENT -3 o##Transfers control to the secondary boot, which reads in the rest of the system. .LM -3 The combination of the LSB of SR0 being set and the contents of SR3 being zero, according to the System User's Guide, enables 18-bit relocation. Thus, when the system is booted and VBN1 runs, any further execution occurs in 18-bit mode; this is the environment when the remainder of the system is read in. It is in this mode that the loader attempts to transfer control to $SVENT in SAV. If $SVENT is above highest mapped Unibus address, the system will not boot completely. It should be noted here that the SAV task used was modified to save and restore only the UMRs that remain enabled. The module SAVE.MAC was modified to save and restore 24 UMRs. In retrospect, this seems to be unnecessary as all UMRs are accessible and SAV will not trap out when attempting access disabled UMRs. .sk III.4 Memory Size Among the things SAV does when the system is booted is to determine if the system is an 11/44 or 11/34. If it is an 11/44 and a mapped system, SAV reenables Unibus mapping and 22-bit relocation. Control is then passed to .INITL in the operating system. .INITL then sizes main memory; it keeps testing higher and higher addresses in 32-word increments until it traps. The system expects all memory to be contiguous. When it traps, it sets $SYSIZ to the number of 64-byte blocks of memory in the system. Since we had 1 Mb of memory, $SYSIZ was set to 40000 (40000 * 100 bytes = 4000000 = 1 Mb.) This location is tested by the MCR SET /MAIN command when you want to create a COM partition. Now, our Unibus memory has addresses beginning at 17600000, far above 1 Mb. In order to create a COM partition, we had to modify $SYSIZ to 177600, which represents 4 Mb minus 8 Kb. Then the following command installs a COM partition over Unibus memory: .SKIP > SET /MAIN=PARNAM:base:siz:COM .SKIP where in our case base=176000. In order to modify $SYSIZ, we first used the OPEN command from a privileged account. To effect the change permanently, we created a privileged task built /PR:5 to zap the Executive. We run this program from our STARTUP.CMD file. Note that it is not good enough to change $SYSIZ and reSAV the system, since on a reboot the value of $SYSIZ is calculated. .sk III.5 Software Boot of a Bootable Image The final problem encountered was booting a standalone bootable image, specifically BRU64K.SYS. (We always use BRU64K.SYS to back up our system disk.) When we booted BRU64K, the system would hang if we had a modified UMA installed; it was successful if we had an unmodified UMA in. This was to be expected since we could not boot a virgin system after Phase II. In examining the BOO listings, we found that the current value of $SYSIZ was used to determine where the actual bootloader, BOTPH2, would be loaded. BOTPH2 is the routine that reads in the specified bootable image and transfers control to it, and $SYSIZ is the number of 32-word blocks of memory in our system. In our system, $SYSIZ was 177600 as a result of running the privileged task mentioned in Section III.4. If $SYSIZ is larger than 7600 (248 Kb), then BOO sets the memory location of where BOTPH2 is to be loaded at 248 Kb - 1 Kb = 247 Kb, the top of memory in an 18-bit PDP minus 1 Kb. If $SYSIZ is lower than 248 Kb, it attempts to load BOTPH2 at $SYSIZ - 1 Kb. After this discovery, we modified $SYSIZ to several values and tried to see if we could get BRU64K.SYS to boot. It booted successfully if $SYSIZ was less than or equal to 6000; it failed when $SYSIZ was bigger than 6000. 6000 64-byte blocks puts top of memory at - lo and behold - 600000 = 192 Kb. This says that as long as BOO can write BOTPH2 to an address below 600000 in our system with a modified UMA, the new image can be booted successfully. Now, when control is transferred to BOTPH2, it clears SR3, thereby disabling Unibus mapping and 22-bit relocation. Since the LSB of SR0 is set at the time the BOO command is issued and never cleared by BOO, the system is in 18-bit mode. Therefore, everything reduces to the previous case. .sk III.6 DMA Into Unibus Memory It was mentioned previously that all of our real-time simulation tasks are mapped to global common partitions and that these global common partitions are now in Unibus space in our 11/44. (For an explanation of tasks linked to global common partitions, see the RSX-11M/M-Plus Task Builder Reference Manual, reference 5.) To run such a task under RSX-11M, a shared memory image must first be loaded into the global common partition using the INStall command. What happens here is indeed a bit strange, and is still under investigation. When you INStall a shared memory image into a global common partition, then a DMA is done to the global common memory. In our system, this works and doesn't work. Specifically, the system thinks the I/O completes successfully, and RSX believes that a shared memory image is now installed in the global common partition. Any task linked to the global common partition can now be loaded and executed. So in this sense, it may be said to "work." There is, however, no data to be found in the global common partition as a result of the INStall. Our shared memory images have initial data and this data must be loaded into the global common partitions. We worked around the problem by installing the shared memory images in a global memory partition located in main memory. We then run a task which transfers data from the main memory partition to the Unibus memory partition. This initializes our shared memory to the values desired. According to the hardware documentation available to us, there is no reason why you cannot do DMA directly to 11/44 Unibus memory as long as you disable the appropriate UMRs. Currently we are looking at our disk driver (DU); we believe the problem is in the software and not in the hardware. (If any readers can shed light on this, we would appreciate some feedback.) .sk IV. Conclusions We would conclude by saying that our experience should be applicable to any multi-port memory system involving PDP-11/34s so long as the interface devices are Unibus devices. In fact, the next logical step would be take the interface device and put it on a Unibus connected to either the SBI or BI of the appropriate VAX. Disabling the top N UMRs on the 11/44 UMA gives 256-8*N Kb memory available to the processor when in 18-bit relocation mode. Any tasks which must run before the system is restored to 22-bit relocation mode must run below 256-8*N Kb. .sk V. Acknowledgements A word of acknowledgement to Carl Mickelson of Loral Systems Division for some illuminating conversations on this subject. .SKIP 2 .CENTER References .SKIP 1. Digital Equipment Corporation, PDP-11 Processor Handbook, 1981, pp. 135-169, pp. 217-258. .SKIP 2. Digital Equipment Corporation, PDP-11 Unibus Processor Handbook, Chapter 3. .SKIP 3. Digital Equipment Corporation, PDP-11/44 System Users Guide, 1981, pp. 3.8-3.24. .SKIP 4. Digital Equipment Corporation, RSX-11M/M-Plus System Generation Manual, Vol 2A, Appendix B. .SK 5. Digital Equipment Corporation, RSX-11M/M-Plus Task Builder Reference Manual, Vol 4B. .COMMENT .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT More on Monitoring Task Status .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT .TEST PAGE 15 .SKIP 6 ##############^IC0000^IS328^GMore on Monitoring Task Status^IS204^IC1000^G .SKIP .CENTER Richard Neitzel .CENTER 312 Laveta Pass .CENTER Golden, CO###80401 .SKIP In the August issue of the Multi-Tasker the article "A Cheap Way to Monitor Task Status" presents a method of monitoring the state of running tasks. This presentation used the RPOI$ directive to make the parent - offspring connection between the tasks. However, the SPWN$ directive can be used just as effectively, and with some minor advantages. SPWN$ specifies the task to be started and allows the specification of an AST routine to be entered when the spawned task exits or emits status. Further, an event flag to be set at that time may also be specified. This means that two directives may be consolidated into one. Thus, with these modifications, the code presented on page RSX-10 of the earlier article becomes: .NO FILL .NO JUSTIFY .SKIP 2$: SPWN$S T$ID(R3),,,,,, _#UPAST, T$STAT(R3), T$CMD(R3), R1, T$TTN(R3), _#"TT MOV $DSW, R0 BCS 3$ .JUSTIFY .FILL .SKIP and the CNCT$ directive code is deleted. Of course, you now lose the flexiblity of changing the installed task name. For most applications this is probably not critical. If an event flag is specified above, we gain the ablity to do such things as handle status reports based on priority. The AST routine can check for a flag which specifies a task status that requires immediate handling. The CNCT$ directive may also specify an event flag. To include this in the earlier example, change the SPWN$ call to: .NO FILL .NO JUSTIFY .SKIP 2$: SPWN$S T$ID(R3),,,,, T.EFN(R3), _#UPAST, T$STAT(R3), T$CMD(R3), R1, T$TTN(R3), _#"TT .JUSTIFY .FILL .SKIP and in the AST code: .NO FILL .NO JUSTIFY .SKIP CNCT$S T$ID(R3), T$EFN(R3), _#UPAST, T$STAT(R3) ... CLRB T$UPDAT(R3) RDAF$S _#FLAGS ; Read the event flags BIT _#1, FLAGS ; Test for flag _#1 BNE CODE ; Flag 1 set ... CODE: .JUSTIFY .FILL .SKIP The following modifications to the data structures shown in the original article are needed for this: .NO FILL .NO JUSTIFY .SKIP change T$LEN = T$STIME + 1 to T$EFN = T$STIME + 1 T$LEN = T$EFN + 1 T$MAX = 66. add FLAGS: .BLKW 4 .JUSTIFY .FILL .SKIP Another use of SPWN$ and CNCT$ is to make certain that tasks are always active. One application I support has seven independent modules supervised by a monitor / control task. The modules must be active for the system to function and have been written so that they may be restarted gracefully. By checking the status of the CNCT$ directive when the AST routine is entered, we can determine if the task is active. If the DSW is IE.ACT, the task is not active. We can now issue SPWN to restart that task. The code for the AST now looks like this: .NO FILL .NO JUSTIFY .SKIP CNCT$S T$ID(R3),, _#UPAST, T$STAT(R3) CMP _#IE.ACT, $DSW BNE 4$ SPWN$S T$ID(R3),,,,,, _#UPAST, T$STAT(R3), T$CMD(R3), R1, T$TTN(R3), _#"TT 4$: ... .JUSTIFY .FILL .SKIP Once again, RPOI$ could be used to start the task, but that requires a separate CNCT$ directive. I believe that using SPWN$ is cleaner and faster (well, experts - is it faster?). It is well worth remembering that you can make connections back to the parent task as well. In the application I mentioned above each of the seven modules are connected to the monitor. They use the restart on disconnect logic shown above, so if the monitor crashes, one of the others will fire it off again. This is very useful for systems that run unattended. One last note: Don't overlook Fortran when inplementing a scheme like this. All the directives needed are available to the Fortran user. Setting up the data structures is a little more taxing, but it is nice when the task will be doing more then monitoring. All our tasks mentioned earlier are completely in F77. Remember: "VMS is a senile version of RSX". .COMMENT .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT Rotating Lights for VT100 Terminals .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT .TEST PAGE 15 .SKIP 6 ###########^IC0000^IS328^GRotating Lights for VT100 Terminals^IS204^IC1000^G .SKIP .CENTER Dale R. Donchin .CENTER Manager, CAD Systems Group .CENTER Digital Equipment Corporation .CENTER 77 Reed Road, HL02-2/G13 .CENTER Hudson, MA###01749 .SKIP While cleaning up my directory recently, I found a few "gems" that I wrote long ago that may still be of interest to novice users. This one is a task called "LITE". LITE is a simple, non-privileged task which exercises the host VT100 using the VT1xx escape sequences. It also demonstrates the use of ASTs and AST service routines, including a novel method of calling a service routine from non-AST level. To enlarge on calling AST service routines from non-AST level: Remember that there is nothing particular about an AST service routine other than cleaning the stack and the method of exit; the Executive directive ASTX$S is used to exit from AST state. If an ASTX$S is issued when the task is not at AST level, the Executive returns directive error status IE.AST (directive not issued from AST service routine). This does not affect task execution; the task proceeds to the next executable statement. If the next executable statement is a RETURN, the same routine can both service ASTs and act as a task level subroutine. .SKIP ^IS144^GRookie RSX Macro programmers should study this program carefully, and understand why it works as it does. It demonstrates both good source coding practice and attention to run-time details, particularly in the abort AST routine. #--#The#Editor^IS204^G .SKIP 2 .TEST PAGE 7 .NO FILL .NO JUSTIFY .TITLE LITE VT1xx idle pattern and clock program .IDENT /V1.0/ ; Author: Dale R. Donchin ; Digital Equipment Corp. ; ; This program displays an "idle" pattern in the L1 to L4 ; LEDs on the VT1xx keyboard, while updating a time display ; in the upper left screen corner. It is "EDT-proof" in ; that it resets the scroll region on exit of applications ; like EDT that change the scroll region during execution. ; Declare system services used .MCALL ASTX$S, CMKT$S, DIR$, EXIT$S, GTIM$, MRKT$ .MCALL QIO$, QIOW$, SREA$S, WTSE$S ; Directive Parameter Blocks GETIME: GTIM$ DATBUF ONESEC: MRKT$ , 1, 2, UPDATE LDTIME: MRKT$ 2, 10., 1 RWRITE: QIOW$ IO.WAL, 5, 1,,,, LWRITE: QIOW$ IO.WAL, 5, 2,,,, < ,4> TWRITE: QIO$ IO.WAL, 5,,, IOSTAT,, CLRALL: QIOW$ IO.WAL, 5, 1,,,, KILLIO: QIOW$ IO.KIL, 5, 1 ; Data declarations DATBUF: .BLKW 8. ; Date buffer IOSTAT: .BLKW 2 ; I/O status block ; Escape sequences for turning LEDS on and off OFF: .BYTE 33,133,60,161 ; Turn all off ON1: .BYTE 33,133,61,161 ; Turn L1 on ON2: .BYTE 33,133,62,161 ; Turn L2 on ON3: .BYTE 33,133,63,161 ; Turn L3 on ON4: .BYTE 33,133,64,161 ; Turn L4 on ; Escape sequences and block for displaying time NEWTIM: .BYTE 33, 67 ; Save cursor .BYTE 33, 133, 61, 73, 61, 110 ; Home cursor ASCTIM: .BLKB 8. ; ASCII time block .BYTE 15 ; Carriage return .BYTE 33, 43, 66 ; Double width .BYTE 33, 70 ; Restore cursor NEWLEN = . - NEWTIM ; Size of data ; Escape sequences to reset terminal RESETT: .BYTE 33, 67 ; Save cursor .BYTE 33, 133, 62, 73, 70, 60, 110 ; Position to 2,80 .BYTE 33, 133, 61, 112 ; Erase to cursor .BYTE 33, 133, 63, 73, 62, 64, 162 ; Set scrol region .BYTE 33, 70 ; Reset cursor RESETL = . - RESETT ; Size of data ; Escape sequences to clear terminal upon exit CLRTXT: .BYTE 33, 133, 61, 73, 62, 64, 162 ; Clr scrol region .BYTE 33, 133, 60, 161 ; All LEDs off .BYTE 33, 133, 62, 112 ; Clear screen .BYTE 33, 133, 61, 73, 61, 110 ; Home cursor CLRLEN = . - CLRTXT ; Size of data .EVEN ; Main program begins. Specify exit AST and start up. START: SREA$S _#EXTAST ; Declare abort AST MOV _#-1, IOSTAT ; Tell UPDATE to reset MOV _#LOOP, -(SP) ; and where to return CALL UPDATE ; Reset and tell time ; Loop turning LEDs on and off LOOP: MOV _#ON1, LWRITE+Q.IOPL ; Turn L1 on CALL WAIT ; Do it MOV _#ON2, LWRITE+Q.IOPL ; Turn L2 on CALL WAIT ; Do it MOV _#ON3, LWRITE+Q.IOPL ; Turn L3 on CALL WAIT ; Do it MOV _#ON4, LWRITE+Q.IOPL ; Turn L4 on CALL WAIT ; Do it MOV _#ON3, LWRITE+Q.IOPL ; Back to L3 CALL WAIT ; Do it MOV _#ON2, LWRITE+Q.IOPL ; Back to L2 CALL WAIT ; Do it BR LOOP ; Restart with L1 ; Little routine to light LED, wait, and clear LED WAIT: DIR$ _#LWRITE ; Turn the LED on DIR$ _#LDTIME ; Wait a while WTSE$S _#2 ; Let LED shine MOV _#OFF, LWRITE+Q.IOPL ; Now turn it off DIR$ _#LWRITE ; Do it RETURN ; Return to caller ; Come here once a second to update time. If here, but the ; previous I/O is not complete, then reset terminal first. UPDATE: TSTB IOSTAT ; Previous I/O complete? BGT 10$ ; Branch if yes DIR$ _#KILLIO ; Else abort it DIR$ _#RWRITE ; Reset terminal 10$: DIR$ _#ONESEC ; Requeue 1 second timer DIR$ _#GETIME ; Meanwhile get the time MOV _#ASCTIM, R0 ; Address to put it MOV _#DATBUF+G.TIHR, R1 ; Address of binary time MOV _#3, R2 ; Convert in HH:MM:SS CALL $TIM ; Convert time to ASCII DIR$ _#TWRITE ; Display it TST (SP)+ ; Pop stack from AST ASTX$S ; Exit AST for awhile RETURN ; At initialization only ; We've been aborted. First clean up, then exit. EXTAST: DIR$ _#KILLIO ; Kill any I/O CMKT$S ; Cancel any timers DIR$ _#CLRALL ; Reset the terminal EXIT$S ; Now exit .END START .JUSTIFY .FILL .COMMENT .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT Spring 1987 Software Clinic .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT .TEST PAGE 15 .SKIP 6 ################^IC0000^IS328^GSpring 1987 Software Clinic^IS204^IC1000^G .SKIP .CENTER T. R. Wyant .CENTER RSX Clinic Coordinator .SKIP Judging by the forms turned in, the RSX Software Clinic held at the Spring Symposium brought the usual broad spectrum of requests. I regret that we were unable to glean more of these - I believe the problem forms here represent less than half the problems actually presented to the clinic. The transcripts below represent those forms I do have. I have not been entirely able to refrain from editorializing, but I have attempted to make it clear which portions represent my ramblings. .LEFT MARGIN +3 .SKIP 2 .INDENT -3 Q: Under RSX-11M+ V2.1, BRU created a multi-volume, multi-backup tape. Can you retrieve anything off the second volume (or third, etc ...) and if so, how? .SKIP .INDENT -3 A: Nothing official. Must skip past garbage at the beginning of the second save set with a self written utility, then use BRU. .SKIP 2 .INDENT -3 Q: How do you do global command files? .SKIP .INDENT -3 A: Look it up; see [*,24]ICPxxxBLD.CMD. (Editor's note: Under M+, by default any command file in [3,54] is a global command file. You can disable this by changing the .SKIP GBLDEF=D$CUIC:nnn .SKIP in [1,24]ICMxxxBLD.CMD, then rebuilding ICP. Instructions for doing this are in the file. If this file does not exist, edit [1,20]ICMBLD.BLD instead, then do a component mode SYSGEN to create ICMxxxBLD.CMD and rebuild the ICP. This patch allows you to turn global command files off, or locate them in any numbered directory. .SKIP 2 .INDENT -3 Q: Have a PDP-11/23. Trying to install RSX-11M V4.0. Have several problems; COPY, DIR, How to put applications program on, Fortran IV V2.5. .SKIP .INDENT -3 A: In [1,2]STARTUP.CMD, insert "INS $TDX". This lets COPY, DIR, etc. be passed to TDX (installed as ...CA.). To enable DCL to pass unrecognized commands to MCR, build DCL with the catchall and "." facility. Refer to file [1,24]DCLBLD.CMD for details. Rebuild DCL using the edited command file, and VMR the new DCL in. Editor's note: It would be keen if DEC would build DCL with MCR as its catchall by default under M as well as M+, though I note that this is an old version. .SKIP 2 .INDENT -3 Q: How can I tell (from DCL if possible) whether a port has a in effect that is hanging the port? Also, how can this state be cleared other than by typing at the hung port? This question relates to hung remote terminals that cannot be easily freed. .SKIP .INDENT -3 A: Three possibilities: (1) Use HPFIX off the SIG tapes, (2) Get multiple characteristics and verify really , (3) Clear bits by clearing U.CTRLS. Be aware that some terminals know whether they have sent a , and behave oddly unless a is actually typed. You can not (in the general case) use set multiple characteristics to clear the . In particular, if a write is already posted to the unit, SF.SMC is queued until the write completes. Catch-22. If you intend to write your own code to do this, read the device-specific modules in the TT: driver. The modules are in directory [11,10], with names like TTYL.MAC (DL11s), TTYZ.MAC (DZ11s) and so on. .SKIP 2 .INDENT -3 Q: How to find commons being referenced in subroutines in a Fortran list file. .SKIP .INDENT -3 A: (1) Look in the Fortran OTS manual under "List file". (2) They're listed at the top of the storage map. FORTRAN generates a few of its own. If you read this correctly, you can even tell what variables are in what commons. .SKIP 2 .INDENT -3 Q: What is the best procedure to handle a symposium tape? It's hard to examine because there is so much out there. .SKIP .INDENT -3 A: Put the tape on a virtual disk. .SKIP 2 .INDENT -3 Q: How do I convert 3rd party interactive software to batch software? A problem is that the hangs up the terminal. .SKIP .INDENT -3 A: See Batch and Queue Operations manual, chapter 3, page 6. .SKIP 2 .INDENT -3 Q: How do you do multiple logins? .SKIP .INDENT -3 A: Use SPAWN or RPOI. .SKIP 2 .INDENT -3 Q: IND detected an error on a global symbol. Global symbols were not defined. The statement was printed during execution due to the undefined symbol. IND did not provide an error message, nor was execution of the command file terminated by IND. .SKIP .INDENT -3 A: An attempt will be made to duplicate this condition in other command procedures before submitting an SPR. .SKIP 2 .INDENT -3 Q: Migrating M to M+. Problem mapping resident data common with I/D tasks. .SKIP .INDENT -3 A: Map common flat and use RESLIB= in taskbuild command file. Editor's note: This must have lost something in the translation. There are known problems with mapping F77 reslibs with I/D tasks - TKB forgets to mark the "D" page mapped by the library as in use. It may then try to map the rescom with the "D" space APR it should have used for F77RES. .SKIP 2 .INDENT -3 Q: When upgraded from RSX-11M+ V3.0 "C" to "D", DTR can no longer find files unless given an explicit UIC or directory name. .SKIP .INDENT -3 A: Patch to DTR omitted when update "D" installed. As an added feature, KERMIT has same problem. .SKIP 2 .INDENT -3 Q: How to use the virtual memory subroutines documented in the SYSLIB manual. .SKIP .INDENT -3 A: Suggest using PLAS directives instead. Editor's note: Does this mean DEC doesn't understand them either? .SKIP 2 .INDENT -3 Q: We are using 4 DHVs on an 11/73 to communicate to 28 11/23s. The DHVs preferentially service one line when several are active. We need to force the DHV to give each line a fair time slice. Thought about token passing, but are unsure to stick with the TT: driver or write a driver or CINT$ task. .SKIP .INDENT -3 A: Suggested a polling scheme using the TT: driver. .SKIP 2 .INDENT -3 Q: LOA gives multiprocessor "ICB failure on CPU A" .SKIP .INDENT -3 A: Don't VMR driver into system. LOA driver /HIGH/PAR=GEN with MCR. Debug it before loading with VMR. (VMR doesn't have much ICB space?) Editor's note: Since a loadable driver is not normally mapped by the Exec, interrupts cannot be vectored directly to it. Instead, an Interrupt Control Block (ICB) is built, which is entered when an interrupt occurs. The ICB maps and jumps to its driver. In an M+ system with Kernel data space, ICBs are allocated in "ICB pool" (NOT to be confused with DSR, or "Pool"). A limited amount of ICB pool is built into the system. When the system is booted, module INITL does useful things. Once done, the code is no longer needed - so INITL's last act is to deallocate itself to ICB pool. The net effect is that VMR LOA may fail to allocate an ICB, but MCR LOA succeeds - on the same system! The initial amount of ICB pool is selectable by SYSGEN question CE110. The default is 128 words. .LEFT MARGIN -3 .COMMENT .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT Spring 1987 Symposium Tape Available .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT .TEST PAGE 15 .SKIP 6 ##########^IC0000^IS328^GSpring 1987 Symposium Tape Available^IS204^IC1000^G .SKIP .CENTER Glenn Everhart .CENTER Chair, RSX SIG Tape Working Group .CENTER RCA A_&D Engineering, 206-1 .CENTER Route 38 .CENTER Cherry Hill, NJ###08358 .SKIP The SIG tape from the Spring 1987 symposium in Nashville is now available through both tree and NLC distribution channels. The tape consists of two parts. First are the files submitted in Spring 1987. These consist of about 22,000 blocks. Since there was room left, a second part was added. These are files which appeared on SIG tapes from Fall 1977 to Spring 1979. These files are selected as still appearing useful; the listing below is only part of what's on the tape. The 1977 - 1979 tapes are not available via the DECUS library, so this material has not been recently available via DECUS. .SKIP 2 Area I: New Items for Spring 1987 .SKIP .LM +11 .TAB STOPS 21 .INDENT -11 [5,4] DECUS C updates for I/D space .INDENT -11 [5,15] " .INDENT -11 [5,16] " .INDENT -11 [5,24] " .INDENT -11 [307,20] Upgraded virtual disk package for M+ .INDENT -11 [312,315] VMS virtual disk, RSX FOCAL, TECO Doctor, Unix program to read VMS Backup tapes, UUCP lookalike archives, DISOWN, RSX task disassembler. .INDENT -11 [312,361] UUCP clone sources. Not RSX but may be possible to get working. .INDENT -11 [312,371] AnalytiCalc RECALC minor bugfix. .INDENT -11 [321,5] Structured Macro library. Q-bus clock routines. .INDENT -11 [337,50] Hitchhiker's Guide to RSX .INDENT -11 [344,*] KMSKIT - lots of stuff. .INDENT -11 [350,340] Pipe Driver for task to task comm. .INDENT -11 [350,124] ODS-2 ACP for RSX .INDENT -11 [350,125] " .INDENT -11 [351,73] IAS AUX, ECR, skeleton IAS handler. .INDENT -11 [351,144] Terminal emulator .INDENT -11 [351,145] AT. session notes and examples .INDENT -11 [356,40] RSX KERMIT .INDENT -11 [356,41] VMS TPC .INDENT -11 [356,42] Bitnet servers sources .INDENT -11 [356,45] IAS Kermit-11 .INDENT -11 [370,352] MYMACS.MLB, CLE command line editor. .INDENT -11 [370,365] Fortran aids and tools. SST handlers, DL driver fix, undeletion, SEARCH, binary file compare, more. .SKIP 2 .INDENT -11 Area II: 1977 - 1979 Stuff .SKIP .INDENT -11 [264,2] 3D plot package .INDENT -11 [270,1] MRMLIB signal processing and subroutine library .INDENT -11 [277,1] 68000 and 8085 cross assemblers .INDENT -11 [300,52] Fortran-callable FCS access subroutines .INDENT -11 [301,16] SSP - Scientific Subroutine Package sources .INDENT -11 [301,27] Fortran callable matrix subroutines. .INDENT -11 [301,50] Dungeon (Zork) binary version. .INDENT -11 [301,22] CHESS .INDENT -11 [302,106] Lunar lander and maze games .INDENT -11 [303,1] How to run giant (100K lines) Fortran programs .INDENT -11 [303,40] RSX mailbox handler .INDENT -11 [307,5] Fortran callable routines for random access to sequential files and multiple precision math. .INDENT -11 [307,11] Blackjack, worm, Pong, technical paper writer. .INDENT -11 [307,22] Disk disaster recovery tools for ODS-1 .INDENT -11 [312,356] Infinite precision calculator. Bitfield handler subroutine. .INDENT -11 [321,2] RATFOR. SCCS implemented as a command file. .INDENT -11 [321,3] SUPERMAC .INDENT -11 [323,2] CSMP - Continuous Systems Modelling Program .INDENT -11 [330,11] Fortran resequencer .INDENT -11 [337,30] Graphics package for Tektronix terminals. .INDENT -11 [340,1] ARC MAIL utility (DECnet not needed). .INDENT -11 [340,20] DOC - Generation of documents from template. KWC - generate KWiC index listings. .INDENT -11 [341,1] TECO file formatting macros, call tree building, disk free block zeroer, what file contains an LBN, more. .INDENT -11 [341,307] ELIZA with objects. The computerized psychoanalyst. .INDENT -11 [342,2] The full TECO V36 distribution .INDENT -11 [343,40] Foreign Tape Processor. Handles many foreign formats. .INDENT -11 [344,30] CVL - Change Volume Label. FRAG - disk fragmentation report. .INDENT -11 [346,100] Stamerjohn's ACP manuals, virtual disks, loadable XDT, index of early RSX tapes, CDA workbook, and more. .INDENT -11 [370,70] Description of Fortran OTS .INDENT -11 [370,130] INDEX - Fortran cross reference program. The best. .INDENT -11 [373,4] RENUM, renumbers Fortran, generates indented listings. .INDENT -11 [373,7] File recoverer - undeletes a freshly deleted file. .LM -11