[Info-vax] Greater than approx 16GB disk leads to UNXSIGNAL crash

[Stephen Hoffman]

On 2021-06-01 16:48:44 +0000, chris said:

> The way we used to get round disk sizes for RT11, was to declare a
> set of logical drives across a single drive, which worked very well.
> I would think vms would have similar facilities...
> 
> of logical drives, which

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.

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.

Back closer to the same era as the OpenVMS VAX version that started off 
this discussion, VAXstation 3100 had 6-byte SCSI commands which limited 
volume capacity support, so some folks took to placing the boot files 
and crash files within the first ~gigabyte, which worked great right up 
until an upgrade moved a file above the address of doom, or the dump 
file got re-sized above the address of doom. Wrappage-triggered badness 
often then ensued. Some folks placed a big file at the end of the 
volume, which blocked upgrades from accessing that storage. I'd expect 
some later used that as an LD device, though LD wasn't nearly as 
commonly used back in the era when vast herds of VAXstation 3100 roamed 
the earth. Yes, I'm here ignoring VD driver, and whatever that 
pseudo-device latent in STABACKIT was named.


-- 
Pure Personal Opinion | HoffmanLabs LLC