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

[cmexec at gmail.com]

On Thursday, January 15, 2015 at 9:23:55 AM UTC-5, Bob Gezelter wrote:

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


I would like VMS Engineering to consider honoring the length field of a $GETDVI request.  $GETDVI uses an item list 3, which includes a length field for the user's buffer.  My old doc set claims that if the length field is large the datum will be truncated.  I think that's a typo, and I expect if the length is too short for the datum the datum will be truncated.  If $GETDVI could honor lengths larger than 4 then a lot of existing code will just continue to run but not handle large disks, since existing code is probably using 4 and a 4 byte integer, and existing correct code at least gives the correct length for the user's buffer.  New code could supply 8, or whatever is appropriate for the user's buffer, and get larger results.  

That doesn't solve DCL's problem since it doesn't have larger integers, and it won't help running old code with large disks, but I think it's a better starting place than new item codes.

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

OK, so in addition to PAGESLETS vs. PAGES we now get BLOCKLETS vs. BLOCKS?  Works, and has precedent.  But given the workings of Files-11, maybe disk block cluster size is the correct approach, and an item code for the number of clusters should be added (DVI$_CLUSTER already returns the cluster size).


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

I very much disagree with that approach.  If VMS tells me something is FFFFFFFF blocks, I want to be able to believe it.

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

IMHO, allowing the user's code to ask for disk size in bytes, KiB, MiB, GiB, TiB, ... may also be a more flexible and workable approach with longer lasting expandability.