DHASKIN@CLARKU.BITNET.UUCP (02/13/87)
Being the person who offered to distribute it, I suppose I should respond to: > Excuse me, but I didn't realize there was anyone out there running a Vax on > floppy disks. W H Y would anyone want a RAM disk on a Vax? ... you should > increase your cache ... If your problem is in BACKUP, try using ... If this > isn't the problem, please try and describe it more clearly, and maybe someone > on INFO-VAX can help. > ----Russ > russ@sp@ohio-state.ARPA > The Ohio State University > Department of Electrical Engineering Russ, I agree wholeheartedly. At this point I consider it only a curiosity which VAXinated types (e.g. people addicted to this VAXcine) would like to explore. While I have no doubt that there is probably a reasonable (or maybe unreasonable but at least fun) application for such a beast out there (which is what I find really neat about working in this business), I would hope that nobody is so innocent as to start putting a DBMS on it. The fact that someone at DEC took the time to implement it and that it is used in STABACKIT.COM is, I think, an indication that there is a niche for it. A colleague supplied me with the routines that I have *not* tested but when the discussion started I offered to distribute to anyone interested. To those folks who requested the routines: I'll be mailing them out tonight or during the day on the 14th. Denis W. Haskin Manager, Technical Services ------------------------------------------------------------------------ DHASKIN@CLARKU.BITNET Office of Information Systems (617)793-7193 Clark University 950 Main Street Worcester MA 01610 "Anyone who _moves_ before Most Holy comes back out will spend the rest of eternity sipping lava through an iron straw." - Cerebus
carl@CITHEX.CALTECH.EDU.UUCP (02/14/87)
>> Excuse me, but I didn't realize there was anyone out there running a Vax on >> floppy disks. W H Y would anyone want a RAM disk on a Vax? ... you >> should increase your cache ... If your problem is in BACKUP, try using ... >> If this isn't the problem, please try and describe it more clearly, and >> maybe someone on INFO-VAX can help. >> ----Russ >> russ@sp@ohio-state.ARPA >> The Ohio State University >> Department of Electrical Engineering Russ, > I agree wholeheartedly. At this point I consider it only a curiosity which > VAXinated types (e.g. people addicted to this VAXcine) would like to > explore. While I have no doubt that there is probably a reasonable (or > maybe unreasonable but at least fun) application for such a beast out there > (which is what I find really neat about working in this business), I would > hope that nobody is so innocent as to start putting a DBMS on it. > The fact that someone at DEC took the time to implement it and that it is > used in STABACKIT.COM is, I think, an indication that there is a niche for > it. > A colleague supplied me with the routines that I have *not* tested but when > the discussion started I offered to distribute to anyone interested. > To those folks who requested the routines: I'll be mailing them out > tonight or during the day on the 14th. There are a few things in VMS that are most easily implemented via the disk driver, the disk ACP, or utilities that use either of these. Among the things that need a disk to operate are VMS itself It wants to read the drivers for the devices it's going to use, the system kernal, and so forth from a disk. Sometimes when VMS is booted, it has no disk from which to read such things. One such case is a standalone utility booted from tape (e.g., for a first-time installation of VMS). In such cases, the boot code loads an image of a (generally rather small) disk from tape, and then proceeds using the RAM disk. Now, to create the disk image in the first place, the easiest way to go (assuming that you don't have a free disk of the size desired: bigger than a floppy; smaller than any hard disk you're likely to be using) is to create, format, and mount a RAM disk, build the system onto it, and then copy the RAM disk to tape (or if you prefer to have an easily accessible permanent copy of the RAM disk, copy it to a file on a real disk). If EXCHANGE were modified to be able to use FILES-11 on a virtual disk, you wouldn't need the RAM disk (anybody from DEC listening?). On the other hand, under VMS V4.x, the amount of space used by placing standalone applications on the hard disk is very small (since it uses multiple directory links to put the system directory in a subdirectory of the standalone root, instead of making copies of all the necessary files), so most of the time, you don't need to make a STANDALONE BACKUP tape anyway. However, this strategy runs into problems if your system disk becomes badly corrupted (for example, by having you run STANDALONE BAD on it). Another case in which RAM disks are quite useful is one which I experienced recently. I manage (among other things) a VAXstation II running VMS, which has a TK50 but no floppies, and a uVAX-II running Ultrix, which has both a TK50 and floppies. I got a copy of some software from someone who has a uVAX-II with floppies, but no TK50, in the form of a number of floppies worth of BACKUP savesets. I used the Ultrix machine to copy the floppies to tape files (block by block, in logical block order). I then copied the tape files to disk files on the uVAX. So now I've got umpteen images of floppy disks sitting on my hard disk. But BACKUP can't deal with virtual disks, and exchange won't deal with Files-11 structured virtual disks. So, I connect PDA0, format it to the size of a floppy, mount it /FOREIGN, spawn a BACKUP process using the RAM disk for input. When BACKUP asks for a new floppy, I copy a new disk image to the RAM disk, run a program to perform a pack acknowledge on the disk (so that BACKUP believes it's got a new floppy), and tell BACKUP to proceed. Admittedly, this procedure was cumbersome, and I later wrote a program to open the disk images, figure out the disk structure by itself, and copy the savesets to individual files on hard disk. However, the latter procedure was more time-consuming than the former, and it wouldn't have paid to write the disk-image-reading utility were it not for the fact that I expect to get software on floppies from time to time in the future.