Short Notes ----- ----- One of the RSX sessions held at the DECUS symposium last month in San Francisco was the @@@System Programming Short Notes@@ session. This is the serious half of what use to be the RSX Magic session. Short Notes is a free format time period for anyone to brag about new RSX tricks or techniques they have discovered. I was not in San Francisco, but if I had been, I probably would have talked about the following subjects. JOB.CMD ------- I use command files to handle all the routine chores on my system. There are also command files to assemble, compile, and link the various software products my company markets. When we converted our system to RSX-11M-Plus two years ago, we started to take advantage of the Batch Processor to run command files. Batch jobs free up terminals and more important, produce a log file which shows every step executed and resulting error messages. I no longer have to keep the ring finger on my left hand hovering over the VT220 hold screen key. Unfortunately, the RSX-11M-Plus Batch Processor has one serious shortcoming. Unlike VAX/VMS, RSX-11M-Plus indirect command files cannot be submitted as batch jobs. The Batch Processor requires each command line begin with a dollar sign ($) and a $JOB card at the beginning of the file to log the batch job into the appropriate account. For a long time, each command file I use regularly had its corresponding batch control file. For instance, the command file ASMREQ.CMD assembles either the RSX-11M or RSX-11M-Plus version of the program REQ. The batch control file BLDREQ.CMD executes ASMREQ.CMD for both versions: $JOB BLDREQ [7,114] $@LOGIN.CMD $SET /DEF=DL1:[304,10] $@ASMREQ MPL $@ASMREQ 11M $EOJ As you can see, BLDREQ.CMD simply sets up the proper system disk and UIC and starts the command files. This same sequence of instructions is repeated over and over again in other batch control files. After writing the 53rd iteration of BLDREQ.CMD, it finally occured to me to write a indirect command file which would generate the appropriate batch control file on the fly and submit the job to the Batch Processor. The resulting command file, JOB.CMD, is shown in figure 1. If I want to submit ASMREQ.CMD as a command file and build the RSX-11M version, I would type (assuming my current system disk and directory is SY:[304,10]): >@LB:[1,2]JOB ASMREQ 11M JOB.CMD creates a batch control file which will execute the indirect command file using the same default directory and CLI as the issuing terminal. The command file first sets symbol @@@dcl@@ true if you are using DCL and false otherwise. The next step saves the current default disk and directory in variables @@@olddev@@ and @@@olduic@@. JOB.CMD then parses logical name @@@SYS$LOGIN@@ to set @@@logdev@@ and @@@loguic@@ to the login device and account. The last setup step is to parse the command file name in @@@p1@@ to see if an extension was specified and append ".CMD" if not. JOB.CMD then checks to make sure the command file exists and sets @@@nam@@ to the filename. JOB.CMD creates the temporary batch control file in your login account. If you have a @@@LOGIN.CMD@@ file, the batch file will execute the command with a qualifier of "BATCH" so you can perform special setup for batch environments such as skipping setting terminal parameters. The batch file then sets the default directory to match the original issuing terminal and starts the command file with whatever parameters are desired. At my site, we chose to have JOB.CMD submit the created batch file with options to not print the log file and to delete the created batch control file. You can change these to match your own preferences. JOB.CMD also assumes disks containing indirect command files are public and thus do not need to be mounted by the batch job. @LB:[LIBUIC] ------------ @JOB is now one of the most popular commands on our system. This created a second problem. We put our common command files in LB:[1,2] and users were getting bored typing @LB:[1,2]filename. Was there anyway to setup a default account for command files similar to how tasks are handled in LB:[1,54] and LB:[3,54]? The answer shows that even RSX Wizards (myself) should read the manuals periodically. The last paragraph in section 2.2 in the new Indirect Command Processor manual tells how to task build Indirect to search an alternate directory if the command file is not found in the current directory. Indirect uses the global symbol D$CUIC to specify alternate directories. You set D$CUIC to the octal equivalent of the directory number. For instance, [1,2] is specified by 000401. If D$CUIC is zero, no alternate directory search takes place. The default D$CUIC value of 1 causes a search of LB:[LIBUIC]. This value is normally LB:[3,54]. So we only needed to move our command files from [1,2] to [3,54] to get what we wanted. If you want a specific UIC, it is easy to edit the Indirect build file and change the D$CIUC value. I/O Bound vs. CPU Bound --- ----- --- --- ----- I recently assisted in the conversion of a monitoring system from RSX-11M to RSX-11M-Plus and in the process, made some interesting observations about I/O versus CPU bound systems. The heart of the monitoring application is a loop which reads hundreds of A/D samples and converts the raw data to engineering values. The loop is scheduled from the clock queue. One goal of system is to run the loop as often as possible. Under the old RSX-11M system, one pass of the monitoring loop took about 25 seconds so the programs were started with a reschedule interval of 30 seconds. We did not expect any dramatic improvement when the new RSX-11M-Plus system was brought up and were surprised when the loop processing time dropped almost in half to 14 seconds. The reschedule loop was lowered to 20 seconds. The improvement is from disk caching. This particular application is ideal for a disk cache. The RMDEMO caching display shows a 98% hit read hit rate even after the system is up for five days. The RMDEMO I/O display shows an average of 6 QIO's/second with caching enabled versus 25-30 QIO's/second when cache is turned off. You would think such number would be a reason for dancing in the streets. Quite the contrary, there was much gnashing of teeth from the operator consoles and programmer terminals. The explanation is simple. The monitoring tasks run at priorities ranging from 150 to 75 (after all, this is why the system was bought). Under the old system, enough of these tasks block waiting for disk I/O to let programs such as EDT give a fairly interactive response. But when disk caching has a 98% hit rate, there is no waiting on disk I/O. It is very unamusing to be in EDT and have a 14 second pause every 20 seconds. The system feels doggy, even though it is running faster than it ever has. By raising the priorities of various interactive user programs and EDT to appropriate levels, we get the best of both worlds. However it is best to do task builds at lunch time. Fortran Post-Mortem Dumps ------- ---- ------ ----- One of the hardest types of bugs to fix is the production program which aborts at random, infrequent intervals. All you can do is install the program with post-portem dumps enabled (INS file/PMD=YES) and wait for the problem to occur again. Unfortunately, Fortran programs do not abort. Instead, the Fortran OTS catches the synchronous system trap and outputs some standard error message. The Fortran OTS then does a normal exit. No post-mortem dump is triggered. You can get a Fortran task to abort by using the USEREX subroutine to specify the F77ABO routine shown in figure 2 as a user specific exit routine. Just before the Fortran OTS executes the normal exit to the operating system, the OTS will now call F77ABO. The routine simply turns off synchronous trap handling to prevent an endless loop and issues a breakpoint trap (BPT) instruction. The task will abort and you can get a post-mortem dump. This technique has one flaw. F77ABO will be called even when the task is exiting normally. The problem is avoided by calling USEREX again just be the task exit and change the user exit routine to F77XIT. OPEN Tricks ---- ------ The OPEN command is the RSX wizards magic wand. With it, the wizard can cure the unabortable task, the locked up system, and the frozen device. True Grand Wizards skip messing with editors, assemblers, and TKB and use OPEN for all programming chores. The OPEN command lets you examine and deposit any location in physical memory, including the I/O page. For example, my system has a DZ11 at address 160100. DZ11 line 2 (TT3:) is hooked up to a Racal-Vadic modem which we use to dial out to other systems using Kermit. We set TT3:'s permanent characteristics to slave and no echo to prevent problems when using Kermit. The modem needs the DTR signal from the DZ11 to operate but RSX only turns on DTR for remote terminals. I do not want to operate the line as a remote terminal as the SET /REMOTE command resets the terminal characteristics. Instead, I use the following OPEN command to turn DTR on for TT3:. >OPEN 17760104 17760104 /000000 1000 > The I/O page is always at the top of memory, so the 16-bit 160100 address is 17760100 in 22-bit notation. The DZ11 DTR mask bits are the high byte of the third word so depositing 1000 in 17760104 enables DTR for the second line. The various OPEN features are well-documented in section 3.34 of the MCR Operations Manual. If you have never used OPEN before, you should carefully read this section before attempting the tricks shown below. One common problem with RSX is the task which will not exit because it has outstanding I/O. Even the abort command is fruitless. You can tell if a program is in such as state by doing an ATL command. The task status should include RDN, HLT, and ABO status and the I/O (IOC) is nonzero. If you have waited a couple of minutes and there is no change, it is probably safe to assume the I/O has been lost and will never complete. I see this problem most often with new device drivers or DECnet. You can use OPEN to zero the task's I/O count and force the task exit to complete. The second field in the first line of the ATL command display is the task control block (TCB) address. If you assume an TCB address of 47124 for the problem task, the following sequence zeros the I/O count offset which is offset 3 of a TCB. >OPEN 47124/KNLD 00047124 /000000 00047126 /000767 367 > The /KNLD makes sure we open the address in system pool and not executive code. We skip over the first location and zero the I/O count by writing just the low byte of the second word. Before the task exit finishes, we have to take it out of rundown state. This is down by turning off the RDN bit (040000) in the task status word (offset 32). >OPEN 47124 32/KNLD 00047156 /040000 0 > Notice how the OPEN command will perform any caculations needed to compute an address in memory. Because OPEN and modify any memory location, its use has the potential to crash your system. On the other hand, OPEN can also fix system problems when your only other recourse is to reboot the system. Wish Book ---- ---- All RSX System Programming Short Note sessions include some blueskying about what we would like to see at a future session. My wish this year is VMS-style command line editting. Like many RSX programmers, I spend equal keyboard time on both RSX and VAX/VMS systems. I find myself constantly hitting @@@^B@@ on the RSX system to no effect.