Black Magic: VMR, BOO, and SAV An RSX system generation is actually a very straightforward procedure until you get to the very end. You select the features you desire, assemble some source files, and link a bunch of programs. We follow these same steps in the command files we use to build our application programs. The RSX system generation saves its "Black Magic" for the grand finale. Three programs - VMR, BOO, and SAV - takes an ordinary file, RSX11M.TSK, and turns it into a running RSX system. This is a non-trivial problem. Some of the problems resemble the question about the chicken and the egg. In order for RSX to run a task, the program must be installed. But in order install a task, INS itself must be installed. In addition, MCR must be present to pass command lines to INS, F11ACP must be active to open the task image files, and MOU must have previously mounted the disk for file I/O. These four tasks must be installed to have a RSX system which can run other programs. Finally, in order to get these four tasks into memory, you will need the granddaddy of all programs, the task loader (LDR) already installed, loaded into memory, and running. RSX-11M V1.0 solved the chicken and egg problem using brute force. The task loader was hardcoded into the executive, along with all of its data structures. The loader ran as a task, although its partition was surrounded by the RSX-11M executive. The install of INS problem was solved using a special task called INX. INX only purpose in life was to install INS into RSX11M.TSK (and also MCR, F11ACP, and MOU). The INX command line took only a filename and one switch. The /LB switch specified the starting disk block number of the task image file to be installed into RSX11M.SYS. In order for INX to work, Digital added the /LB switch to DMP to have some simple way of reporting the starting block number of a task image file. The last commands of a RSX-11M V1.0 system generation were: >DMP TI:=INS.TSK/LB >INX RSX11M/LB:n >DMP TI:=MCR.TSK/LB >INX RSX11M/LB:n >DMP TI:=F11ACP.TSK/LB >INX RSX11M/LB:n >DMP TI:=MOU.TSK/LB >INX RSX11M/LB:n >BOO RSX11M The RSX11M.SYS now met the bare minimum requirements for running other programs and finishing the system startup. VMR is the generalization of the original INX command. VMR commands are a subset of the standard MCR commands you use to run your system. The VMR commands differ from their MCR equivalents in that VMR commands are directed to the system image disk file rather than the current running system. For example, when you type SET /LOWER=TT4: to enable lower case for a terminal, MCR causes a bit to be toggled in the terminal driver data structures. The same command to VMR causes the same bit to be toggled, except the data structure is found in a disk file instead of memory. VMR operates on what is called a system image file. You create a blank system image file by using the following PIP command: >PIP RSX11M.SYS/NV/CO/BL:(n*4)+2.=RSX11M.TSK This command creates a file named RSX11M.SYS from the RSX executive task image produced by the system generation. There is almost certainly a previous version of RSX11M.SYS so the /NV switch forces the new file to be the highest version. System image files must be contigious in order to be read by the hardware bootstrap so the /CO switch is required. System image files are simply a image of what should be loaded into memory when the system is booted. The /BL switch allocates disk blocks to the file and thus determines how much memory can be initially loaded. You calculate the /BL value by taking four disk blocks for each 1KW of memory and always adding a two block overhead. A standard 124KW system image file will uses /BL:498. to create the file. Do not forget the period after the number or PIP will assume the value is in octal. RSX11M.SYS does not have to be as large as physical memory and in fact is almost always much smaller than real memory. The file just has to be large enough to hold whatever must be loaded initially into memory to get the system started. The normal value of 498 disk blocks, the RSX-11M maximum, will almost always be enough. If this value is not large enough for RSX-11M-Plus, simply make another copy of RSX11M.TSK and use a larger value. On small RSX-11M systems, you of course must not make RSX11M.SYS larger than physical memory. You do not have to name the system image file RSX11M, but you change its filename, you will also have to make a copy of RSX11M.STB with the same new filename. SYSGEN produces a command file to drive VMR. The first commands in SYSVMR.CMD set the system, library, and network UIC's and the size of primary and secondary pool. There is almost no reason to change the UIC values and unless your system is especially memory tight, there is probably no reason to decrease the supplied pool boundaries. Only very large system will need to bump the secondary pool allocation up. The first versions of VMR required you to perform a lot of octal arithmetic, especially to calculate partition boundaries. The current version makes life much simpler, although the cryptic warning message "Installed tasks or commons may no longer fit in partition" is output. The VMR command VMR> SET /MAIN=SYSPAR:*:* starts the SYSPAR partition at the next boundary and makes it as large as possible. After installing and fixing the executive commands and various system tasks, the command: VMR> SET /TOP=SYSPAR:-* shrinkwraps the SYSPAR partition around whatever code was loaded by VMR into the partition. The same sequence of commands is used to setup and load device drivers into the DRVPAR partition. The code which goes into SYSPAR are actually extensions of the RSX executive. In some cases, the code takes the form of common areas which the executive will directly reference when needed. These areas are called directive commons and are installed using the following commands. VMR> INS DIR11M/RON=YES VMR> FIX DIR11M/DIR RSX-11M has only two directive commons while RSX-11M-Plus and Micro/RSX may have up to six if you include vectored executive and disk caching. In any case, all relevant commons are loaded and permanently fixed into SYSPAR. VMR has special code to merger the directive commons into what appears as one single region. This is done simply for esthetics. The SYSVMR.CMD command file also installs and fixes four tasks into SYSPAR: the task loader (LDR), command line dispatch (MCR), task shuffler (SHF), and task termination program (TKTN). Each of these tasks provides an essential RSX executive service and therefore should be permanently fixed into memory except in those special cases of small memory systems. VMR outputs another message which can be ignored when it loads the terminal driver and reports "Loadable driver larger than 4K". As the terminal driver in its smallest form is larger than 4K, the message can be safely ignored. SYSVMR.CMD can be used "as is". However, there is one section which I recommend you edit in order to make a safer system. SYSVMR installs almost every available privileged RSX task into the GEN partition. I do not think that certain tasks should be installed because of they are infrequently used and their misuse can be destructive. Tasks in this category include BOO, INI, HOM, LOA, and UNL. The later two are included because the normal case is to permanently load all device drivers. On system which will infrequently use account logging, I also do not install SYSLOG and ACC. The rest of the SYSVMR.CMD file sets the round-robin and disk swapping parameters, sets the terminal characteristics, and displays the results. My experience shows changes in the standard round-robin and disk swapping parameter values results in no measureable performance improvement. The supplied values are adequate settings. It is useful to move the section which sets terminal characteristics to a separate file and reference the new file from SYSVMR.CMD. Terminal characteristics are the one part of SYSVMR.CMD which will change frequently. By keeping the settings in a separate file, you can use VMR to change a terminal characteristic without having to start from a new RSX11M.SYS file. One unusual problem caused by VMR is tasks which end up installed into two systems at the same time; once in the current running system and again in the new system image file. Installing a task causes system specific addresses to be written back to the task header. If these addresses differ between the current system and the new system image, a task you just installed with VMR may not be runable in the current image. You will get different addresses if your SYSVMR.CMD file changes the order or number of partitions or which device drivers are loaded. One simple way to avoid the problem is to use the following commands to rename all tasks in [1,54] to version 1 and then make a second copy of the tasks. VMR will install version 2 copy while the current system will use verison 1. When the new system is running, [1,54] may be purged again. >SET /UIC=[1,54] >PIP LB:*.TSK/PU >PIP LB:*.TSK;1/RE=LB:*.TSK;* >PIP LB:*.TSK;2=LB:*.TSK;1 In summary, VMR is nothing more than a version of MCR which read and writes to a disk file instead of memory. There is very little to change in the SYSCMR.CMD file which is produced by RSX system generation other than removing some unneeded task installs and splitting out the section which sets terminal characteristics. You can ignore any messages you get from VMR unless the word FATAL is used. Once you have constructed your RSX11M.SYS file, you need to start it using the BOOT task. BOOT probably has the simpliest command line of all MCR tasks: >BOO [filespec] You simply name the file to boot and if you forget, BOOT will use the file LB:[uic]RSX11M.SYS where [uic] is your current UIC. BOOT find the file on the disk and does a few simple validity checks to make sure this is a system image file. If so, BOOT takes control of the system and proceeds to load the new image into memory. It outputs no warning message to other users and makes no attempt to shutdown active programs and close open files. This is your responsibility before using BOOT. BOOT cannot read the file using standard disk I/O because it would be reading on top of the executive itself. Instead BOOT moves a special 0.5KW bootstrap to the top of physical memory. BOOT is built with a set of special device drivers for the various disks which RSX supports. It picks the device driver it needs to read in the system image file and puts it inside the special bootstrap. This process is why you sometimes cannot boot a very large system from a smaller system. For instance, consider what happens when you upgrade a PDP-11/34 system to a PDP-11/44 with 512KW of memory. The BOOT for the PDP-11/34 system still thinks there is only 124KW of memory and thus copies its bootstrap to 123.5K. If the new saved system has any code above this boundary, the newly booted system will not run properly. You might need to perform the VMR and BOOT in two phases, once to get from the PDP-11/34 to a minimum PDP-11/44 configuration and another to complete the process. When you boot RSX11M.SYS for the very first time, you do not get the standard system startup procedure. RSX11M.SYS, like all tasks, has either a normal starting address or the address of a debugging aid. If the Executive Debugging Tool (XDT) was generated into the system, XDT will prompt for input. Type a @@G@@@ causes XDT to continue and return control to RSX-11M or RSX-11M-Plus. The normal starting address of RSX11M.SYS is in a special executive module named INITL. This code starts the RSX operating system for the very first time. When INITL is finished, it turns itself into free hole in system pool. A newly booted system is somewhat like a brand new baby. INITL puts out a short message and starts MCR up to wait for the first command line. While the basic system installed by VMR is available, most of the real features of RSX must still be turned on. Usually, the only command you issue to a newly booted system is @@SAV /WB@@@. SAVE is a two-part program. The first part of the SAVE command copies memory back to the system file from which it was booted and writes a new disk bootstrap which will read the saved image. Note, the image written to disk includes SAVE itself. When the system image is booted using either the hardware bootstrap or the BOOT command, the second part of SAVE takes control and brings the system up. The INITL code from the initial boot of RSX11M.SYS cannot be used because it has been converted to pool. Also, SAVE does a much more comprehensive system startup. The definitive article on SAVE was published by in the October 1982 issue of the Multi-Tasker. "An Exposition on SAV in RSX-11M-Plus V2.0" was written by Paul Bezeredi of Digital Equipment Corporation. Paul lists the 42 steps SAVE follows writing the system to disk and 32 steps SAVE uses to bring the system up. When the system is rebooted, SAVE selectes the system clock depending on whether a programmable clock is available or not, extends the last partition (usually GEN) to the end of physical memory, sets the boot device public, sets the console terminal as a logged-in, privilege terminal, outputs a system identification message, redirects the pseudo devices to the boot device, mounts the boot disk, and starts processing of LB:[1,2]STARTUP.CMD. This last file finishes the startup process with any site specific initialization which is required. One final note about BOOT and SAVE. An unsaved system cannot be copied to another disk while a saved system can. This is because the executive references the file images of installed tasks by physical disk address (logical block numbers). Unless you are making an exact image copy of a disk, the file images will not be at the same place. SAVE fixes this problem. Before the system is written to disk, SAVE changes the logical block number to the file identification of the task file. File-id's are usually preserved when disks are copied so SAVE can convert back to the new logical block numbers when the system is booted. This is why there is a flurry of disk I/O when the system first comes up. Also, the BRU message reporting file-id's will not be preserved means disk is no longer bootable if you are making a copy of a system disk.