On 2021-06-01 19:08:20 +0000, arca...@gmail.com said:

> If you mean Unix style partitioning, what would you gain? You have to
> fix the size at partition time (or trust "interesting" tools to rejig
> stuff for you).

Storage partitioning is the typical solution here, and GPT partitioning
is expected by the Itanium EFI and x86-64 UEFI consoles.

--
Pure Personal Opinion | HoffmanLabs LLC

On 2021-06-01 17:45:33 +0000, Simon Clubley said:

> On 2021-06-01, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
>>
>> OpenVMS Development never prioritized the addition of partitioning
>> support. That, and this case involves a very old and under-patched and
>> buggy OpenVMS VAX version. Retro-computing almost inherently involves
>> revisiting old bugs.
>
> It would be nice to have proper partition support on VMS, with multiple
> bootable partitions as well.

Yes, it would. That was discussed before, and it'll undoubtedly be
discussed again.

The work here mostly touches the storage device drivers, SET BOOTBLOCK,
BACKUP, and a few other tools.

The common OpenVMS tools and ~all customer apps won't notice
partitioning, though.

>> More recent OpenVMS has a hideously ugly partitioning hack commonly
>> found on OpenVMS I64 and specifically for Itanium EFI support, and that
>> hack is solely intended to present what OpenVMS expects (one big
>> volume) and what EFI expects (GPT partitioning) and without allowing
>> partition-aware tools to easily corrupt the OpenVMS one-big-volume view
>> of the storage. Silent console-triggered corruptions were once
>> possible here with older EFI firmware too, when the expectations of the
>> firmware and of OpenVMS diverged.
>
> I wonder if we are heading towards a modern version of the various
> WRITEBOOT issues and "fun" that sometimes happened in the old days...
> :-)

There are always issues in this area. VSI is using a "creative" scheme
in support of booting and crashing on x86-64, too.

There's a separate and unchanging OpenVMS installation being kept
around particularly for assistance when crashing on x86-64.

Coincidentally, the same developer that created the ugly partitioning
hack for OpenVMS I64 re-wrote WRITEBOOT for V8.0, too.

SET BOOTBLOCK / sys$setboot as a foreign command or when RUN / and the
sys$setbootshr API.

SET BOOTBLOCK was intended to be necessary only for Itanium, but works
correctly with Alpha and VAX boot devices.

The tool can also correctly "sniff" and detect a bootable VAX, Alpha,
or Itanium storage device, among other features.

BACKUP calls into sys$setbootshr for various processing.

SET BOOTBLOCK necessarily knows all about the ugly hack for OpenVMS I64
and EFI, too.

--
Pure Personal Opinion | HoffmanLabs LLC

On 2021-06-01, abrsvc <dansabrservices@yahoo.com> wrote:
> I find these discussions interesting. Why would anyone expect software written 20 or more years ago to support (without change) hardware that wasn't even a concept at the time? Saying that this may result in similar issues to the "writeboot" issues of the past seems a bit much too. Take a snapshot of the state of the software today and come back in 30 years with new hardware and see what happens. I would expect to see similar "problems".

You should read what I wrote more carefully Dan.

My WRITEBOOT comment had nothing to do with old hardware but with
future systems.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

Antonio,

the underlying problem in [MOUNT96]MOUDK2 has been fixed on 18-OCT-2000 by making sure, that VCB$B_BLOCKFACT is at least 1 to prevent the UNXSIGNAL INTDIV error in F11BXQP.

This solution is present in OpenVMS VAX V7.3 or any patch with a VMOUNT.EXE linked later than 18-OCT-2000 (e.g. VMOUN01_072).

Volker.

On Friday, 10 December 2021 at 08:03:30 UTC, Volker Halle wrote:
> the underlying problem in [MOUNT96]MOUDK2 has been fixed on 18-OCT-2000 by making sure, that VCB$B_BLOCKFACT is at least 1 to prevent the UNXSIGNAL INTDIV error in F11BXQP.
>
> This solution is present in OpenVMS VAX V7.3 or any patch with a VMOUNT.EXE linked later than 18-OCT-2000 (e.g. VMOUN01_072).

Thanks for chasing this down. I can confirm that V7.3 does not crash under these circumstances.

Antonio