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

[Bob Gezelter]

On Thursday, January 15, 2015 at 12:21:37 AM UTC-5, Stephen Hoffman wrote:
> On 2015-01-15 01:56:24 +0000, David Froble said:
> 
> > Maybe I'm painting with a "too broad" brush, but, today memory is cheap 
> > and plentiful.  Why not make anything that might possibly have a large 
> > value a quadword.  Yeah, lots of work up front, but perhaps not much 
> > more work to do 50-100 (or whatever) than just a few.
> 
> Sure.  Great idea.  But it's more than a little work.   For everybody.  
>   The client applications will have to be reviewed and modified to use 
> the new itemcodes, or to expect the newly- and optionally-extended 
> return fields from the existing itemcodes here.   While existing and 
> unmodified applications might not fail, the applications also won't 
> work as expected when presented with an 6 TiB disk spindle or a 32 TiB 
> RAID6 volume, or whatever other fields were extended to quadwords.  
> These existing and unmodified applications will likely either get an 
> error code they might not expect, or they'll get and process what is 
> bogus data, depending on what approach VSI might decide to do here, if 
> VSI decides to promote fields.  More than a few existing OpenVMS 
> applications haven't made it to ODS-5 support after all, so there'll be 
> more than a few that won't get updated for quadword returns...  
> Probably fodder for a major release (V9, V10, etc), given the amount of 
> effort and change and churn that would be involved here, too.
> 
> 
> -- 
> Pure Personal Opinion | HoffmanLabs LLC

David,

I second Hoff's comment, with an add-on.

Extension to quadwords is probably a good long-term goal, however care is needed. As Hoff noted, it is not just a base software issue. The impact of such a change would ricochet through customer's existing code base with side effects ranging from annoying (mis-formatted output) to catastrophic (production processes stop running).

I would advocate for an approach which is both deliberate and embracive. First, qwuadwords responses are probably the right long-term destination. However, I would take the following steps to ease the transition and preserve presently operating images (including shared middleware and emulated/translated images).

- define a datatype for "disk block count" in the user system service header files (e.g., DVI$DiskBlockCountReturn). Presently, that would equate to 32 bits, later being defined to 64 bits. This would allow savy coders to write code that compiled correctly on BOTH old and future platforms.

- adopt (and DOCUMENT) the convention that if a value is too large, the maximum value representable in the field will be returned (e.g., LONG_MAX, ULONG_MAX, ..._). Coded and compiled optimized correctly (e.g., result = (value > xxx_MAX) xxx_MAX : value) this should require at most a handful of extra instructions in the code path.

- use disjoint itemcodes for the returning of 64-bit returns, preserving the old item codes for back compatibility.

The above is probably incomplete, but it summarizes an approach which will benefit all minimizing disruption)

- Bob Gezelter, http://www.rlgsc.com