ABSTRACT:
The VE: package is an RSX M/M+ Virtual Disk package
permitting multiple files or devices (or mixtures) to be associated
together as single virtual disks. Currently up to 8 such may be
so associated, though more can be added easily by reassembly.
The mnemonic was changed to VE: from VD: in order to permit the
old virtual disks to coexist with it. They provide greater
protection against inadvertent errors, but less capability for
free association of devices.
DESCRIPTION:
This version of VEDRV is a mod from the VDDRV on [307,100] of F81RSX
for M or M+. It incorporates changes which will allow it to link
multiple files into a single virtual disk. It assumes that the
virtual disk is 1 block longer than would be obtained from each
file, with the extra block being a pseudo block that will always
return an error on access. Thus, if you create a virtual disk and
run BAD, those blocks will be marked bad, RSX will never attempt a
QIO$ across file boundaries, and the driver is nearly as simple as
the original. At present, AVE will allow up to 8 files to be assigned
to a virtual disk (change VEPRE to increase). You must define M$VE$$
in VEPRE to enable this stuff.
The driver's name was changed to VE: so that the 2 types of virtual
disks can coexist in a system. Because there are NUMEROUS ways you can
screw up with this driver (for instance, command errors in AVE will zero
the disk size, or you can forget the order in which parts of a VE: are
assigned), it was thought that you would be best off able to use the old
VD: drivers where only single file assigns are needed. It also makes it
easier to test VE: if all blocks are on a virtual disk.)
Some minor kludges and caveats:
1. AVE will not lock the files any more and DVE won't unlock
them. I thought that keeping multiple filename blocks
in pool is too costly. Only the first is even kept and
it is not really used.
2. Checking is rather minimal and if you don't run BAD first
to add bad blocks to a badblock file, you'll screw up.
3. The driver will actually genrate a pair of bad blocks together
at boundaries, plus one at the end of the disk. BAD will
find these. Up to 8 files or devices may be associated with
each VE: unit (as presently done; re-edit VEPRE to alter
this if more are needed). If you try to assign more, the
AVE program is supposed to tell you. The message is that
the VE: unit is already assigned. (This was a 3 hour edit).
Further additions include the AVEX program, which is also off an
old DECUS tape but modified for this package. It allows you to use all or
part of physical disks for virtual ones, by logical block number, so
you can make several small disks look like one bigger one. Thus, you can
make your 2 RL01's look like an RL02 or some such thing. It is a good
idea to use the /INitialize switch on the first AVE to a virtual disk,
just in case the old size was not zeroed in the UCB of the thing. DVE
will zero the size, but if you ever bypass it, it'll be just too bad.
This AVEX is also handy for preventing wild BRUs from clobbering
your disk...as was the original. Since this version derives from one that
is OK on M or M+, it should be so again. Note the UCB (I think) gets another
4 words in V4 of M or V2 of M+. It should be clear from the manuals where.
Make that change before using on V4 or V2 or your system'll crash!
Because of the ease with which one can forget the names of files
or disks which are assigned, I recommend STRONGLY that you ALWAYS DRIVE
AVE or AVEX from COMMAND FILES (i.e., using indirect MCR). This will give
you a way to trace what you have.
Glenn Everhart
Further Note:
This package can be built for various systems by the command file
VEGEN. It allows VE: to be set up for single file use or the multifile
use described above, and configured for the old versions of M or M+
(V3.2 or V1), or for M V4 or M+ V2. The thing is tested in M+ V2 but not
in M V4 since I don't have an RSX11M V4 system handy. However, it looks
like it'll be OK for M V4.
There are some extra versions of AVE, DVE, and AVEX with longer
filenames as well as the ones VEGEN uses. They attempt to support the
new M+ V2 functionality of external headers by the DEC-suggested
code changes. However they are NOT tested; try at your own risk. VEGEN
will built the normal ones with no external header; they work but take
a bit of pool for the headers. This may not be a problem however, if
you use CCL to install-run-remove AVE and DVE rather than leaving them
installed permanently.
Glenn Everhart