[Info-vax] how to extract and install content from vms073lp.zip

[Paul Sture]

On Sun, 01 Apr 2012 12:41:16 +0000, Simon Clubley wrote:

> On 2012-04-01, Paul Sture <paul at sture.ch> wrote:
>> On Sat, 31 Mar 2012 18:36:28 +0000, Simon Clubley wrote:
>>
>>> On 2012-03-31, Qunying <zhu.qunying at gmail.com> wrote:
>>>> ; Define disk drive types. RA92 is largest-supported VAX drive set
>>>> rq0 ra92
>>>> set rq1 ra92
>>>> set rq2 ra92
>>>> set rq3 cdrom
>>>>
>>>> ; Attach defined drives to local files attach rq0
>>>> /home/qunying/vms/data/d0.dsk attach rq1
>>>> /home/qunying/vms/data/d1.dsk attach rq2
>>>> /home/qunying/vms/data/d2.dsk
>>>>
>>>>
>>> The only part of your host filesystem which is used is the part used
>>> to store these files and unless SimH has acquired some form of dynamic
>>> disk resizing (it's been a few years since I last used SimH so I am
>>> just covering all possibilities :-)), the size must be consistant with
>>> the emulated device.
>>> 
>>> 
>> See the section "The Variable-sized RAUSER device" at:
>>
>> http://labs.hoffmanlabs.com/node/922
>>
>> "The following creates a generic RA-series disk with 20,000 512-byte
>> block capacity:
>>
>> set -L rq0 rauser=20000
>>
>> RAUSER is specified in 512-byte disk blocks (with the -L option) (and
>> in units of mebibytes (MiB) without), and can range up to 2 gibibytes
>> (2 GiB) when simh is compiled and running with 32-bit addressing, and
>> up to one tebibyte (1 TiB) when simh is compiled and running with
>> 64-bit addressing. The backing file must be of at least sufficient
>> capacity for the specified RAUSER size."
>>
>>
> That's interesting; I didn't know about that.
> 
> That was one part of what I was thinking about above, but the other part
> I was thinking of was some form of true dynamic resizing during use
> somehow as the free blocks on the emulated device moved towards zero.

That might be useful for Alpha emulators where VMS supports the

$ SET VOLUME /SIZE=[=nnn]
$ SET VOLUME /LIMIT[=n]

commands, but would it be useful for VAX/VMS which doesn't?
 
> Given that it's a software emulation, I wasn't 100% sure that someone
> had not written some hooks into the emulator to gain access to what
> would otherwise be opaque details (such as the ODS-2 free volume space
> count) when viewed at emulator level.
 
But the guest OS also needs the ability to expand such volumes. Given 
that SimH emulates so many different hardware platforms, each of which 
could be running a variety of operating systems and file systems, this 
has the potential to become a mammoth project.

I can however see it as being useful for hardware emulators running with 
a narrowly defined set of host and guest operating systems, for example 
CHARON-VAX  or CHARON Alpha, or say VMware plus RHEL guests running a 
well defined set of file systems.

It can be a pain in the neck expanding disks in a virtual environment.

With VMware and VirtualBox for example you can create dynamic virtual 
disks which start out with a minimal allocation of real disk space and 
grow as needed, but you still need to perform some kind of manual action 
to expand a disk above the upper limit you gave it at creation time, and 
then tell the guest OS to use it.

(IIRC SimH initially creates disk container files in a similar way, and 
expands them as VMS writes to them, but if you do an INITIALIZE/ERASE for 
example, it will obviously allocate the lot there and then.)

-- 
Paul Sture