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

[David Froble]

Stephen Hoffman wrote:
> 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.

I'm not saying how it should work.

There will be customers who just don't need the larger disks.  This 
assumes the "smaller" disks will remain available.

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

I know you have attitudes about "code cruft".

I'm going to guess that initially VSI's initial concern will be existing 
customers, and their needs.  Maybe they can reach beyond that in the future.

Now, being able to use very large disks will most likely not be a 
problem, whether they are needed, or not.  For some, it will be an 
absolute requirement.

What would be possibly a disaster would be breaking the applications of 
existing customers.

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

Yep.