V D D R I V E R VDDRIVER.MAR and ADVD.MAR (and ADVD.CLD) form a simple virtual disk system for VMS. The basic use is: 1. Use @ADVD and @VDDRIVER to build the components and load VDDRIVER as suggested in VDDRIVER.COM, setting MAXUNITS to whatever number is desired. 2. For each VDn: unit you want to use: SET COMMAND ADVD Create a CONTIGUOUS file of the desired size. Note that the file size will be truncated to a multiple of 64 blocks for use purposes as the driver's "physical" structure is some number of 64-sector tracks, one track per cylinder. Give a command of the form ADVD/ASSIGN VDn: dev:file where VDn: is the VD unit you're assigning to, and dev:file is the container file to use. Note that the dev: part will generally be REQUIRED. Now you can use VDn: just like a "Real" disk. When done (and VDn: is dismounted), the command ADVD/DEASSIGN VDn: will get rid of the assignment so you can associate a different file with the VDn: unit if desired. You still have to INITialize VDn: units if you want to use them as file structured; they act like formatted but un-initialized removable disks otherwise. Why bother? VD: units can be handy for a variety of reasons, including: 1. Multiple cluster factors; you don't have to dedicate a whole pack to a cluster factor just to avoid waste or inefficiency where some group needs an extreme one. 2. Identifiers by volume (for security) can be used for VD: units to increase the number of security domains available without buying lots of new packs. 3. File structures other than ODS-2 can be EASILY handled. Examples include unix, ODS-1 (RSX), RSTS, RT11, ... You don't have to dedicate a whole RA81 to make a volume that contains a 1000 block Ultrix structure... 4. Volume protections, in addition to file protections, can be varied... 5. When loading large tapes from other sites (how 'bout SIG tapes, folks...), you may find it a pain to delete thousands of files from the new directory trees you created when you need the space. Well, use a virtual disk! Copy the tape to a VD: unit that holds it. Now when you're done, just dismount and deassign the virtual disk, erase ONE contiguous file, and you're done. Or just re-INIT the "pack" if you prefer. What could be easier? 6. Extensions like those in the VE: driver in RSX11M/M+ could add extra security features to protect data even against those with privileges like READALL or BYPASS. These are left as exercises for the reader... (ha ha. Seriously, I hope someone will do a few of them though.) Other extensions could be used to logically join several small disks into a bigger one at the driver level (with invented bad blocks between the physical storage areas) or do other semi-weird tricks. 7. Multiple drives can make it harder to browse around a system than one single target drive, or if you want, they can provide a class of devices where browsing can be permitted. (If your SHOW DEV shows VD: unit names of PUBLICTOOLS1 thru PUBLICTOOLS9, as a for instance, you might assume these VD: units are OK to look at. Handy in a big engineering community where you want to encourage folks to share their stuff.. 8. Some time back, someone asked at an Advanced Q+A how to limit his sys$scratch on a one drive system. Put it on a virtual disk! Now it can use the virtual disk, and the rest of his system disk won't get clobbered by runaway loops... I hope this gives the idea. Also I hope the tool will be usable. It is MINIMALLY tested but looks OK so be careful with it when using at this point. It has gone thru assign, INIT, MOUNT, CREA/DIR, copy both ways, DIR, dismount and deassign. I notice that after the INIT you need to ADVD/DEASSIGN and then reassign the thing. Some extra deassign and reassigns seem to be needed at times. But there is no ill effect on either your system or the virtual disk. The driver supports logical I/O and above (no physical I/O - just like the MSCP disks -) but has some physical structure declared just as a historical thing. The current ADVD forces virtual disks to be multiples of 64 blocks long due to this. The main bit of trickery here is that the FDT routines do normal disk-like operations within the VD: context for everything and the startio entry of the driver has some unusual code. This code modifies the I/O packets to send them off to the real driver for read/write operations (but no others) after calling IOC$CVTLOGPHY on the modified block number to get it to the form the "host" driver needs. The VD: code then unbusies the driver and returns to VMS. There is a special FDT entry for logical I/O that dispatches that directly to the host driver since that seems cleaner than the other entry. I suspect it is not really needed and it's there because it started that way. A couple of things: 1. The container file is NOT protected. DON'T blow it away while a VD: is active on a container file; you'll mess the file structure up on the host disk if this is done since VD: won't know the container file is gone; the blocks are still there. Protect the file yourself if you have doubts! Create it with protection against deletion too. 2. If you do your ADVD from a .COM file, you'll have a record of the file-to-disk assignments. DO SO. There's no other record provided. And yes, such a thing is DARN handy at times. 3. Don't forget to back up virtual disks. They get files erased by mistake too. 4. Normally to use a VD: unit you Load VDDRIVER (if not loaded) ADVD/ASSIGN VDn: file Mount VDn: ... use VDn: ... DISM VDn: ADVD/DEASSIGN VDn: Glenn Everhart There are MANY rough edges here. The most notable is that for long transfers (over 65535 bytes), the driver doesn't make provisions and will give errors. Basically you have to be able to have the system reissue qio's and the driver perhaps should check that the bytecount will be too big and NOT set the UCB field in the I/O packet to the target driver's if so. This may or may not work. In any case, the problem is rare and the device looks OK on the basis of some testing consisting of mounting, directory listings and copying files both ways, and lots of logical I/O. The final solution to the problem may be the VMS hook that says if the PID field is a system address, that address gets control when I/O is done. Much messing around with this is possible. Too bad RSX didn't have such a hook. Another rough edge is that while you cannot ADVD/DEASSIGN a VD: unit while it's mounted, and while ADVD will refuse to do so, ADVD will not give you an error message to indicate it has so refused as currently done. This MIGHT get fixed soon. Failure of ADVD to allow you to create files may also get fixed. I have left some debug code in the driver mainly as an illustration of one way to see what's going on. It stores some numbers in the driver itself during operation. Since I wanted to debug the driver on a running VMS system (and DID so!), I just used this technique to store numbers, then looked at them with SDA to find out what was going on. I also did a LOT of desk checking the code before giving it control, which saved me from system crashes and made bringing the driver up fairly simple. I realize that the trick of storing numbers for inspection by SDA is simpleminded, but thought there may be those who wouldn't think of it right off... All and sundry are invited to improve this driver. While messy it works and I hope will do folks some good. Glenn Everhart Everhart%Arisia@RCA.COM 609 338 6022 Glitches: In setting up a virtual disk: 1. Create the desired file. Remember size gets truncated to a multiple of 64 blocks. 2. Use ADVD/ASSIGN to assign the file to a VDn: unit. 3. INIT the disk. 4. Use ADVD/DEASSIGN to deassign the VDn: unit and THEN use ADVD/ASSIGN again to reassign it. 5. Now mount the disk and use. The extra ADVD/DEASSIGN and ADVD/ASSIGN is only needed after the INIT operation. Reason is obscure but it seems a harmless effect. If you have a VDn: unit mounted, ADVD/DEASSIGN will NOT deassign the unit but won't give any error messages. Use SHOW DEV VDn: to ensure the unit has gone offline to show it really got deassigned.