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