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

[David Froble]

Stephen Hoffman wrote:
> On 2015-01-14 19:54:45 +0000, kenneth.randell at verizon.net said:
> 
>> Try a DVI$_MAXBLOCK on a drive over 1.0 TB capacity and you get a 
>> negative number.  DVI$_FREEBLOCKS has the same issue.
> 
> FWIW, whatever programming language you're working with here (DCL?) is 
> apparently defaulting to a 32-bit, signed longword, integer representation.
> 
> sys$getdvi[w] is returning an unsigned longword value, as that's the 
> only way to fit a 2 TiB block value via a longword.
> 
> The DCL environment just doesn't implement unsigned integer values.  Nor 
> does DCL offer floating point values, quadword signed or unsigned 
> integers, nor extended-precision math, nor arrays and dictionaries and 
> data structures, definitely no objects, command line completion, 
> immutable data, UTF-8 character encoding, regular expressions, nor 
> user-written lexical functions or any other forms of extensions, or 
> other increasingly-expected constructs.   And yes, there are some 
> hack-arounds available for some of these.  But integers?  Those are 
> signed values.
> 
> Part of the delay involved in extending the supported volume sizes to 2 
> TiB was due to the need to ensure that existing OpenVMS system code 
> always treated the disk size values as unsigned integers.  Prior to that 
> work, the OpenVMS code had never been supported past 1 TiB, and was 
> expected to have some "wrinkles".

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.