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

[Stephen Hoffman]

On 2021-05-26 08:40:50 +0000, arca... at gmail.com said:

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

If this is a production project, stop looking for other issues, ~mirror 
the existing hardware environment for the existing code, and get the 
source code ported to Linux, BSD, Windows, or OpenVMS V8.4+; with 
wherever you're going with this app or this data.

As for your testing assumptions, ~nobody back then was looking for 
these sorts of issues, as you're off in what was then unavailable or 
unsupported territories, and—more problematically—you're also working 
with a veritable dearth of patches installed.

There have been a number of retro-computing folks posting around here 
that wanted "the experience", of course. Many have subsequently gotten 
clobbered by their more modern assumptions, and/or by the lack of 
patches, and/or by emulator or flaky hardware bugs.

This isn't new. OpenVMS has serious gaps now—not the least of which is 
the now-less-than-theoretical though rather-better-tested 2 TiB 
addressing limit, and a file system itself designed for hard disk 
drives—and which will be even more striking given the benefit of ten or 
twenty years' hindsight, and hardware and software advances. I'm 
loading now-small 10 TB HDD spindles into NAS arrays.  One of these 
HDDs is as much or more than many VAX configurations had in aggregate. 
A shelf of these now-small HDDs is more array storage than many 
production AlphaServer configurations featured. With your data-access 
project, you're back nearly a quarter century. That's a long time in 
the IT business.

If this is a hobbyist data-recovery project, have at. I'd still 
recommend Alpha or Alpha emulation here (reports here that AXPbox works 
reasonably well, IDE bugs aside), as Alpha has the advantage of a 
couple of decades of updates that your OpenVMS VAX configuration lacks.

And here, I'd wonder if this is a TCP/IP Services bug. TCP/IP Services 
prior to V5 (UCX$) wasn't entirely stable, and V5 (TCPIP$) and later 
has had and has its issues. DEC sought OSI, and OpenVMS IP support 
never recovered.


-- 
Pure Personal Opinion | HoffmanLabs LLC