Submission to Fall 1986 DECUS RSX SIG Tape Jerry Ethington Prolifix, Inc. 245 Hawkeegan Drive Frankfort KY 40601 (502)223-5489 P/OS Memory Disk Driver MDDRV is a memory disk driver for P/OS hard disk version 2.0 and later systems. A memory disk takes a chunk of your system's memory and makes it look like a normal disk drive to the system. Since it performs no seeks and transfer rates are limited only by the speed of the CPU, it is considerably faster than a Winchester disk drive. Noticeable speed improvements can be achieved by copying frequently used files or heavily overlaid programs to the memory disk and accessing them from there. There are several general things you should know about using MDDRV. First, after installing with MDLOAD, the device name for MDDRV is MD0: and it can be accessed just like any other P/OS device. Second, a memory disk needs memory to live in - the more memory you have, the bigger you can make the memory disk and the more stuff you can copy to it. With the standard 512KB of memory on a Pro, you can really only spare about 128KB at the most for a memory disk - 256 blocks. If you want to do anything serious with memory disks, you really need to add additional memory to your system either by upgrading the daughterboard memories on a 325/350 to 1MB, adding 256KB option cards, or adding 512KB daughterboards to 325/350/380 Pros. For owners of 325s and 350s, upgrading the two 128KB daughterboards to 512KB apiece, for a total of 1MB, is probably the most cost effective, followed by adding MSC-11CK 256KB option cards if you have free slots for them to live in. Every kilobyte of memory you can dedicate to the memory disk adds 2 blocks to the size of the disk. A Pro can theoretically be expanded to a maximum of 3MB, although with currently available options from DEC the limit is actually 2MB on a 380 since only 4 expansion slots are available at 256KB each, plus the standard 512KB and a 512KB daughterboard. On 325s, the limit is 1.5MB; on 350s with Winchesters, 1.75MB. Reportedly, DEC will soon have 1MB option cards available, and this will allow you to reach the full 3MB limit and devote some serious memory to memory disks or disk caching programs. If you need more information about memory expansion, write me or call - this topic could fill a small book all by itself. Lastly, the consequences of biting off more than your system can chew by specifying too large a memory disk will be a system hang where everything locks up, and you will have to reboot to try again by powering your system off and back on. Installing MDDRV Binaries To install the MDDRV package binaries, make a floppy with the package in one directory and execute the command file MDINS.CMD from either the Tool Kit or Command Language. On P/OS V3.0 and later systems, you must be logged in on a privileged account and, in the PRO/Server (read Pro/Cluster) environment, you must be local on the file server. For example, if the package is on a floppy labeled MDDRV: in directory [USERFILES], type the command "@MDDRV:[USERFILES]MDINS". The files MDDRV.TSK, MDDRV.STB, MDLOAD.TSK, and MDUNLOAD.TSK will be copied to the correct locations. On P/OS V2.0 or V2.0A systems, PROLOD.TSK will also be installed. Rebuilding MDDRV Package from sources To rebuild MDDRV, you must have installed the Pro/Tool Kit. MDDRV also requires the optional installation of files necessary for privileged program development. These files are on the PRODCL2 floppy of the P/OS distribution in the [ZZPRIVDEV] directory, and are described in the Tool Kit Release Notes. The files required are Lb:[1,5]Exemc.Mlb, Lb:[1,5]Prvlib.Olb, Lb:[1,5]Pos.Stb, and Lb:[1,5]Exelib.Olb. An indirect command file to rebuild the package is provided as MDBLD.CMD. MDLOAD and MDUNLOAD are largely prototype programs showing you how to load and unload MD. You may need to customize them to integrate them with an application. Both can be spawned from your application; MDLOAD accepts a single command line from spawn in the format "size/label", where size is the size in decimal blocks of the memory disk to create, and label is the volume label to initialize the disk with. The label may be left off, and P/OS will generate a label based on the date and time. MDUNLOAD needs no command line. Both will emit appropriate exit status to a parent program. If attached to the terminal, your application should detach before spawning MDLOAD or MDUNLOAD so they can display error messages if a problem is encountered. Running MDDRV The pair of programs MDLOAD and MDUNLOAD start up and remove the memory disk, respectively. They are installed in the appropriate directory so they can be run from the Tool Kit or Command Language by typing "RUN $MDLOAD" and "RUN $MDUNLOAD". MDLOAD will ask two questions. It will first prompt for the size of the memory disk to create - this is entered in decimal blocks. It will then ask for the volume label to initialize the memory disk with. You may just enter a return for this question, and P/OS will generate a volume name based on the date and time. If you enter a volume name, it must conform to P/OS standards, which are up to 12 characters of alphanumeric characters, beginning with a letter. MDLOAD will create a dynamic region of the correct size for the memory disk, load the MD: driver, initialize the disk with the volume label you specify, and mount the disk. At this point you can create directories on the memory disk and copy files to it. If you want to start up MDDRV every time you enter the Tool Kit or Command Language, you can edit the file APPL$DIR:START.CMD on 2.0/2.0A systems, or DCLAPPL$DIR:START.CMD on 3.0 and later systems. Add a line 'RUN $MDLOAD/COMMAND="size/label"' where size is the size in decimal blocks of the memory disk to create, and label is either the volume label to initialize the memory disk with or blank for P/OS to generate a label for it. Be sure to also edit the file APPL$DIR:EXIT.CMD on 2.0 systems, or DCLAPPL$DIR:EXIT.CMD on 3.0 systems, and add the line "RUN $MDUNLOAD" to remove the memory disk when you leave the Tool Kit or Command Language. You can shut down the memory disk by running MDUNLOAD. You should remove any tasks installed from the memory disk first, and copy any files which have been created on the memory disk that you want to keep. MDUNLOAD asks no questions; it dismounts the memory disk, unloads the driver, and deletes the dynamic region. Any files on the memory disk are destroyed. General Notes and Observations I am somewhat disappointed with the results of the memory disk myself. I wanted it primarily for improving development speed in the Tool Kit environment - faster task builds, Fortran and Pascal compiles, etc. I have a 350 with 768KB of memory, and normally use about 256KB for the memory disk resulting in a 512 block disk. I have tried many experiments with placing PAB or PF7 on the memory disk, and have rarely seen more than about a 20% performance improvement. I have finally concluded that, at least on task builds, overlaying is not the speed bottleneck; it is rather, the huge number of file lookups that PAB performs in the process of building a task image. I suspect that real performance gains might be possible if I copied all the object files going into a task image onto the memory disk, for instance Syslib, Paslib, Prof77, etc., but to hold these files will take more than the current 256KB I allocate for the memory disk. I will soon be upgrading the two daughterboard memories on my 350 so I will have 1MB on the system board and 512KB in the option cage, for a total of 1.5MB so I can use a 1MB (2048 block) memory disk, more than enough to copy the libraries and several task images onto the memory disk. I suspect this amount of memory will give very substantial performance improvements. The fortunate people with Pro 380s will probably notice a significantly greater performance improvement than 350 users, since the performance of the memory disk is limited only by processor speed and, by my benchmarks, the 380 enjoys between double and triple the CPU power of the 350. It is possible to redirect the work files used by the task builder and several compilers to the memory disk by assigning MD000: the logical name WK000:. Macro and Fortran already use WK: for their work files; in order to force PAB to use it, you can either (1) "Assign/Task:...PAB WK0: 8" or (2) use ZAP to patch PAB.TSK/AB, changing 2:34/ from 53117 to 45527, the ascii for WK. I am also studying disk caching schemes, and will probably have a working disk cache program soon, although at this point I am unsure whether I will offer it through DECUS or sell it as a commercial product. I view disk caching as a statistical memory disk; that is, the software statistically determines what should be on the memory disk at any given moment. For systems with limited memory such as my 768KB configuration, I suspect this will make considerably more efficient use of the memory. I believe that the main problem with a memory disk is that since you are statically determining what should live in memory, it requires a very large memory disk to get everything you are going to need during normal operations. A caching program can change what is in memory at any given moment and adapt to what activities are going on at any given moment - at least that is the theory. I'll be sure to write an article for the DECUS newsletter when I get the thing working and get some results.