March 1993 Here's yet another new version of the RAMDISK driver I wrote lo these many moons ago. This version fixes a few bugs, and adds some enhancements. The most important bug fix has to do with mount verification support for VMS V5.5: DEC changed the way this behaved, with some consequences for RAMDRIVER. The basic difference is that the mount verify code will place IO$_PACKACK (among other things) IRPs directly onto the RAMDRIVER's I/O queue, which is not what it expected to find there. The result was often a system crash. This has been fixed. (Cluster transitions will put disks into mount verify these days, including ramdisks.). The most important new feature is that the RAMDRIVER no longer uses non-paged pool for its disk "blocks" - it swipes pages off of the free page list and maps them into system address space. The nice thing about this scheme is that you can give the pages back to the system as something besides non-paged pool when you're done using the RAMDRVIER. MSCP support is included in this version, though why anyone would find it useful mystifies me. The biggest problem with MSCP support turns out to be brain damage in the MSCP server -- it doesn't bother to set IRP$V_FUNC in IRP$W_FLAGS for read requests (like everything else does) -- and we were dispatching based on this flag. Also bear in mind that while access to the RAMDISK on a local machine can be multi-threaded, access via the MSCP server is single threaded. Most of the performance advantage gained by not having any rotational latency is negated by the number of data copies that go on when using MSCP to access a remote ramdisk. Note that the device name for the RAMDISK must be RDA0 if you intend to use it via MSCP. Before anyone asks, I have no idea if you can bind two of them into a shadow set or into a stripe set :-) The original text file that came with the 1988 version of this is called ORIGINAL-RAMD-BLURB.TXT. The previous new blurb file (which came with the last version) is called OLD-RAMD-BLURB.TXT. Included once again is a MAKE.COM, which will build everything, and an INITVD program to initialize the RAMDISK. You still need lots of spare SPTREQ to use this. If you attempt to initialize a RAMDISK and win an %SYSTEM-F-INSFSPTS, then you need to raise the SYSGEN parameter SPTREQ and reboot. To short circuit the inevitable deluge of questions about how to use it, build the driver (use $ @MAKE), and then use SYSGEN from an account with CMKRNL to load it: $ Run SYS$SYSTEM:SYSGEN SYSGEN> LOAD disk:[dir]RAMDRIVER SYSGEN> CONNECT RDA0/NOADAPTER/DRIVER=RAMDRIVER SYSGEN> EXIT $ Then use INITVD to expand the size of the disk to the desired number of blocks (you must have sufficient free memory on your system to support the size of the disk you want): $ Run INITVD Init-VD> RDA0 size $ Then, initialize, mount, and use it in the standard way: $ Initialize RDA0 FOOBAR $ Mount/System RDA0 FOOBAR $ Create/Directory RDA0:[TMP] etc. No, the contents of the RAMDISK are not saved across system boots (yes, people asked me this question :-). RAMDRIVER is still a spare-time project. I am grateful to TGV, Inc (my new employer) for their tolerance of my fixing RAMDRIVER, and to Ehud Gavron (gavron@aces.com) for testing it thoroughly and several helpful suggestions. This version is for VAX only; the next spare-time project is an Alpha version. This is still UNSUPPORTED code. Use it at your own risk. Enhancements and bug fixes welcome; I'll deal with bug reports as spare time allows. Please *DON'T* send bug reports or questions about RAMDRIVER to service@tgv.com; this is not a TGV product, and is not supported by TGV. Gerard K. Newman, TGV, Inc. 603 Mission St. Santa Cruz, CA 95060 gkn@tgv.com | 619.591.4717 (voice+fax) | 800.TGV.3440 | 408.427.4366