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

[David Froble]

Bob Gezelter wrote:
> 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).

Indeed!  Which is why I raised the "concept" of having larger data, or, 
having things work as in the past.

> 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

The problem with this entire discussion is the idea that disk block 
count is the only issue.  I submit that there can be other data that 
would also benefit from larger values.  I don't try to list any, as that 
again would be restrictive.

While I'm not going to attempt to suggest a solution, not my job, I feel 
that whoever might take a look at the issues might be able to design a 
system where the code used for one piece of data could be used for many 
pieces of data, thus getting many benefits for not much more work than 
just for disk block count.  The code for doing longwords vs quadwords 
might also lend itself to re-use.

If you're going to do something, don't do it half assed ....