	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.
