.PAGE SIZE 58, 85 .NONUMBER .LEFT MARGIN 10 .RIGHT MARGIN 75 .NO FILL .NO JUSTIFY # .SKIP 5 .CENTER The RSX Multi-Tasker .SKIP .CENTER April, 1988 .SKIP .CENTER "CRASH - Continue with scratch media on LB0:" .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 Submitting Articles to the Multi-Tasker RSX-2 And That's The Way Things Are RSX-2 Announcing VMS - IAS Compatibility Mode RSX-3 Bulletin Board Notes RSX-4 DECUS Europe / Rome Q _& A RSX-5 Implementing Secure User Environments RSX-9 Timer Support for User Written Drivers RSX-11 Virtual Disk Driver Problem Fix RSX-17 .JUSTIFY .FILL .SKIP 14 .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 .CENTER Food for Thought .SKIP "One thing I have learned in a long life: that all our science, measured against reality is primitive and childlike - and yet is the most precious thing we have." .SKIP 2 .INDENT 30 - Albert Einstein .COMMENT .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT The Editor's Corner .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT .SKIP 9 .CENTER The Editor's Corner .SKIP .CENTER Bruce R. Mitchell .SKIP Well, shucks. Gosh golly gee whiz (Batman). Are we having fun yet? With the release of RSX-11M-Plus Version 4, I should hope so. This should be the "all things to all hackers" release, incorporating logical names, a fully vectored Executive, support for the GIN$ directive, ACDs, and in general so many features that it could reasonably be called "VMS-11M-Plus". Well, all things to ^&most\& hackers, at least. I still can't believe it. I thought RSTS V7 was a hog! Pretty soon ^&we'll\& need a stripped version of M-Plus to replace the application platform RSX-11M used to be. Myself, I still run M-Plus V1.0 on my 11/34. SIG curmudgeon, you know. We got some interesting stuff this month. We got a fix for virtual disk drivers in the V4 release of M-Plus. We got notes on a secure user environment using custom CLIs. We got VMS - IAS compatibility mode. We got timer support for user written device drivers. (We got to run that RMS backup ... custom database deliveries ... we got to move these ... DECnet packets ... we got to format these RM03s!) Ahem. This is a somewhat sparse issue, but still most interesting. And unusual as well; the Editor has foregone the pleasure of his monthly flame in the interest of presenting a short article on the proposed VMS - IAS compatibility field test. So why don't you read that article first? .TEST PAGE 5 .SKIP 2 .CENTER ----- Submitting Articles to the Multi-Tasker ----- Please submit machine readable media. RX01/2, RX50 and 9 channel 800/1600 BPI magtape are preferred. Almost any medium I can't read can be converted. All RSX volume formats are acceptable, but please don't send VMS Backup or ODS-2 format media. You can also submit articles through the RSX bulletin board system at (612) 777-7664. The Editor loves you if you do so. Kermit the file in and send it via MAIL to username MULTITASKER. Submissions which aren't machine readable may take longer to get into print. If you format your submission 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 thanks you for the consideration. Send your articles and other submissions to the luxurious Multi-Tasker offices: .SKIP .NO FILL .NO JUSTIFY Bruce R. Mitchell Machine Intelligence and Industrial Magic PO Box 77 Minnesota City, MN###55959 .JUSTIFY .FILL .TEST PAGE 5 .SKIP 2 .CENTER ----- And That's The Way Things Are ----- _... this month in Pool Lowbegone, where the SACK pulses are strong, the brevity of BBSY is handsome, and the number of DMA transactions is above average. .COMMENT .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT Announcing VMS - IAS Compatibility Mode .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT .TEST PAGE 15 .SKIP 4 .CENTER Announcing VMS - IAS Compatibility Mode .SKIP 2 .CENTER Bruce R. Mitchell .CENTER Machine Intellgence and Industrial Magic .SKIP Well, all you 11 hackers out there who are afraid that "everybody" feels IAS and RSX have no place in the VMS world, read on. You'll be happy to know that someone is actively doing something about it. First, some history and mutual admiration. The RSX and IAS SIGs have enjoyed the closest relationship since their separation some years back. The ^&DeVIAS Newsletter\& and ^&The Multi-Tasker\& editors, their respective SIG chairs and steering committees have the greatest respect and admiration for each other (since a big collective drunk two years ago). With such commonality of interest between these two SIGs (both party a lot and both systems run on PDP-11s) it is not surprising to find that there is much cross-fertilization between the two SIGs. A case in point is that of the new IAS SIG chair, Alan Frisbie. Alan is and has been an active and well-respected member of the RSX SIG since before the beginning. A successful, and independently wealthy, consultant to both the highest levels of Digital and the users of their equipment, his recent assumption of the IAS SIG chair office can only bode well for that SIG. We wish him the acme of success in that office, and hope that he gets his garage cleaned up real soon. Another case is that of Sharon Johnson, until recently of the RSX SIG Steering Committee and now of the VMS SIG. Having served well and discharged her position with RSX well and honorably, Sharon now moves on to a new position in the VAX Systems SIG. It is interesting to note that leadership from RSX is always ready to assume new positions. (What has this all to do with VMS - IAS compatibility mode, you ask? Read on. We're getting there. Have patience.) Alan, of course, has the best of relationships with VMS as well. He enjoys writing VMS drivers, which is good; with the impending release of VMS V5.0, he will be rewriting a lot of them. In fact, Alan is now so taken with VMS, or as we RSX hackers say, "punch-drunk; loopy as a loon", that he has recently chosen to marry into that august, respected and generally overfed organization. Literally. .SKIP 2 .CENTER - hearts and flowers, please - .SKIP Alan Frisbie, of Flying Disk Systems, and Sharon Johnson, of the University of Minnesota Division of Epidemiology, announce their intent to form a tightly coupled VMS - IAS heterogeneous cluster. .SKIP The implications of this are staggering. One can almost see the future fully debugged VMS - IAS tightly coupled cluster with lots of little RSX nodes hanging around the net. While Alan insists that no such plans are contemplated, the Editor has found that in such trial situations it is always well to be watching for unexpected new releases. The Editor sees ^&many\& such possibilities, all interesting; but chooses not to elaborate further here, having been warned several times to clean up his act. In the best traditions of both Digital and Big Blue, this announcement is made without a firm release date. The actual field test is expected to begin sometime in the fall of 1988; updates will be published as they come in. Neither party to the agreement would comment on the expected duration of the field test period, but we hope that it will be both long and fruitful for both parties involved. .COMMENT .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT Bulletin Board Notes .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT .TEST PAGE 15 .SKIP 4 .CENTER Bulletin Board Notes .SKIP The BBS is running reliably these days. As of late February, the number of users is approaching 100. RSX MAIL, Kermit, old issues of The Multi-Tasker and various other items are available. Conferencing is still unavailable but remains a high priority. A Vadic 212LC modem was installed on the system in December, replacing the previous 3451P. The system still needs hardware. Anything. The biggest needs right now are a couple 80 Mb SMD winchesters and a 2400 baud modem. But anything and everything goes, so pack up all your disused treasure and ship it off to the BBS management c/o your friendly Multi-Tasker editor at the address above. The BBS number: 1-612-SPR-PONG / 1-612-777-7664. This line is autobaud 110 - 1200 baud. To request an account, log in with account name ACCOUNT, password REQUEST. .COMMENT .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT DECUS Europe / Rome Symposium Q&A .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT .TEST PAGE 15 .SKIP 4 .CENTER RSX Question and Answer Session .CENTER DECUS Europe / Rome Symposium .CENTER September 1987 .SKIP 2 .CENTER Dr. Adrian Bottoms .CENTER XDT Computer Systems .SKIP 2 Top Ten Wish List Questions .SKIP .LM +9 .INDENT -9 1.##Q:###Will DEC provide a command line editor? .INDENT -5 A:###Only place to put it is in the terminal driver which is already too big and complex to support such an enhancement. For time being use DECUS command line editor. .SKIP .INDENT -9 2.##Q:###On-line and in place disk compression? .INDENT -5 A:###Some effort investigating problem but no plans for near future. .SKIP .INDENT -9 3.##Q:###Selective copy with BRU or PIP .INDENT -5 A:###No effort being put in, but it's a good idea. .SKIP .INDENT -9 4.##Q:###Vectored executive? .INDENT -5 A:###Already done for 11M-PLUS in V3.0. As of V4.0 most privileged utilities will also be vectored, but SAV probably never, and LOA in near future. .SKIP As of V4.0 distribution philosophy will be changed. Each version and update will consist of a complete distribution kit. Old privileged tasks should run on newer execs. .SKIP .INDENT -9 5.##Q:###Limitation on length of MCR queue to prevent pool being lost due to rubbish input from terminals etc. .INDENT -5 A:###Would like to see the problem better defined. .SKIP .INDENT -9 6.##Q:###Directory listings in alphabetic order. .INDENT -5 A:###Use SRD. Development group uses SRD too, and it is faster than PIP. .INDENT -5 Aud:#Want DEC supported utilities! .INDENT -5 A:###No plans to do it. .SKIP .INDENT -9 7.##Q:###Want BRU /DIR to be sent to a file. .INDENT -5 A:###No plans to do this soon. Use BRU in batch job and look at log file. Or use BRUDIR from RSX SIG tape. Or LOG off old M-Plus V1.0 kit. .SKIP .INDENT -9 8.##Q:###Support a general magtape file utility; VMS version of BRU?; or RSX version of BACKUP. .INDENT -5 A:###Could use ANSI magtape support or BRU under VAX-11 RSX. .INDENT -5 Aud:#ANSI does not support directories. It is not an adequate solution. .INDENT -5 A:###Would like to do it but can't see enough need. Have discussed VMS BACKUP for RSX. Won't be done for a couple of releases. .INDENT -5 Aud:#Adrian Bottoms reported he had sent a Fortran source which will read BRU tapes to Bruce Mitchell. .SKIP .INDENT -9 9.##Q:###Preserve creation date by default on PIP copies. .INDENT -5 A:###PIP can be built to do this by default. BRU already preserves creation date. .INDENT -5 Aud:#PREGEN systems have default set as no preserve. Wants it the other way around. .INDENT -5 A:###We have to maintain compatability with previous releases. .INDENT -5 Aud:#Provide a ZAP location that allows customers to change the default. .INDENT -5 A:###Could do it - prefer to use logical name. .SKIP .INDENT -9 10.#Q:###Reserve some pool space for an abort command. Allows task to be aborted when pool is low. .INDENT -5 A:###Problem somewhat removed with external headers since the pool no longer needs to be in pool to allow it to be aborted. .INDENT -5 Aud:#Problem with tasks with outstanding I/O. .INDENT -5 A:###We will NEVER NEVER NEVER support an abort of a task with outstanding I/O since there's no safe way to do it. .LM -9 .SKIP 2 Q _& A Section .SKIP .LM +9 .INDENT -9 1.##Q:###Steve Balteskonis - DEC, Germany .BREAK What is the difference between DLX and the RSX DEUNA device driver? .INDENT -5 A:###Has no direct experience of DEUNA driver. One difference is that the new DLX interface in DECnet supports both Ethernet standards. .SKIP .INDENT -9 2.##Q:###Why is there no generic DEQNA driver? .INDENT -5 A:###DECnet group had no connection with the RSX DEUNA driver. .SKIP .INDENT -9 3.##Q:###What are plans from DECnet group to support DELQA and from RSX group to support a DELQA driver. .INDENT -5 A:###DECnet will support all new devices. No answer from RSX group. .SKIP .INDENT -9 4.##Q:###Alan Frisbie, Flying Disk Systems, USA. .BREAK Since there is to be no RSX-11S-Plus will it be possible to get some M-Plus features into 11S, e.g. variable length send/receive data. .INDENT -5 A:###Official answer is no, since RSX-11M and RSX-11S are mature. .SKIP .INDENT -9 5.##Q:###Adrian Bottoms, XDT Computer Systems, U.K. .BREAK Is there a known problem writing files with fixed length 1024. byte records to ANSI magtape? .INDENT -5 A:###No known problem. Needs more information. .SKIP .INDENT -9 6.##Q:###Peter Moews - DEC, Germany .BREAK Are there any plans to remove the 498. block restriction in SAV in RSX-11M/11S? .INDENT -5 A:###No plans but there has been some talk about doing it. Does not see the need for it. .INDENT -5 Aud:#Alan Frisbie has systems with all 256Kb full of tasks and need the extended support. .INDENT -5 A:###Not planned for 4.3 but thinks they have done it for a particular customer. May consider it for a future release. .SKIP .INDENT -9 7.##Q:###Peter Korthoven - Promis, The Netherlands .BREAK On M-Plus system crash gets PC, Error code and System error codes. What are the error codes and where are they documented? .INDENT -5 A:###CDA manual. Try [61,10]BUGCHK.MAC. .SKIP .INDENT -9 8.##Q:###Jan Belgraver - Organon, The Netherlands .BREAK In update D RSX-11M V4.2 we got DTE, but it is not documented and when I built it, it did not work. There were no build files on the kit (got them from Software Support). There was also a missing library. .BREAK .INDENT -5 Aud:#The missing library is FDVLIB. .SKIP .INDENT -9 9.##Q:###Hans Hamakers - BBC Brown Boveri, The Netherlands .BREAK What is the use of the $ERSEQ data and what does it count? .INDENT -5 A:###Not certain but thinks it counts all hard- and software errors. .INDENT -5 Aud:#It counts the start/stop mode for TK50 which are ignored by ELI. .SKIP .INDENT -9 10.#Q:###Hans Hamakers - BBC Brown Bovery, The Netherlands .BREAK Problem with multibuffering and direct access files; last byte gets lost if record size and specified record size in OPEN are equal to 212 bytes. Sent SPR, but has had no response yet. .INDENT -5 A:###[No understandable answer on tape] .SKIP .INDENT -9 11.#Q:###Jan Belgraver - Organon, The Netherlands .BREAK When there is an error packet with an internal error, RPT reports an error and dumps internal data; does not know how to skip such a bad entry. .INDENT -5 A:###Send an SPR with file demonstrating problem. .SKIP .INDENT -9 12.#Q:###Jan Belgraver - Organon, The Netherlands .BREAK BRU64K - CONFIGURE shows mag tape device present but attempting to do a backup gets "DEVICE NOT IN SYSTEM" error. .INDENT -5 A:###No idea what's wrong - RSX developers try to stay away from it! Would anybody object if BRU64K was dropped? (This doesn't remove BRUSYS support). Can BRUSYS replace BRU64K? (nobody in the audience depends on BRU64K). .SKIP .INDENT -9 13.#Q:###Peter Korthoven - Promis, The Netherlands .BREAK Can a BOOT command be implemented from BRUSYS? .INDENT -5 A:###Would like to. Add it to the wish list, might be suitable candidate for release in near future. .SKIP .INDENT -9 14.#Q:###Jan Belgraver - Organon, The Netherlands .BREAK Wanted extended TTDRV QIOs. Asked for them in SYSGEN but didn't get them. Found have to answer "Y" to DECNET. Could it be changed to ask a direct question? .INDENT -5 A:###Could change it. Wants to make SYSGEN less exciting!! .SKIP .INDENT -9 15.#Q:###Peter Korthoven - Promis, The Netherlands .BREAK The build file for ICP allows a number of options to be changed; mentions maxima for many of these parameters but many can be exceeded. .INDENT -5 A:###The maxima represent what SYSGEN needs. Checks in the code that used to enforce these restrictions have been removed. Allows user to tailor ICP for their own needs but may have impact on symbol space. .SKIP .INDENT -9 16.#Q:###Jan Belgraver - Organon, The Netherlands .BREAK Provide ICPBLD.CMD to allow user to specify .ENABLE SUBSTITUTION as a default? .INDENT -5 A:###Wanted to do it but got overruled. .INDENT -5 Aud:#Provide a ZAP location. .SKIP .INDENT -9 17.#Q:###???????? .BREAK Documentation question - must cost much money to produce and check documentation. Is there any hope for better documentation? e.g. for DECnet and I/O manuals for RSX-11M/11M-PLUS. .INDENT -5 A:###Makes great effort to document well. If you see any errors PLEASE PLEASE send an SPR. Documentation for next release of RSX-11M-PLUS has been extensively reworked. Should see some improvements. DECnet programming documentation has been improved. .LM -9 .SKIP Submitted on behalf of the European RSX SIG by Jan H. Belgraver, chairman. .COMMENT .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT Implementing Secure User Environments .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT .TEST PAGE 15 .SKIP 4 .CENTER Implementing Secure User Environments .SKIP 2 .CENTER Wayne Steffen .CENTER Cap Gemini America .CENTER 134 Cedar Ave. .CENTER Stirling, NJ###07980 .SKIP To implement a secure environment on RSX-11M-PLUS, one can use captive command procedures with slaved terminals, or write a restricted user-written command language interpreter (CLI). A problem with captive command procedures is - what can the user do when the procedure bombs? The terminal is slaved and nothing can be entered from that terminal, until unslaved by a privileged user. A problem with restricted CLIs is - how to implement a command you don't want entered directly, but is part of a procedure. For example, BRU is a command executed as part of a user backup procedure after the necessary MOUNT commands are issued. If the CLI passes BRU as a valid command, the user can execute it by typing it in. This article deals with getting around the direct-entry problem so that we restrict the user, but allow command procedures to issue any commands necessary to execute the procedure, without slaving the terminal. The GCCI$ (Get Command for Command Interpreter) Exec directive can return an optional information buffer. This buffer contains the name of the parent task in four bytes starting at byte 3 for FORTRAN, or offset G.CCPT for MACRO-11 relative to the base of the buffer. If this location is zero, there is no parent task for this command. Commands entered by the user at the terminal have NO parent, but commands executed as part of a INDirect command procedure DO have a parent task. In the CLI, validation of commands should be done first to allow for procedures that call other procedures, such as a backup procedure that uses a mount procedure rather than MOUNTing directly. If the command is not a valid command defined for user entry then we check parentage. If there is no parent then display a firm but friendly message about typing illegal commands. If the parent is specified then pass the command to MCR or DCL, almost as is. Many INDirect procedures check to see which CLI is in use before issuing a command. This is done to prefix the command with "MCR " or "DCL" as needed to allow the command to work in different CLI environments. Our CLI won't be MCR or DCL, though, so the prefix MCR will probably be added by the command procedure. That is assuming the command procedure looks like this: .SKIP .LM +5 .NO FILL .NO JUSTIFY _.SETS PREFIX "" _.IF NE "MCR" .SETS PREFIX "MCR " 'PREFIX'MOU MU0:/FOR/NOS .JUSTIFY .FILL .LM -5 .SKIP Before the command is passed to MCR, the "MCR " will have to be stripped from the command, or "DCL" if the default was DCL. Some of the following example is copied from [USER]TMCLI.MAC supplied with RSX-11M-PLUS, and some is from a user-written CLI. This example has only two commands implemented, T and H. See the original source TMCLI.MAC or TMCLI.FTN to see how actual commands are implemented by a CLI. (Editor's note: In the following example, some branches may need to be replaced with alternate-sense jumps depending on the size and number of the execution setup code routines.) .NO FILL .NO JUSTIFY .SKIP 2 ; Check for legal commands T OR H # CMP _#"T, G.CCBF(R0) ; Is it a "T" command? BEQ TCMD ; If so, go process it # CMP _#"H , G.CCBF(R0) ; Is it a "H" command? BEQ HCMD ; If so, go process it # ; Not a valid direct command; see if a parent task exists # TST IBUF+G.CCPT ; Does parent task exist? BEQ ILLCMD ; If not, go error out # ; The command has a parent task, so give it to MCR as is. # MOV _#MCRNAM, R2 ; MCR... is task name MOV _#CMDBUF, R4 ; Point to command buffer MOV _#RPOI, R5 ; Point to RPOI$ dir DPB MOVB _#RP.OEX, R.POSC(R5) ; MOV _#CMDBUF+G.CCBF, R0 ; Load string addr in DPB MOVB G.CCCT(R4), R1 ; Put length in RPOI DPB # ; Except if command starts with "MCR " skip the "MCR " ; NOTE: It is assumed that R0 points at an even address! # CMP _#"MC, (R0) ; First 2 characters "MC"? BNE XQTCMD ; If not, go do it now # CMP _#"R ,2(R0) ; Second 2 chars "R "? BNE XQTCMD ; If not, go do it now # ; Yup it's got it so strip it from the line # ADD _#4, R0 ; Bump pointer past "MCR " SUB _#4, R1 ; Shorten buffer by four BR XQTCMD ; And go do the command # # ; Create TYPE command # TCMD: BR XQTCMD ; And go do the command # # ; Create HELP command # HCMD: BR XQTCMD ; And go do the command # # ; Execute pending command # XQTCMD: CALL ISSCMD BR GETCMD ; And get the next command # # ; Illegal command processing # ILLCMD: MOV _#ERR01, R0 ; Point at error message CALL ISSMSG ; Issue the message BR GETCMD ; And get the next command .JUSTIFY .FILL This is just a starting point for a specific restricted CLI, a programmer should study the DEC supplied [USER]TMCLI.MAC or .FTN routines for further information. .COMMENT .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT Timer Support for User Written Drivers .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT .TEST PAGE 15 .SKIP 4 .CENTER Timer Support for User Written Drivers .SKIP 2 .CENTER Jim Bostwick .CENTER Cargill Research .CENTER PO Box 9300 .CENTER Minneapolis, MN###55440 .SKIP While presenting a talk at the Nashville Symposium on ASTs, I made the somewhat brash remark that I had "once used Kernel ASTs to implement timer support for a driver". This remark generated a number of questions and requests for more information. The result is this article, which discusses how to get internal timer services into an RSX device driver. We'll meet kernel ASTs and bounce off a few other subjects along the way. The truth of the matter is, there's not much to putting timers in a driver, so I've thrown in more information to pad the article. A disclaimer: This is an article about device driver and RSX internals. I assume that you are familiar with the basics. In particular, you must known what SCB, UCB, and other TLAs mean. If you've never read the "Guide to Writing an I/O Driver", you may want to file this article for future reference. On the other hand, it IS written in English and really isn't all that arcane. So, if you're just interested in a peek under the hood, read on. There are two ways to get timers into your RSX driver. The first is called "device timeout". Device timeout is one of the services provided by RSX for all device drivers. It exists primarily to prevent a driver from hanging on a lost interrupt. To use device timeout, simply stuff the interval in seconds into byte offset S.CTM of the unit's SCB. Normally, you do this at I/O initiation, but you can initialize or reinitialize this location at any time. As the RSX clock interrupt service routine ticks off each second, it scans the SCBs, looking for non-zero S.CTM values. When one is found, it is decremented. If an S.CTM value reaches zero, the driver is called at it's timeout entry point. Thus, the driver regains control, and can take whatever action is necessary. Part of the QIO completion code in the executive clears the S.CTM offset, to avoid spurious timeouts. Although device timeout is useful for dealing with a hung device, this facility is not really suitable for general timing within a driver. For starters, there is only one timeout entry point, and only one timer value. This is fine for the function's intended purpose. However, for general timing, having only one timer available is a bit restrictive. A more troublesome restriction is that the time increment is fixed at 1 second, and is not synchronized with the system clock. This means that there is a -1, +0 second slop in the timeout. For a value of n, you actually get n-1 seconds, plus however many clock ticks are left in the current second. Why is it like that? S.CTM is a byte value, and 255 ticks let you time only up to about 4 seconds. Not good for a slow typist. Higher precision would cost cpu cycles during the SCB scan (once per second), plus more code in the Exec, plus 3 more words of pool for each SCB. So the answer is "it's simpler, smaller, and faster to do it this way, and it's accurate enough as it is. " A digression: Ever wonder why the terminal driver uses 10 second timeout increments? Some time back, there was a patch to TTDRV which turned the timeout parameter into second, rather than 10 second increments. We used it for a while, but fairly quickly went back to the standard driver, and rolled our own timeouts in the user program for short intervals. Why? Having TTDRV accept increments down to one second was just too tempting, and we started specifying 1 second timeout for instrument or other non-human serial links. A rash of link failures resulted, because a given QIO might time out after only 1 tick due to the inherent slop in the driver timeout code. I suspect that the RSX developers set up 10 second increments to avoid having to answer gobs of SPRs on "broken" timeout functions! Before you scream to DEC about ineffective facilities, consider that the driver timeout is an efficient mechanism of entirely satisfactory precision - ^&for it's intended purpose.\& Back to the subject at hand. The second, and much better, way to set a timer from your driver is to roll your own clock block, and insert it in the RSX clock queue. Although this sounds a bit intimidating, it is really quite simple. There is even ersatz documentation in the "RSX Guide to Writing an I/O Driver". True, there is no mention of it in the index or table of contents, or for that matter anywhere in the main text. But the necessary data structures and system subroutine (CLINS$) are included in the reference section. If you look closely, there is even an example in one of the sample drivers! You still have to go to the Executive sources to figure it all out, but you find lots of interesting things in there, which usually makes such a trip worthwhile. Using the clock queue gives you many of the same timer services that are available from user state with the MRKT$ directive. Intervals are in ticks, the precision is to -1, +0 ticks, and you can set up as many timers as you need. Not all of the MRKT$ features are available, however. In fact, you are dealing with the Executive routines which the MRKT$ directive calls for you. RSX assumes that if you are tough enough to go right to the CLINS$ routine, you don't need any hand holding. The only increment at this level is ticks, so if you want your driver to wait for 13 hours, you need to come up with a large number (of ticks) to stuff into the clock block. You also need to be sensitive to what a tick means to the system your driver is running on. There are usually 60 ticks per second, but may be 50, especially if you drink a lot of tea. If your system has SPM, there are probably 100 ticks per second. With a KW11-P as the system clock, it could be almost anything. The right number can be picked up at run time from the Executive data area. Although you can certainly build a clock queue entry which will set an event flag in a user task, a driver doesn't have the proper context for an event flag or an AST service routine. Instead, a special clock block is used which results in "AST-like" calls to the specified service routine in the driver when the timer expires. "AST-like" calls sounds like it could be related to this mysterious "Kernel AST" thingy. Right. An "AST-like" service whose action routine is in the Executive or other system state code is called a Kernel AST. The routine may not really be in the kernel, although it is mapped through the kernel APRs. It will definitely NOT be a real AST! Trapping off the system stack is reserved for REALLY significant events. But Kernel AST is a descriptive name, and has sort of a nice ring to it, so that's what they're called. That, or simply KASTs. There are several types of these creatures, all among the more obscure inhabitants in the RSX pet shop. They do the same kinds of things that "real" ASTs do in user mode: allow a process to suspend itself pending some event. Consider the following example. When a buffered read I/O completes, the issuing task may have to be checkpointed in and mapped before the driver can copy the data to the user buffers. To do this, the I/O completion code tickles the Loader to bring the task back into memory, and posts a Kernel AST. When the task is available, the AST fires, and the suspended I/O completion code finishes. Before the AST fires, the system is doing something more useful than waiting around for the Loader - perhaps executing the Loader. But I digress. We are interested in timer support, and one of the several types of clock queue entry will generate a Kernel AST. The driver posts the timer, then goes on about it's buiseness. When the timer expires, the driver is re-entered. There are several types of clock queue entry. Type 6, "Single Shot Internal System Subroutine" is the one needed. The request type identifier (6) is also defined symbolically as C.SYST. This, plus the offsets into the clock block are defined by macro CLKDF$. To set up a timer, first allocate a clock block, by calling $ALCLK. The clock block is carved out of system primary Pool (don't worry, it is not large), and its address is returned in R0. The clock block is initialized, and the timer started, by system routine $CLINS. The call to $CLINS is set up as follows: .SKIP .LM +5 .NO FILL .NO JUSTIFY R0 = Address of clock block (as returned by $ALCLK) R1 = High order of interval in ticks R2 = Low order of interval in ticks R3 = R4 = Request type (C.SYST = 6) R5 = Service routine address relocated through APR 5 .JUSTIFY .FILL .LM -5 $CLINS converts the interval to an absolute time by adding it to the system time of day clock and adjusting for midnight as necessary. It then copies the adjusted time, the other parameters, and driver (or caller) APR5 mapping into the clock block, and queues the block in the system clock queue. Note that if you are in the habit of writing very large drivers which overflow into APR 6 (TTDRV does this), then among many other headaches, you must ensure that any timer service routines are mapped via APR 5. When the timer expires, the Executive maps the driver and calls it at the specified entry point. The driver wakes up at system state, with the clock block address in R4. When the driver finishes whatever processing is necessary to handle the timer expiration, it does a RETURN, which gives control back to the Executive. Unlike user mode ASTs, there is no cleaning of the stack prior to return, and no ASTX$ call needed (or allowed!). All registers MUST be preserved by the service routine. Failure to do so usually leads to sudden activity on the system crash notification device. And that is that. Once you know how to set up the $CLINS call, putting timers into a driver is no more difficult than using MRKT$ with an AST routine in user state. However, you do have a bit more houskeeping to do. The Executive does not deallocate the clock block after the driver returns. This is actually friendly behavior, as it saves the driver the trouble of allocating a new clock block for each request. Normally, one or more clock blocks will be allocated during driver initialization, and never given back, unless you plan to unload the driver. That would leave the clock block(s) orphaned, and those chunks of Pool lost forever. By the way, I would strongly suggest NOT unloading a driver with timers posted. There's no analog to TKTN to clean up a driver. The timer WILL expire and the service routine WILL be called, whether it's there or not. If not, the consequences would be - ah - interesting. If you must unload the driver, put in a special QIO function to tell the driver to close up shop. This would wait for any pending timers to expire, and deallocate the clock blocks. Of course, it would also necessarily cause any subsequent QIOs to be rejected out of hand. This raises another potential caveat: there is no way, short of running down the clock queue yourself, to cancel a timer once it's been posted. Thus, you probably need a flag to tell the service routine "never mind". Great care must be exercised within the timer service routine. Just as with user-mode ASTs, the mainline code is completely unaware that the AST routine has come and gone. It is all too easy to do something in the AST routine which damages the driver's internal context. The driver will usually share its insanity with RSX. You know the rest. By the way, a Kernel AST provides a neat way to get a driver to do something even though NO QIO IS EVER POSTED to it! Like recursion, this is an esthetically pleasing concept with limited (though real) practical use. Its best application may be for establishing your hacker's credentials over a few brews at the local pub. Or, perhaps you have a device which simply pines away from lonliness and croaks if not tickled every so often. The way this trick works is as follows: At the online entry point, post a clock queue entry for some convenient interval. In the KAST service routine, tickle your device or whatever, then call $CLINS again to perpetuate the timer. Around and around it goes. Come to think of it, this might also be a neat way to embed truly weird code in the Executive where no one will ever find it. After all, system state is system state, no matter how you get there. Simply graft your trick code and the appropriate $CLINS calls onto some unsuspecting driver (the one running the system disk might be a good choice), and turn it loose. Just the ticket for a routine that selectively increments the saved PC of all programs running under your shop bozo's UIC. Except for BYE, of course. Amaze your friends! Befuddle your enemies! Give yourself some job security! Enough of that. I hope that I've shown how adding timer support to your drivers is not at all difficult. No more trouble in fact than putting similar support into a user task. As with most things, once you know how, it's easy. This article may also have piqued your interest in the remaining types of clock queue entries (one could surmise that there are at least 6 types), the other kinds of Kernel ASTs (there are several), or both. If so, haul out your trusty RSX listing, and have at it. And by all means, let us know what you find. .COMMENT .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT Virtual Disk Driver Problem Fix .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT .TEST PAGE 15 .SKIP 4 .CENTER Virtual Disk Driver Problem Fix .SKIP 2 .LM +5 .RM -5 Editor's note: I have no record of who submitted this. The problem exists due to use of DV.MSD in the latest release, and this is the correct fix. The same fix should be applied to all other virtual disk drivers. .LM -5 .RM +5 .SKIP After installing RSX-11M-Plus V4.0 I encountered a small problem trying to BRU to a virtual disk. This letter describes the problem and a how I solved it. I have used the virtual disk package the Spring 1983 SIG tape, UIC [370,21]. This software is Ralph Stamerjohn's original VD package for RSX-11M, modified for M-Plus by T.K. Pang and L.M. Fraser. Although their comments say this version was done for an M-Plus V2.0 field test, I have used it with V2.0 thru V3.0 Update E without the slightest problem. This venerable VD also worked with M-Plus V4.0 with one minor exception: BRU (Ident 08.16 and later) refused to use VD devices. If I mounted a VD device Files-11 or as a foreign device and tried to BRU to it, I got either of the following messages: .SKIP .INDENT 5 BRU -- *FATAL* -- Device not mounted files 11 on VD0: .INDENT 5 BRU -- *FATAL* -- Device not mounted foreign on VD0: A BRU.TSK from M-Plus V3.0 Update E running on the V4.0 system allowed access to the VD device, so the problem was with BRU itself, not the operating system. I poked around in the VD0: device data base using FCB (file control block lister) from the Fall 1983 SIG tape, UIC [300,70]. I compared the unit control block of VD0: to a UCB of a "real" disk and discovered differences in the word U.CW1 (unit characteristics word 1): .SKIP .NO FILL .NO JUSTIFY DB0: VD0: Value Description ==== ==== ===== =========== DV.DIR DV.DIR 10 File structured device DV.MSD 100 Mass storage device DV.UMD 200 User mode diagnostics supported DV.F11 DV.F11 40000 Mountable as FILES-11 device DV.MNT DV.MNT 100000 Device is mountable .JUSTIFY .FILL The decoding of the bits in U.CW1 was found in the "RSX-11M-PLUS and Micro/RSX Crash Dump Analyzer Reference Manual", page C-86 (DEC p/n AA-JS13A-TC) distributed as part of the M-Plus manual set. I used the MCR OPEn command to set the DV.MSD bit in U.CW1 for VD0: and found that BRU worked. The conclusion was that for some mysterious reason BRU now checks the DV.MSD bit. To make the fix permanent, I changed the device driver data base (VDTAB.MAC) to set the DV.MSD bit, and rebuilt the VD package. After that, everything was back to normal.