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

[Michael Moroney]

cmexec at gmail.com writes:

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

I did some experiments with V8.4 and I have some facts for this discussion.

First, SDA reveals disk drives have a UCB field UCB$Q_MAXBLOCK_64
(overlain by UCB$L_MAXBLOCK), showing there has been _some_ (possibly
minimal) work towards eventual larger drive support.

Second, $GETDVI will only need minimal work.  I ran a program that does a
GETDVI request for DVI$_MAXBLOCK, but with a 20 byte return buffer and
asking for a returned byte count.  It works correctly, giving a return
bytecount of 4 and zeroing the other 16 bytes of my buffer.  It will need
to be taught to return all 8 bytes of UCB$Q_MAXBLOCK_64 and return a
bytecount of 8 (assuming the user's buffer is large enough). $GETDVI will
truncate fields when the user field isn't large enough. If the user buffer
is only 4 bytes (unsigned int), is this the correct behavior (giving an
incorrect blockcount), or should it return the maximum it can, %xFFFFFFFF.

I also created and accessed drives just under and somewhat over the 2.1TB
limit.  VMS returns a correct (unsigned) value, $ SHOW DEVICE Dxxx:
displays the correct value, and DCL's F$GETDVI returns a negative value.
The >2.1TB drive will not mount at all, returning a DEVOFFLINE error.
It shows 0 for a blocksize.

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

Not necessary.  A properly taught GETDVI will do the right thing.
Higher layers such as DCL will need more work.

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