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

[Stephen Hoffman]

On 2021-05-25 23:37:55 +0000, arca... at gmail.com said:

> I wanted a 100GB disk (using SIMH) under OpenVMS VAX V7.2.
> 
> That seems to be fine until I try to create a file. Admittedly I've 
> only tried to create a file either using FTP or BACKUP, but as they're 
> so disconnected, I assume that it's actually XQP (or something in the 
> file system) that gets upset.
> 
> I backed off my disk size and even 20GB triggers the crash. 16GB seems 
> to be OK.
> 
> Now OpenVMS beyond V5.5-2 supports single volumes of 1TB, so I'm 
> surprised that a 16GB volume causes a crash.
> 
> Does anyone have a real VAX with a real disk (> 16GB) successfully 
> hanging off it? I do have some SCA-80 36GB disks but I've never 
> successfully got them working on either a VS4000-96 or a VS4000-60, so 
> I'm not in a position to try this out myself.

You're retro-computing. For this case, you're trying more recent sizes 
and limits than were typical ~three architectures back.

Theoretical limit for ODS-2 is 2 TB and was effectively 1 TB prior to 
V8.4 due to some signed usage and that's all still ~busted in DCL to 
this day.

Driver-permitted and console-permitted addressing was less, depending 
on the hardware.

Old SCSI-2 was slightly past 8 GB up until V6.2 IIRC when IBM decided 
to use an adjacent field to allow larger capacity addressing and that 
then got standardized into SCSI-2, and PATA was limited to 24-bit on 
OpenVMS, and VAXstation 3100 consoles do stupid things with storage on 
boot devices larger than 1.073 GB.

Limits? 100 GB was ~ginormous in the era of OpenVMS VAX V7.2. SCSI was 
flaky back then too, and you're on an emulated server just to add a 
little more hardware complexity.

Somewhere back in this same V7.x range of versions, patches became 
available only to support customers, too. Wouldn't surprise me that 
you're missing a TCP/IP Services patch or three, as well as mandatory 
OpenVMS VAX patches.

I'd suggest smaller devices and contemporary capacities, or the use of 
rather newer OpenVMS versions if you want to work with OpenVMS and not 
chase older hardware limits and older bugs, depending on your 
retro-computing goals.


-- 
Pure Personal Opinion | HoffmanLabs LLC