Favorite RSX problems This paper began its life with the suggestion that perhaps the same questions came up repeatedly in the software clinic. A symposium presentation was duly scheduled, and notes from previous clinics were pulled and studied. The suspected repeatability was found, but it turned out to be at the topic level, not the question level. The question then became, what to do with the information? The obvious thing was to order the clinic notes by topic and re-issue them. That is the easy solution, but also probably the deathly dull one. In an Favorite RSX Problems attempt to improve on this, I have attempted to write a few paragraphs about each of the "hot" topic areas. There is no attempt here to give comprehensive coverage of these topics, but to capture those areas which, if the clinic is a guide, prove troublesome in practice. - DA012 - 1 FAMILY DIFFERENCES The RSX phylogenetic tree is unusually richly branched. This can lead to some confusion, especially between RSX-11M+, RSX-11M, and RSX-11S. Thomas R. Wyant, III RSX-11M+ is unique in the RSX family in a number of E. I. DuPont de Nemours respects: Richmond, Virginia * It supports I&D space. * It supports symmetrical multiprocessing, which would be a moot point (there being no commercially available SMP hardware), except that the May 5, 1992 configuration control functionality (CON ONL, CON OFF) is a consequence of this. * It can load more than 124Kw at boot. This can cause confusion, as you can BOO a large M or S system from M+, but not from M; this is a (by all indications permanent) restriction to the other systems. RSX-11M+ requires a 22-bit PDP-11 on which to run. That is, there is a way to GEN it for 18-bit systems, but you are on your own if you do so. It does not technically require an I&D space processor, but you should expect to find yourself extremely short on pool if you don't use one. Micro-RSX is just a variant of M+, built from the same kit. Though M+ is larger than M, it may be faster; some code paths have been optimized for speed, whereas in RSX-11M they were optimized for size. Favorite RSX problems Favorite RSX problems RSX-11M is rather mature now, and typically only gains * Task ...xxx is never active under M+, though it is new features by the "trickle-down" effect. Unlike RSX-11M+, the first of its kind to be activated under M. RSX-11M is maintained in such a manner that it can run on any PDP-11 ever sold, and this can also restrict the * The RPOI$ directive is restricted to CLIs under M. features available. There are a lot more configuration options for RSX-11M than for M+; this is partially offset by * The inheritance of default directories is different the fact that the RSX-11M SYSGEN is cleaner than the M+ one. between M and M+, due to the way named directory For example, you give SYSGEN a list of the devices you want, support was done. Under M+, a task inherits its and it asks only questions relevant to those devices (as default directory from the task that spawned it, opposed to M+, which asks an endless series of questions not from the terminal. This means command buffers like "How many PC-11 paper tape readers do you have?"). and such need to issue a SDIR$ .. SD.TI directive to re-acquire the correct default before each RSX-11S is a "proper subset" of RSX-11M, designed to spawn. run in a memory-only configuration, booted either from a local disk or over the net. The major changes involve removal of F11ACP (ie - no system support for Files-11), multiuser protection, and of command line support. Other system features (like memory-resident overlays, 2 OVERLAYS parent-offspring tasking, send/receive, etc.) tend to be there. Most MCR commands are also gone; the minimal system Overlays are the canonical way to get five pounds of includes TIM, RUN, and REM. There is no INS, but there is a code in a two pound bag. If done properly, they can get you task called OTL ("Online Task Loader") which can install a lot of functionality in a little address space. If done tasks off RT-11 format floppies or DOS-11 tape. Since improperly, they can result in a task that won't run, or RSX-11S has a small installed base and OTL is not shared even a task that won't taskbuild. with RSX-11M, it tends to be a bit buggy, with the bugs generally being in the area of header setup. The best time to overlay a task is before it's coded. Plan to segment functionality into several independent (or Independent of the RSX variant, there are two varieties fairly independent) modules, rather than one megamodule. Of of the TT: driver -- the half-duplex driver and the course, this is a good idea even if you don't need to full-duplex driver. The full-duplex driver offers more overlay. functions, such as true full-duplex operation (you can have a read and a write posted at the same time), RSX requires you to organize overlays into one or more device-independent cursor positioning, table-terminated trees. The root of the main tree is your main module - that reads, command timeout, and so on. It's also bigger. is, the one that first gets control when the task runs. RSX will (if you ask it) autoload other segments as they are Users of the half-duplex driver need to be aware that a called, making overlays, if not painless, at least not control/U, though it cancels an MCR command, does NOT excruciating. release the command buffer (and therefore does NOT free the terminal for I/O). You MUST follow the control/U with a There ARE some more-or-less arcane rules for return if that is your intention. constructing overlay trees, but they are all based on the following principle: Any attempt to refer to data or code Porting user-mode code among the variants of RSX is that is not in memory is doomed to failure. generally no problem. Code written under RSX-11M generally runs unmodified under M+, though some of the M+ features DEC has made it fairly difficult for code not to be in (such as named directories) can be picked up by relinking. memory, but you can force out a module you need if you're Similarly, code linked under M+ generally runs under M, not careful of your calling relationships. For example, in provided it uses no M+ specific features. the following tree There are, however, some differences in task dispatching that may need to be attended to: Favorite RSX problems Favorite RSX problems ROOT There is a third solution - to put the routines in a | cotree. Basically, instead of a single tree, the task A becomes an orchard. Any routine on one tree can call any / \ routine in another tree, as long as you avoid the cotree B C version of the "A-B-C" example above. Routines in a cotree can call each other with the usual restrictions. "A" can call either "B" or "C", and whichever one gets called gets loaded in. But if the root calls "B", then "B" Overlaying is a useful technique only when the calls "A" and "A" calls "C", "B" has been overlaid by "C", overlaying modules don't change, or when changes can be and all perdition will break out when "A" tries to return to ignored. This makes it (sometimes) great for code, but "B", landing instead at some random location in "C". (generally) useless for data. Those with a need to cram five pounds of data in a two pound bag should look into Another way to screw up would be for the root to files, virtual arrays (in FORTRAN - a BASIC virtual array is declare "B" as an AST, then call "C". The AST mechanism has a file), or perhaps memory-resident overlays (which still no way to load overlays, so when the AST fires, control goes have to be loaded by hand). to whatever random location in "C" corresponds to the AST entry point in "B". Moral: Put AST routines in the root, unless you intend to be VERY careful about who calls who when. 3 I&D SPACE. Data is also susceptible to corruption by this process So what is I&D space anyway, and what does it buy me? - in fact, perhaps more so than code. Most problems of this The answer requires a brief tour of the PDP-11's sort occur when a routine saves the address of some data, architecture. A PDP-11, any PDP-11, can only address 64Kb then uses it later. FORTRAN ASSOCIATEVARIABLEs, for of memory at a time. This restriction is evaded somewhat by example, should probably be in the root; at the very least, the Memory Management Unit; you can still see only 64Kb at a you MUST close the file before overlaying the module the time, but it can be the 64Kb of your choice (sort of) out of variable is in. I/O buffers and status blocks would also be the 4Mb the bus can address. This is good for the a problem if the I/O is asynchronous; in synchronous I/O the executive, but still involves some penalties for the system is done with the addresses before you leave the application programmer: a memory-resident overlay, for module. One way to force variables into the root is to example, is still an overlay. declare them in commons (FORTRAN) or as "extern" ("C"). But on some PDP-11 models, the Memory Management unit Problems with overlays can also occur when code has twice as many registers as you'd expect, and the modifies variables initialized with DATA statements, then capability to tell the difference between an instruction makes assumptions about whether the modified value is access and a data access. The last is pretty simple, preserved from one call to the next. In brief, if the really: any access through the PC register (including overlay was forced out and reloaded, the variables got fetching the offsets for address modes 6 and 7, regardless re-initialized. If not, they didn't. The safe thing to do of which register was specified) is an "instruction" access; is not to modify variables initialized with DATA statements. anything else is a "data" access. All this can leave the poor programmer with a real Hence I&D, for "Instruction and Data". Given an dilemma about where to put utility routines in the overlay operating system that supports it (M+, MicroRSX, and tree. If they're put in the root, they can't overlay each Coprocessor/RSX do, M and S don't) What it buys is simple. other, and the overlay tree looks like a palm tree, with Instead of having a total of 64Kb at its disposal, a task most of it's height being trunk, and branches bushing out at can have 64Kb of instructions PLUS 64Kb of data. This is no the very top. If they're put at the tips of the branches, big deal for tasks that are mostly code with a little data you need many copies of each, and the task image becomes or vice versa. But it can significantly flatten (or immense -- possibly to the point where the task builder eliminate!) overlays for tasks with about the same amount of can't build it any more. each. Favorite RSX problems Favorite RSX problems Unfortunately, there's no such thing as a free lunch. data in .PSECTs with the "D" attribute. While you're at it, Though the CPU knows (by convention!) what's instructions you may want to divide readonly data from read/write data and what's data, the Task Builder doesn't; it can't afford (using the "RO" and "RW" .PSECT attributes respectively), so to make that kind of assumption, and relies on the compilers the /MU taskbuilder switch buys you space also. It will and assemblers for this information, in the form of .PSECT suffice to have three .PSECTs: declarations. If the information is there in the objects, all you have to do is apply the /ID switch, and you're .PSECT PURCOD RO,I,LCL,REL,CON ; For Code there. If it isn't, you can't use I&D space for that particular task. .PSECT PURDAT RO,D,LCL,REL,CON ; For RO data What determines whether the .PSECT information is there .PSECT IMPDAT RW,D,LCL,REL,CON ; For RW data depends on where the object module came from. If it's a MACRO-11 module, it's there if you put it there. If it's a high-level language module, it's there if the language All you need to do is to insert one of the above lines in supports it and the compiler is configured for it (NOT the front of each section of code or data. Once you've defined same thing, and PDP-11 Fortran-77 is a prime example!). If a .PSECT, you don't need to repeat the attributes every time it's a library module it reduces to one of the above two you use it (though it won't hurt to do so). Just it's name cases, with the complication that if the .PSECT information is enough for the task builder, eg: ISN'T there, there may not be much you can do about it. .PSECT PURCOD As mentioned above, Fortran-77 supports I&D space, but the compiler must still be configured to emit the proper for all blocks of code after the first one. code. The reason is that the FORTRAN OTS sometimes uses calls with linkage registers, and linkage registers don't You'll also have to find all uses of linkage registers, work in an I&D space environment. "Linkage registers" and recode to eliminate them. refers to subroutine calls like the following: JSR R4,FOOBAR .WORD DATA 4 SYSTEM MANAGEMENT 101 In this example, R4 serves as the linkage register. The There is a miscellany of "problems" with managing an subroutine refers to the in-line data with instructions like RSX system, many of which come down to "what command do I issue to ...". This kind of question appears to arise from MOV (R4)+,R0 a number of sources, including: not realizing the nature of the problem, incomplete documentation sets, or incompletely and returns (after R4 has been properly positioned) with or inobviously documented functionality. This kind of "RTS R4". Without I&D space, the technique of using linkage question has been grouped here under the title "System registers and in-line code saves space. With I&D, however, Management 101". it doesn't work - TKB puts the data in instruction space, but the CPU looks for it in data space. So the Fortran-77 compiler MUST be configured to produce code that doesn't use this technique. The bad news is that you have to relink the 4.1 The DCL Interface compiler to do it (the type of code emitted is determined by a GBLDEF in the taskbuild command file). The good news is DCL is not native to RSX, but was layered on top of MCR that you probably don't have to keep two versions of the as an "alternate" command line interpreter. An RSX system compiler around, as code configured for I&D space will still will support up to 15 alternate CLIs, with MCR, DCL, CCL, work when linked without the /ID switch. and so on co-existing happily; users can switch between them with a simple SET command. In MACRO-11 modules, you have to do all the sectioning off of code and data yourself. Basically, this is done by placing instructions in .PSECTs with the "I" attribute, and Favorite RSX problems Favorite RSX problems Alternate CLIs were implemented with the RSX group's 4.3 Pool Conservation usual minimalist economy; all the alternate CLI does is dequeue its command, translate it to the equivalent MCR System managers are frequently looking for more pool. command, and reissue the new command to MCR. Use of LAT terminals can gain you pool, but only if you you end up with fewer TT: units by so doing. Unused TT: ports DCL was implemented using a fairly involved parser and should be SET /SLAVE; likewise TT: ports connected to "odd" a two-step translation scheme. This evidently gave the devices, as a "streaming" line can deplete pool in a developers some trouble, as DCL has to this day the command heartbeat. On an M+ system, the terminal should be slaved SET DEBUG, which causes DCL to display the MCR command it before it is CONed ONLINE. On an M or S system, it must be generated from your DCL command, rather than passing it to done in VMR. MCR for execution. This can be valuable when you can't figure out why DCL won't do what you want. For example, Occasionally, you can gain contiguous pool by SET there are at least three different FORTRAN compilers /MAXPKT=0, followed by setting it back to the normal value. available under RSX: ...FOR (FORTRAN IV), ...F4P (FORTRAN This works because I/O packets go into the MAXPKT queue when 4+), and ...F77 (FORTRAN 77). The cheap way to get DCL to deallocated, and they were originally allocated from random invoke the one you want is to use SET DEBUG to find out what locations in pool. DCL's default FORTRAN is, and install yours accordingly. You use SET NODEBUG to get back to normal operation. Many CLIs under RSX also implement the idea of a 4.4 Getting A Crash Dump "catchall"; that is, a task which gets the command if the current CLI can't make heads or tails of it. DCL can be Sooner or later (sooner if the pool problems aren't built so that MCR is its catchall, and in fact it is mastered), the system manager needs to force a crash dump. distributed this way for M+. But RSX-11M, the last time I The general method is the same for any RSX system: force a looked, still distributed DCL with no catchall. To turn on transfer of control to address 40 (octal), which contains a this capability, edit DCLBLD.CMD (instructions are in the JMP to the crash code. How the method is implemented, file) and relink. however, depends on the CPU involved: * 11s with a console subsystem: 4.2 Console Logging 1. Type control/P to get the console prompt (>>>). All console subsystem commands are terminated Console logging is a facility that captures all output with the key. to CO: in a file for your later reading enjoyment. It can be a real boon if your console terminal is a CRT, or if over 2. Type "H" to halt the system. zealous neatniks tend to trash critical console listings. All messages are time stamped (though not date stamped) on 3. Type "D/G 7 40" to deposit 40 in the program the left. The drawback is that ONLY output to CO: is in counter. the log file; output directly to TT0: will not appear, nor will output that bypasses the operating system completely, 4. Type "C" to continue the processor. such as crash notification. To turn it on, simply SET /COLOG=ON 5. If this fails, type "S 40"; this initializes You can start a new log file by the processor, thus losing you the state of the SET /LOGFILE= memory management registers. (no, there's nothing after the "="). The log files end up in LB:[1,6]. * 11s with console ODT: 1. Type control/P to get the ODT prompt ("@"). Console ODT commands don't need the key unless explicitly stated. Favorite RSX problems Favorite RSX problems 2. Type "H" to halt the system. 4.6 Emergency Entrance 3. Type "$7/" to open the program counter; its Occasionally a system manager must gain access, on an contents will be printed. emergency basis, to a system for which he/she does not have a password. The following procedure has worked on every RSX 4. Type "40" (with carriage return) to deposit 40 system the author has tested: in it. 1. Reboot 5. Type "P" to proceed. 2. Soon as the system identifies itself, start typing 6. If this fails, type "40G", which initializes control/C as fast as you can. the system. 3. When you get an MCR> prompt, enter "REM ...AT.". This will cause the startup command file not to run * "Real" 11s, with toggle switches and blinking (since there's no "@" processor to run it), leaving lights: you logged on to the system console as a privileged user. Regrettably, the author no longer has access to such equipment. This works because ...SAV unslaves the system console on reboot - so even if TT0: is slaved in VMR, there is a "window of opportunity" between the time MCR becomes available and the time [1,2]STARTUP.CMD is dispatched (to possibly slave TT0: again). 4.5 Disk Management Lest the VMS people get too smug, a similar procedure One of the realities of a modern file system is that is available for the VAX: disk space WILL become fragmented. The DEC-approved way to deal with this is to use BRU to back up and restore the 1. Do an interactive boot ("B/1" on a MicroVAX). disk. People with single-disk systems are in a slightly awkward position, but can get by with standalone BRU. As 2. On receiving a SYSGEN prompt, enter 'SET distributed, you can find standalone BRU in UAFALTERNATE 1'. For a VAXstation, you'll have to LB:[1,64]BRU64K.SYS, which you can bring up using "BOO". 'SET STARTUP_P1 "MIN"' also. Then "CONTINUE" Tape-resident versions are available, or can be made yourself with BRU64K.SYS, BRU64K.STB, and a suitable copy of 3. After the system comes up, you should be able to VMR (you'll need the 11M version, as standalone BRU is based log into SYSTEM using any password of appropriate on RSX-11S). You probably want to have the tape on hand length. Don't forget to run SYSGEN again to put even if you normally use the disk-based version, just in the modified parameters back as they were. case your disk gets clobbered. The above procedure can be defeated by actually providing an Another fact of life is that systems evolve. The alternate UAF. If that has been done, then at the SYSGEN addition of named directory support to RSX-11M+ was NOT prompt 'SET/STARTUP=OPA0:'. This causes the system to transparent, due to the need not to break existing attempt to use OPA0: as the startup command file. applications. This left old applications unable to reference named directories. The fix for this is in most cases very simple; re-link the application. If the application relies on FCS, RMS, or CSI$ to parse the file 4.7 Miscellaneous Tweaks And Twiddles spec, and if the application is not so tight that the expanded functionality won't fit in the available address Various RSX utilities, such as CMP, will sometimes give space, this is all that is needed. Don't forget that this errors such as "XXX -- Dynamic Storage Allocation Failure". works not only on your own code, but DEC's (eg: compilers) These tasks use available space in the task's partition, and DECUS's. past the end of the task, as their work area. For some Favorite RSX problems Favorite RSX problems reason known only to the developers, they refuse to use the little to nothing about what you want it to do; you just EXTK$ directive to acquire more space. However, you can describe the local configuration and DECnet figures out the manually increase the available memory by installing these rest. Routing, for example, happens automatically providing tasks /INC=nnnn. You will have to play around a bit to find routers are available (and routers aren't required if the out what the maximum is; /INC=MAX was "Noted" at one point, nodes are adjacent and have only a single DECnet line). but may not have made it into RSX. 5.1 Managing DECnet/RSX 4.8 Peering Under The Hood Managing a DECnet/RSX system consists mainly of One of the advantages of RSX is that you get the managing the node table and the communications buffers. source. As the code is its own most accurate documentation, Managing the node table can be a problem in a large net, reading it can clarify points about how RSX really operates. with nodes coming and going frequently. The strategy of Unfortunately, you don't get the code to ALL the components, choice in this case seems to be to set up a distribution just the executive; and typically you get nothing for tree, with one (or a few) nodes having the master list, and layered products but an object library. You can, however, others getting it from them. RSX has an NCP command to disassemble the modules in the library if you have a crying support this: need to know what's in them. There are a couple disassemblers available on the RSX tapes, including DOB and >NCP COPY KNOWN NODES USING source ORC. where SOURCE:: is the node you intend to get the node list from. There are a couple caveats here: 4.9 Strange But True * NCP does not update the static database; you'll have to define a minimal database by hand, and issue the NCP copy command every time you want an * The output volume of a disk-to-disk BRU can have update. different numbers of occupied blocks than the input volume, due to the possibility of lost files (or * DECnet keeps most of its information in private files with multiple directory entries), and pool (partition POOL..). This includes the node differences in [0,0] (particularly BADBLK.SYS on table. POOL.. does not expand, nor does DECnet non-MSCP disks). .LE;Any utility that uses the cease operation when it fills up; instead, DECnet GCML$ interface (and most of them do) will accept starts using primary pool. Unless POOL.. has a any number of output file specs, and ignore the LOT of freeboard, NCP COPY KNOWN NODES (or any extras. This came to our attention when someone other procedure that adds a bunch of nodes to the asked the function of the third output file of MAC. table) can send you down the tubes. Managing the communications buffers consists mainly of being sure there are enough. The critical quantities here 5 NETWORKING AND DATA TRANSFER (all defined as SYSTEM parameters in CFE) are: RSX systems are frequently found in data collection * MAXIMUM LINKS applications. Getting the data into and out of the RSX The maximum number of connections AND CONNECTION system over a network (DECnet or otherwise) then becomes one REQUESTS outstanding at any point in time. of the implementation tasks. * LDB (Large Data Buffers) DECnet is a surprisingly easy networking system to use Used as data buffers by DECnet. According to the (that is to say, I learned on DECnet and have found other manual, you'll need one per logical link plus at systems appallingly difficult). Typically, you tell it least one per line (more for high-speed lines). Favorite RSX problems Favorite RSX problems These come out of POOL.. if space is available. * Service the mailbox LUN periodically, if the logic of your code allows it. * SDB (Small data buffers) Used for interrupt messages. The manual says to * Use the SPA$ macro (yes, you have to use MACRO-11) allocate them similarly to LDBs (one per link plus to fire an AST on receipt of a mailbox message. at least one per line), plus a couple more "for the The AST dequeues messages as they arrive, pot". These also come out of POOL.. if space is remembering to reject any connect attempts so the available. resources are deallocated. * CCB (communications control buffers) Used to manage the LDBs and SDBs; you'll need one for each of the above. These come out of primary pool. 5.2 Communicating With VMS Networking between RSX and VMS systems is generally not There are two ways to know when you haven't got enough. the problem it is perceived to be. The differences in One is the NCP SHOW component COUNT command, which will show machine architecture are, as it turns out, no problem. you if you're getting allocation failures. These failures Differences in operating system can be (especially in the are accompanied by performance degradation, which will be realm of user authentication), but the problems are noticeable if the failures are sufficiently frequent. The generally manageable. And though the software interface to second symptom is the failure to establish DECnet links due DECnet LOOKS vastly different between the two systems, to insufficient DECnet resources. NTD (which itself uses there's really no problem here either. one to two DECNet links) and the DECnet RMDemo pages (which you have to build into RMD yourself using Most problems with RSX-to-VMS networking revolve around [200,200]UNSGEN.CMD) can give you an idea of what links you user authentication. Modern versions of RSX-11M+ support have up at any given time. There's a caveat here, hinted at proxy logins, which is a big help (for one thing, the VMS under "MAXIMUM LINKS" above: connect requests are not links people understand it). The proxy database is maintained (except for the purposes of the NTD display that counts using [5,54]PROXY.TSK. For proxies to work, however, a links outstanding), but they consume all the resources of a couple conditions must be met on the RSX side: link. One way to soak up any amount of DECnet resources works like this: * You must be running accounting (which implies M+). 1. Write (as we all do) a DECnet task "A" that accepts * If the RSX system initiates the link, it must be a link and then just sits around processing data, initiated from a terminal that was logged in while ignoring anything that might come in on its mailbox accounting was active. This generally excludes LUN. tasks run from the clock queue. 2. Have task "B" connect to task "A". Other ways of getting the access control right include aliases on the RSX side, and default accounts (possibly 3. Have task "C" attempt to connect to task "A", attached to DECnet objects) on the VMS side. If explicit retrying periodically. The connect requests will passwords need to be exchanged over the net, remember that remain queued to "A" (though they time out to "C") earlier versions of RSX have an eight character maximum on until "A" either dequeues them or exits. passwords. There are several (not necessarily mutually exclusive) ways Once the formality of access control is taken care of, to deal with this: links are initiated and accepted in the usual way. The RSX side calls OPNNTW followed by BFMTn and CONNTW to initiate a * Wait for the symptoms to occur, and then track down connection, and OPNNTW followed by GNDNTW and ACCNTW to the culprit and shoot him/her/it. accept a link. The VMS side, if using transparent DECnet, opens '"TASK=name"' to initiate a connection to the named task, and opens SYS$NET to accept a connection. A Favorite RSX problems Favorite RSX problems connection must be both initiated and accepted to be _ ; should show you 177774 successful. If, for example, an RSX task issues a CONNTW _ 240 ; NOPs the second word call to a VMS command procedure which does not open SYS$NET _ ; should show 001xxx (or run a program which does) the RSX task will eventually _ 240 ; NOP the last word get "no response from object". _ ^Z ; CTRL-Z out. Almost any VMS program can create, open, read, and 5. Now do whatever is necessary to restart DECnet with write files on an RSX system just as though they were on a the new copy of NETACP. The minimum is probably: remote VMS system; just put a node name on the front of the >NCP SET EXECUTOR STATE OFF file spec. This works not only for DIRECTORY, COPY, and >NCP CLEAR SYSTEM TYPE, but for EDIT, BACKUP (save sets only), SEARCH, and >REM NETACP even ANALYZE/RMS. Similarly, most files on a VMS system >INS NETACP (except indexed prologue 2 and 3 files) can be opened by an >NCP SET SYSTEM RSX task linked to RMS and DAPRES. This can be done with a >NCP SET EXECUTOR STATE ON FORTRAN-77 task (at least under M+) by simply relinking the but this procedure grows extra steps if you've task to the RMS FORTRAN run-time system, RMS itself, and VMRed NETACP or SAVed your system with DECnet DAPRES. In addition to whatever commands you need to running. include the RMS OTS, you'll need the following in the root of your task: LB:[1,1]RMSLIB/LB:R0EXSY:R0IMPA LB:[1,1]RMSDAP/LB:R0AULS 5.3 Communicating With Odd Devices/Systems You'll also need the following options: There are, of course, a large number of systems for which DECnet is not the answer, either because the RSX RESSUP = LB:[3,54]RMSRES/SV:0 system is too heavily loaded, or because the remote system LIBR = DAPRES:RO won't support it. In this case, there are other alternatives: There is also a bug in versions of DECnet/RSX prior to M+ 3.0 B and M 4.2 B, that prevents the RSX system from * Non-DEC implementations of DECnet. accepting connections from more recent systems, either RSX or VMS. The problem was overvalidation of the connect * The DLX interface, which includes only the bottom block, and it can be fixed by ZAPping NOPs over the two layers of DECnet. offending instructions. The exact procedure is: * KERMIT, which is available for a large number of 1. Copy or back up [5,54]NETACP.TSK (JUST IN CASE!!!) systems, and from a number of sources within DECUS. 2. Dump it to a text file. * XMODEM. 3. With your favorite editor, find consecutive words * The RSX communication drivers, available for a having the following octal values: 032705, 177774, number of interfaces (but not, unfortunately, all 001xxx (where xxx doesn't really matter). Make of them). note of the block:byte number (in octal) of the location of the first of these three (eg: 14:130 * A no-protocol communication program such as DTE -- yours may differ wildly from this!) (SET HOST/DTE), PIP (COPY), TEM; some fiddling with device attributes (such as /NOECHO) may be needed. 4. Execute the following ZAP commands: > zap * Your own code. Use QIO or READ if possible for ZAP> netacp.tsk/ab efficiency rather than unsolicited input AST. _ block:byte/ ; ZAP should show you 032705 _ 240 ; NOPs the first word This grades off into the topic of custom device I/O, which Favorite RSX problems Favorite RSX problems will be taken up later. typically one per function, though some require two (eg: "Start of Job" and "Son of Start of Job"). Interestingly, the interface requires files to be identified RMS-style (by fully-qualified file spec), rather than FCS-style (by device 5.4 Miscellaneous Tweaks And Oddities. name and file ID) as generated by PIP and FORTRAN (DISPOSE='PRINT' is equivalent to DISPOSE='SAVE' under the The two remote terminal commands in general use under RMS OTS, and for good reason). PRT... gets the unenviable RSX, SET /HOST and RMT, are NOT equivalent. SET /HOST uses task of making the conversion, which it can only do by the CTERM protocol, which is DEC's standard remote terminal reading the file name out of the directory file's header. DECnet protocol, whereas RMT uses an RSX-specific protocol There's a trap here for those who rename directories. But (there are other system-specific components available though it is possible (though awkward), with the source in hand, to unsupported: RVT for VAXen, RST for RSTS). It would seem write your own program interface to the queue manager. to be the obvious move to ditch RMT in favor of the Similarly, one who wants to know what's in the queue standard, except for the pragmatic consideration that RMT, can/must open LB:[1,7]QUEUE.SYS (shared, please!) and use where applicable, is more robust. One should beware, for the information in the sources to help interpret what is example, of running ACNT over a CTERM link, as the link may found there. refuse to pass a lone escape character, making it impossible to exit ACNT. Modern ACNTs have been modified to work Perusal of the source can also point the way to some around this. useful techniques that don't require a line of code. For example, it is sometimes desirable to drain the queue for a Certain versions of the remote terminal protocols have stalled printer, rather than printing the output somewhere trouble with large data buffers (eg: screen fills) on else. Assigning a queue to the null device would seem to be input, output, or both. Symptoms can range from partial I/O the logical way to do this, but alas the Queue Manager won't up to system crashes. This can be lived with (while you're let you assign a print processor to a pseudodevice. It waiting for your SPR to be acted on) by calling GETLUN to turns out, on reading QMGASS.MAC, that you CAN create an determine your device name, and using smaller buffers if the "applications queue" to a pseudodevice, and the only thing device name is RT or HT. you lose is transparent spooling. The MCR commands for setting up such a queue are: Certain communication devices are known to occasionally drop interrupt enable. When this happens, everything comes >INS $LPP/TASK=NL0 ! Install "Print" processor to a screeching halt. When this is discovered, DECnet >QUE NL0:/CR/NM ! Create queue. generally grows a few lines of code to deal with the >QUE NL0:/SP/EX ! Initialize applications proc. problem, so the solution is to upgrade. Certain models of the DL, DZQ, and DELQA are known to have this problem, but The critical item is the "/EX" switch on the last QUE this list is far from exhaustive. command. Since LPP actually copies the output to NL0:, it takes a bit to get rid of a large file. Someone REALLY interested in performance could write their own despooler. 6 QUEUE MANAGER The queue manager is an odd and sometimes frustrating 7 FIXED IN NEXT RELEASE beast. It is reasonably functional, but it lacks a callable interface for anything more than the most rudimentary Once or twice per clinic, a problem comes in which is functions, and the documentation tends to cover only plain simply the result of a bug in RSX. There is nothing to be vanilla uses. Anything out of the ordinary drives one done in such instances but to recommend an upgrade. The straight to the source, which is in [25,10]. more notable bugs that we have come across in this context include: The source is actually pretty well commented. One finds that the interface is similar in design to the VAX * M V4.1 through about M V4.2 "C" take the RX50 interface; one creates jobs, adds files to them, and so on. controller off line when the drive door is opened, But the interface is strictly 13-word send-receive packets - making it necessary to reboot every time you want Favorite RSX problems Favorite RSX problems to use another floppy. not cover ACPs; the best advice here is to take F11ACP as your pattern, compare the M and M+ versions, and be guided * M V4.4 and earlier did not provide the NL: device by the differences. External header support is guaranteed by default during a SYSGEN. This doesn't sound to be an issue (though a minor one, and covered by the like much of a problem, until you realize that driver manual), and there may be others. SYSGEN requires NL:. You can always override SYSGEN's default; the moral is not to fall asleep Drivers come in basically two flavors: programmed- (or at the switch. character-) interrupt, and DMA (or NPR). The former is covered with complete examples (at least for those who need * Micro-RSX V3.1 doesn't recognize a DHQ-11 if the to write a paper tape driver). The latter is a more complex programming mode jumper is in DHU mode (which, job on Unibus machines, due to the need to manage the odd-sounding as it is, is where you really want mapping registers. This is covered in section 7.3 of the it). last manual I looked at (earlier ones relegated it to an appendix), but there seems to be no single strategy on when * Under M+ V4.0 and 4.1, if a non-privileged task to allocate and deallocate. The driver writer should issues the QIO function SF.SMC to a terminal other consider that RSX does basically the same thing when it runs than it's TI:, the system crashes. Other amusing out of UMRs as when it runs out of pool; that is, nothing ways to crash a system include: good. If you only want a couple, for a high-data-rate application, you may want to just grab a couple and keep - RUN TI: (about M+ 2.1) them, to avoid the overhead (small but non-zero) of continually reallocating them. The online entry point is a - PIP _/LI (about M+ 3.0) good place under M+, so you can give them back at the offline entry point. If you potentially need a bunch of UMRs, you'll probably need to obtain them on the fly. * M+ 3.0 "A" and "B" were unable to run "BAD" on an MSCP device (RCT, the reconfiguration task, would Sometimes you find yourself tinkering with DEC's get totally confused and mark the disk offline). drivers rather than writing your own. One may, for example, wish to have more than one copy of a given driver resident * M+ 3.0 "B" and M4.2 "B" and earlier won't accept simultaneously, due (for example) to unit or controller DECnet connect requests from more recent systems. restrictions. If the driver is loadable, it is simple to This was discussed earlier under networking. change the device name, though you need to beware of the fact that some of the macros have driver-name-specific code in them. If you need error logging, you'll have to edit and recompile the error logger modules. Failing that, you can rename the cloned devices back to the original device names 8 DRIVER HACKS once they're loaded, provided you were careful to avoid unit number overlap. The rename can be done at the online or RSX practically invites people to do custom I/O, and powerfail entry point, with a privileged task, or even with many take up the invitation. The "Guide to Writing an I/O OPEN. Driver is reasonably clear, and covers the main cases. The main drawback is that someone decided to remove the appendix Some older drivers come in resident versions only. on executive data structures. This appendix is still in the Loadable versions may be available from Colorado Springs "Crash Dump Analyzer" manual, so the information is not (though your mileage may vary). If you can't get it there, lost; but neither is it all together in one handy place. you should be able to "roll your own"; the hardest part is probably getting the database built the way you want it. For many, the most useful part of the manual is the appendix on converting RSX-11M drivers to RSX-11M+. The Per Bruce Mitchell, the TT: driver is "a mouse and a procedure is pretty mechanical, and not very difficult; the half"; surely it's a driver and a half, with a unique M to M+ conversion is one of the few pieces of kernel-mode customization capability called the Ancillary Control code I have done without sending the system down the tubes Driver. The legend about the invention of ACDs is that the somewhere along the line. Unfortunately, the appendix does FMS engineers came to the RSX engineers with the words "We Favorite RSX problems Favorite RSX problems have a problem." The RSX engineers answered "We noticed," 9.1 Intertask Communications and invented a method to hang a back end on the terminal driver to do custom processing. The ACD runs in kernel mode One thing nobody can accuse RSX of is a lack of (to avoid the overhead of context switching), and can do communications mechanisms. There is, in fact, an just about anything it wants to the data stream; the main embarrassment of riches. However, one of the things that restriction is that I/O requests can be neither created nor seems to be lacking is a multicast mechanism; that is, a way destroyed. ACDs written during development included a null to have several tasks service (in effect) the same ACD, a "backwards" ACD (which reversed all text on output), send/receive queue. This deficit can be remedied in a "George Orwell" ACD (to monitor the data stream on another software in at least the following ways: terminal), and a command line editor. DEC currently distributes some to do terminal keyboard mapping; character * Create a dispatcher task to forward the messages set conversion (eg: ASCII to EBCDIC) is also possible. If via the "Send, Request, and Connect" directive, used with non-terminal devices, ACDs can be used to generate keeping track of which tributary tasks are active, and interpret communication protocols, and to time stamp and either stalling or (preferably) queuing data; in the latter use, be sure you elevate CPU priority to messages internally if all tributaries are busy. BR6, so the clock doesn't update while you're copying its value. * Install the receiver as ...xxx, and have it invoke the GIN$ directive as soon as it becomes active to In some applications it may be better to connect a task change its name. You will still need to check the directly to the controller, rather than going through a queue before exiting, as another message may have driver. RSX provides the CINT$ directive to do this. This become queued before the name change. directive sets up a subroutine in the task to be mapped in kernel mode and called whenever the specified interrupt occurs. Data can be shared with the main task using a The opposite problem could be referred to as the "Data common area (that is, a data .PSECT). You'll have to put Logger Problem"; that is, the configuration where many tasks the code in the same .PSECT, or at least be REAL careful funnel messages to one task, which (among other things) logs about .PSECT naming, so that the code and data can be mapped them to disk. The problem here is that the "Receive Data or with the same APR. CINT$ can handle DMA as well as Exit" directive does just that, and performs no file cleanup programmed I/O; the same UMR allocation mechanism used by if the "Exit" function is taken. If the code closes and the drivers is available to your task. Just don't forget to reopens files for each message processed, performance will deallocate them when you're done. suffer. There are several alternatives available to boost performance. * Process messages using the "Receive Data" directive 9 TOPICS IN APPLICATION DESIGN until it returns the "No More Messages" error, and only then close the files and do "Receive Data or Application design seems often to be done these days Exit". without either consideration or proper understanding of the platform on which the application is to be implemented. * Convert to "Receive Data or Stop" and hold the This kind of thing works more or less well, depending on files open. If necessary, you can "Crash Proof" what services the application needs. In areas other than your files by doing a flush operation after the sequential file operations, the industry has done remarkably updates. The code for an F77 flush (using the FCS poorly in providing standard interfaces to similar system OTS) looks like this: features, and even were such an interface to exist (eg: the POSIX effort), the differing performance of the underlying ; CALL FFLUSH(LUN) ! FORTRAN call. system services could still be an issue. Two of the most LUN = 2 ; Offset to LUN idiosyncratic areas to be dealt with are those of intertask .IIF NDF D.FDB, D.FDB =: 14 ; FDB Offset. communication and of privilege and protection. FFLUSH:: MOV @LUN(R5),R2 ; Get LUN from FORTRAN CALL $FCHNL ; Map to FFDB address ADD #D.FDB,R0 ; Point to the REAL FDB. Favorite RSX problems Favorite RSX problems CALL .FLUSH ; Flush the file. (accepting the restriction in size), and flip the bit on and RETURN ; Done. off yourself. Kernel mode is also a must for finding out .END the characteristics of other tasks and terminals, such as their UICs. Task characteristics may be tricky, as many of them are stored in the header, which may not be resident. [14,10]THPAGE.MAC, the RMD task header display code, is a Those who want to re-use the aforementioned log file good template to follow on how to get task characteristics. should be aware that a FORTRAN REWIND does not reset the end-of-file position. There are (inevitably) several ways to do this: * PIP file/EOF:1:0 * Issue a Truncate call after the rewind. You'll need the address of the FDB (under FCS, found as above by calling $FCHNL and adding D.FDB to the result) or the RAB (under RMS, found similarly, the "magic number" to add is different). * Read the file header using an ACP QIO and reset the end-of-file position. You'll have to re-open the file to get FCS or RMS to realize what you've done. See the back of the I/O Operations Guide for more information. 9.2 Privilege And Protection It had been noted that RSX recognizes only two classes of user: God and dirt. Installed tasks can allow "dirt" to become "demigod", doing, under the control and (hopefully) restriction of the task things that would ordinarily not be possible. Unfortunately, certain operations are difficult to restrict on the task level, and premier among these is file access. A privileged task gets "system" access to all files, and if that task takes a file name as input, it becomes difficult to keep people from gaining access to files not meant for them. Communications programs (privileged so that they could manipulate terminals other than their TI:) were particularly prone to this, and the early releases of (at least) KERMIT and TEM were capable of stealing the system account file. Lacking the number of privilege bits that other systems may have, the RSX application can "make do" by turning its privilege on and off. The GIN$ directive has support for this; the usual thing to do being to turn privilege off before a file open operation, and back on when the operation is complete. Lacking GIN$, you can build the task /PR:5