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

[Jan-Erik Soderholm]

Johnny Billquist wrote 2012-04-01 17:47:
> On 2012-04-01 15:39, Paul Sture wrote:
>> 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
>
> Nonsense. VMS with VAX supports much larger disks than the RA92. The
> largest actual, manufactured MSCP disk (which is what RA disks are) is the
> RA73, which is 2 GB, compared to the 1.4GB of the RA92.
>
> However, MSCP disks really are not tied to any specific size based on the
> name of the disk reported by the disk itself. That is just a silly string.
> However, I suspect that simh will create files of the size of the disk, if
> you specify a disk name. That size is then reported to the system when
> queried, and that size is what is relevant.
> Note how I say "size" here, and not type. MSCP have a function to report
> the size of the disk, and that is all any OS use to figure out the size of
> the disk. And you can (even in simh) set the size to just about anything
> you care. It's in disk blocks, and each block is 512 bytes. I think it's a
> 64-bit number...
>
> However, VAXen also support SCSI, which have much larger disks than any
> MSCP disk.
>
>>>>>> 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 the size thingy I mention above.
>
>>> 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.
>
> simh have no clue about "free blocks" in the VMS point of view. It can't
> possibly do anything. It presents a disk, with a certain number of blocks,
> and that's it.
>
>> 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?
>
> It would still not be usable for simh, since this is not visible to simh,
> nor can simh deduce anything from the actual data written to the disk.
>
> But even so, I wonder what those commands really do?

IIRC, they pre-alocates a larger (then the current size needs) BITMAP.SYS
so that the volume later on can be dynamicaly reseized (made larger).

I think this is mostly used when making a shadowset lerger by replacing
each disk one-by-one with larger modells. When the last disk is
replaced the volyme can (menualy or automaticly, don't know) be
made larger to fill up the new physikal disk.

 From the 8.4 sysmn manual :
"Dynamic Volume Expansion (DVE), introduced in OpenVMS Version 7.3-2,"



>
>>> 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.
>
> Right.
>
>> 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.
>
> Still not realistic. You need to understand the file system of the
> emulator, which can be very complex to say the least.
>
>> It can be a pain in the neck expanding disks in a virtual environment.
>
> With VMS, it is a pain because there is a file inside the file system
> (mentioned by Jan-Erik as well, I saw) that actually keeps tracks of free
> and used blocks. Any time you decide to change the disk, that file needs to
> be changed as well.
>
>> 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.
>
> Right. Which is when things gets complicated. Not preallocating disk blocks
> for your virtual disk is a no-brainer in a way. You loose a little speed,
> but apart from that, it's not really a problem at all.
>
>> (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.)
>
> Right.
>
> Johnny
>