[Info-vax] Looking for suggestions for new $GETDVI item codes

[Stephen Hoffman]

On 2015-01-15 10:13:27 +0000, David Froble said:

> Yes, I know it would be major work.  But what is the alternative for 
> those wanting to use large disks and such?

Hopefully, the disk-style interfaces are all long dead well before 
64-bit, quadword values are exceeded.  Though that likely means memory 
windows and/or larger physical address spaces will be required, or 
both.  But I digress.

As for extending the fields to a quadword, there isn't a good 
alternative.  Larger sector counts and larger sector sizes will be 
disruptive, no matter how those changes are rolled out.  Modern disk 
blocks are now 4096 bytes, and there's more than a little code around 
that assumes 512-byte blocks, and there's more than a little code that 
assumes that disk sizes will fit in longwords, which in aggregate means 
breaking that code, and quite possibly implementing something similar 
to the existing IDE/ATAPI optical disk synthetic-sector support for 
2048-byte optical-media sectors.  Or quite possibly both.

> What about a SYSGEN parameter that all such data would respect, either 
> quadwords, or longwords, based upon the parameter?

That's a system-wide setting, which means that toggling the setting and 
migrating to larger disks is an all-or-nothing undertaking; more of a 
migration.    This particular detail is much more likely to be 
conditionalized at run-time, either based on a new itemcode that allows 
8 byte buffers, or probably more likely based on seeing whether the 
existing buffer for the itemcode is 4 or 8 bytes in size.  The 
system-wide "parameter setting" with this approach being the classic 
"don't configure and connect a volume larger than 2 TiB, if your code 
really isn't ready to deal with that" mechanism.

The historical fondness for conditionalized settings and adding 
parameters and compatibility serves to build up code cruft over time, 
as well as documentation cruft, testing cruft, and a whole host of 
other issues.   Once something gets added to the operating system, the 
VMS folks were classically quite reasonably loathe to remove it, even 
when removing it would have made more sense.  The accretion that arises 
then creates longer-term and more subtle problems.  Sure, it's bad to 
break APIs and interfaces unnecessarily, but it's also bad to be 
dragging around code that is problematic, deprecated or insecure, and 
that's before any discussions of whether the particular features are of 
sufficiently broad interest to warrant further investments.  The old 
parallel-processing library PPLRTL was deprecated a decade or two ago, 
and it's still around.   For an operating system to be financially 
successful, the folks should want or need to be over onto the New 
Hotness much sooner than that...  It's better to spend more of the 
available time and effort on newer features and newer interfaces and 
newer hardware and the rest of the stuff that folks want to buy and 
upgrade to, and less on old code and old features.  To be absolutely 
clear, this doesn't mean ripping out old code just because it's old.  
It does mean ripping out old code that's been deprecated and/or 
superseded.

> Still don't have an ODS-5 disk ....

Ayup.   DEC/Compaq/HP didn't sufficiently enable and didn't encourage 
folks to upgrade VMS.  Operating system and hardware support contracts 
are nice, but encouraging folks to move off the old software and the 
old hardware has better trade-offs for the vendor and for the customer. 
 As one of the many changes in the industry since the era of Alpha and 
VAX, HP is recommending a five-year hardware replacement cycle for 
servers, for instance.  The older boxes just aren't as economical to 
run, or to maintain, as the newer ones.  Where you can replace a rack 
or two of older servers with a Moonshot box, there can be substantial 
space savings to be had through consolidation, too.

Now what VSI does here, and what they have for both shorter- and 
longer-term plans, we'll find out over time.



-- 
Pure Personal Opinion | HoffmanLabs LLC