VEDRV (Modified VDDRV) 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