corot@utcsstat.UUCP (07/05/83)
Ok wizards: Have any of you given any thought to getting unix and vms to share a disk (like an RA81, for example)? Has anyone actually done this? We are getting a single disk 750 soon and we thought that being able to boot vms occasionally might be nice. We may use vms' stand alone backup to save the disk and DEC might feel better about things if we verify hardware problems with vms. We would like to have unix boot blocks, a minimal vms disk and the rest of the disk belong to unix. VMS is a bit rigid about home blocks, so we thought that letting vms at the disk first might be easiest. Allocate all the spare space to a single file and then build the unix file system into that space. Any ideas about how to accomplish this? Corot Reason University of Toronto ...decvax!utzoo!utcsstat!corot
z@rocksvax.UUCP (07/08/83)
I had a setup where I shared a RP07 between UNIX and VMS. What I did was modify the VMS device driver to think the RP07 was only 500 cylinders instead of 630. The place where this happens was in DRDRIVER.EXE (see micro- fiche with your distribution). I had a little trouble figuring out the PATCH utility but eventually got it. Two locations need to be modified: the number of cylinders and the number of bytes. What you then do is put the new DRDRIVER.EXE into sys$system and reboot. This MUST be done on a disk other than the type you are modifying. We did the mods on an RM05 for our RP07. Now VMS thinks RP07's are 500 cylinders long. Now run BAD to restore the bad block info and then BACKUP a copy of your favorite VMS filesystem over it. For unix I had to modify /sys/dev/hp.c. This just was a table so it was easy. I left hp0b the same size because I didn't understand swapping code. Also /sys/stand/hp.c needs to have a table modified so boot floopy does what is right. In your case it would be a boot TU58. What you get is a VMS filesystem on which you can't use standalone utilities and which developes STRANGE problems if you run ANALYZE. It seems to be intact after running unix but I can't say for sure. The unix filesystem runs OK but seems to get corrupted when the VMS disk diagnostics are run. I suspect it has something to do with where the "extra" bad block info is located. When I say corrupted I mean FUBAR. I tried this scheme only briefly. It is better to get another disk. //Z\\ Jim Ziobro rocksvax!z or ziobro.henr@parc-maxc
drockwel%bbn-vax@sri-unix.UUCP (07/12/83)
From: Dennis Rockwell <drockwel@bbn-vax> We are about to try a variation on the same theme: we're going to attempt to put 4.1c in a large contiguous file on the VMS disk. I expect that this will prevent VMS from munging our filesystem, as it certainly shouldn't mung user's files when the diagnostics run. Now, if we can just compress the VMS disk to get a nice, big contiguous file... Anybody got any clues there?