UNIX coresident with VMS

P. D. Guthrie pdg at ihdev.UUCP
Wed Oct 16 05:08:49 AEST 1985


In article <91 at ucbjade.BERKELEY.EDU> mwm at ucbopal.UUCP (Mike (I'll be mellow when I'm dead) Meyer) writes:
>In article <522 at phri.UUCP> roy at phri.UUCP (Roy Smith) writes:
>>> >Is it possible to have UNIX and VMS coresident on the same physical disks?
>>>
>>> It should be possible to do this, provided [...] UNIX does not tamper with
>>> the VMS partitions of the disk, and that VMS does not tamper with the UNIX
>>> partitions of the disk.
>>
>>	Any dual Unix/VMS wizard (do such creatures exist?) 
>
>I've known a few people who were just sub-wizard on both, so i expect that
>they do.
>
>>want to try
>>building a disk which has both a valid Unix and a valid VMS file system *on
>>the same partition*?  To be fair, both file systems can be read only.
>
>Sorry, no can do. VMS doesn't grok "partitions." A disk is a disk is a disk,
>and you have to deal with the whole thing at once.
>

Yes, but isn't it possible to write device drivers for Vmess that use different
disk formats?  I'm sure that it must be (I don't know Vmess). You could
then get some type of device (I think SI does this) that makes one large
disk look like a bunch of smaller disks and format some unix and some
VMS.  The uVax I think requires this for the larger capacity drives.  I
also remember something about a SI controller that lets two uVaxen use
the same disk, so it might be possible to have one run VMS and one Unix,
and access each other's data through partitions (virtual disks) handled
by the controller.

>As has been pointed out here, you *can* allocate a large chunk of the disk
>as a contigous file on VMS. You then make your Unix partitions all live in
>that file.
>
>The only problem left is what to install as the boot block on the disk.
>I'm not familiar with the VMS boot sequence, so I'd be tempted to put the
>Unix boot sequence in, with a file (/vms) that you boot to bring up VMS. Of
>course, since VMS can easily get to the Unix half of the disk, it might be
>easier to do things the other way around.
>
>	<mike



More information about the Comp.unix mailing list