From: HENRY::IN%"artecon!olson%hp-sdd.UUCP%sdcsvax.ucsd.edu%sri-kl.ARPA%relay.cs.net@rca.com" 18-FEB-1987 12:13 To: hp-sdd!mod-computers-vax@sdcsvax.ucsd.edu Subj: Submission for mod-computers-vax Path: artecon!olson From: olson%artecon.artecon.UUCP%relay.cs.net@rca.com Newsgroups: mod.computers.vax Subject: Re: RAM pseudo-disk for VMS Message-ID: <360@artecon.artecon.UUCP> Date: 17 Feb 87 18:59:50 GMT References: <8702160725.AA29018@decwrl.dec.com> Reply-To: olson@artecon.UUCP (Jay J. Olson) Organization: artecon Lines: 70 I was pleasantly surprised to see the recent interest in the VAX/VMS pseudo disk device (aka RAM disk). As the author of PDDRIVER, perhaps I can lend a historical perspective and suggest some things people might want to try. In general, the observations by INFO-VAX readers have been correct. The reason the pseudo disk device driver was written was to allow standalone backup to be booted from TK50s in order to initially install VMS (there are a number of MicroVAX configurations that do not have removable disks). Since tapes are not generally considered random access devices, and since VMS requires a random access device for the system disk, the pseudo disk approach seemed to work out best. Here is a short explanation of how booting from tape works. When the 20000 bit of R5 is set on entry to SYSBOOT (or in version 4.5 or later, the special SYSGEN parameter VMSD4 is non-zero), the boot device (i.e. the TK50) is allowed to be different from the system device (i.e. the system disk when VMS is running). All the files loaded by SYSBOOT are read from the tape, then things are fixed so that it appears that PDA0: is the system disk and PDDRIVER is the device driver for the system disk. PDDRIVER uses an area in non-paged pool to simulate a disk. In normal VMS operation, the allocation of this space is done with an IO$FORMAT QIO, with P1 being the size (in blocks, I think) of the area. Assuming appropriate privileges, one can change the size of the pseudo disk's data area on the fly with another IO$FORMAT QIO. However, in the bootstrap environment, SYSBOOT preloads the data area with the image of a disk which it obtains from the file PSEUDOLOA.EXE (by the way, VMSD4 is used to specify the size of the pseudo disk's data area, just in case PSEUDOLOA.EXE spans volumes, as it might on a floppy). Thus, when standalone backup is booted, VMS thinks there is a disk available for it to page from, read files from, etc., when in fact, everything is in memory. This suggests one trick which might be useful. Astute system managers often put a standalone backup system in some alternate system root on their system disk. This is fine for backing up disks, including the system disk, but everyone learns sooner or later that you can't restore your system disk this way (since you will overwrite the currently executing image, and mess things up the next time a page fault occurs). The trick is to build the alternate system root so that it uses the pseudo disk booting technique. Just put all the files SYSBOOT loads in the alternate root, then put all the other standalone backup files in PSEUDOLOA.EXE. By looking at STABACKIT.COM this shouldn't be too hard to figure out. One note: the system root in PSEUDOLOA.EXE should be the same as that from which you are booting (typically [SYSE.]). It seems that most people are interested in the pseudo disk for use in a normal VMS environment. There are no known problems with this, but the most useful approach seems to be to put frequently referenced files there. As numerous fiche-readers have remarked, the performance of PDDRIVER may not be as good as some disks (the same is reportedly true of the null device) since it moves data one byte at a time at IPL 8, and since it eats up a large, contiguous, chunk of non-paged pool. By the way, if you crash while PDDRIVER is loaded, your data may not be lost. Since all of memory is written to the dump file, your data is in SYSDUMP.DMP. Perhaps some clever soul will write a utility to recover it. Jay Olson {hp-sdd,telesoft,esosun}!artecon!olson (work) {hp-sdd,telesoft,esosun}!artecon!gumby!jjo (home) Disclaimer: I don't work for DEC anymore (I sure miss it though), and I haven't used VMS for more than a year, so some of the details may be incorrect or may have changed.