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

[arca...@gmail.com]

On Wednesday, 26 May 2021 at 03:55:55 UTC+1, Stephen Hoffman wrote:
> You're retro-computing. For this case, you're trying more recent sizes and limits than were typical ~three architectures back. 

The system from which I'm recovering data would have had RZ29 disks (4GB) back then, so I do realise that I'm going slightly beyond the original hardware :-) But the documented limits were much higher and I would have though that they would have been tested. Naturally there were precisely zero 100GB+ drives in the days of V6 but a hacked version of LDDRIVER that did sparse allocation and claimed to be a 32GB disk would have found this pretty quickly. Assuming it's an OpenVMS issue and not a SIMH issue.

> 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.

FTP was where I hit this first. So then I FTP'd the first saveset to a smaller disk (and also having misread UNXSIGNAL as UCXSIGNAL in my head :-)) I then decided to expand the first saveset onto the 100GB drive ... it blew up in exactly the same way. So I can't blame UCX :-(


> 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.

Turns out that the savesets are all /IMAGE backups so, unless I want to see more "invalid related NAM block", I'm better off with a series of 2GB-4GB volumes anyway, at least for the targets when I expand the savesets.


Thanks


Antonio


-- 
Antonio Carlini