Post by Robert A. Brooks
Back in the day when I worked in VMS Engineering in Nashua, NH, I would
periodically poll the collective wisdom of comp.os.vms for suggestions regarding
new $GETDVI item codes.
OK... You asked for it...
Not really a new itemcode, but a longstanding
<http://www.openvms.compaq.com/wizard/wiz_8428.html> difference from
what DECnet did: get DVI$_TT_ACCPORNAM to identify the origin of remote
TCP/IP telnet and ssh connections via TCP/IP Services. Also something
like DVI$C_SECONDARY that will to allow me to get from the telnet or
ssh terminal device back to the BG socket device, for cases where there
are "stacked" devices. (VAXman has a tool that can help here, but it'd
be more convenient to have the base OS do the proper thing here.)
A disk native sector size itemcode: 512, 512e, 2048 (CD, DVD), 4096
(4Kn advanced 4K native); this from the optical and the IDEMA advanced
format support in various storage devices. VMS won't do much with 4Kn
native (yet?), but support for those disks are already here on other
platforms. DVI$_DEVBUFSIZ gets you want VMS sees, not what the disk
That four-byte DVI$_MAXBLOCKS field is going to need some work, sooner
or later. Might want to make it happen sooner, even if the underlying
change doesn't arrive until later.
An item code for easier scanning and detecting optical media, and
another for detecting flash media, and SSD. Also having an indicator
for virtual disk and virtual tape would be handy, particularly once
Jur's LD updates are back-integrated into VMS and with the virtual disk
and tape support added/upgraded. Similarly, some indication of whether
the disk uses FC, SCSI, iSCSI or NI hardware, and then if the storage
access protocol is MSCP or NFS or maybe (eventually?) via a CIFS client
or some other remote-access client. (e.g. DVI$_DFS_ACCESS, or maybe
rolling what could be a whole herd of _ACCESS codes into one new
mechanism rather than allowing the itemcodes to breed.) Here's a spot
where DVI$C_SECONDARY might be handy, too.
At some point in the hypothetical future of VMS, some $getdvi
infrastructures around whether the disk is encrypted will be of
interest. Maybe not for immediately reporting that (as there's not yet
anything to report here), but some way architected that MOUNT can then
leave some details around for $getdvi to report on the encryption
status, particularly when the disk is mounted with encryption enabled.
Unmounted disks would be "unknown", mounted disks (currently)
"unencrypted", and (probably eventually) specific disks will be
"encrypted" or (probably better) some indication of the type of
Being able to detect a recordable optical device, and acquiring some
details of the particular disk medium loaded in the would have been
nice, but then the need for optical is waning.
Deprecate the entirely fictional DVI$_CYLINDERS, DVI$_SECTORS,
DVI$_TRACKS, and have a look at deprecating or undocumenting whatever
other itemcodes don't make sense any more.
An itemcode that lets me know if the associated RAID hardware
underneath a controller-instantiated disk volume is somehow degraded,
and needs attention. (There's no good way to see if you're operating
with a degraded storage configuration short of walking up to the
cabinet and checking for angry fruit salad colors or rummaging the
error logs, and the error logging and reporting is, um, somewhat of a
Have somebody review the documentation for DVI$_SPECIAL_FILES. That's
the POSIX symbolic links support, right? (Because $getdvi isn't
looking at "special files" in the Unix and C sense, well, not unless
somebody was quietly planning on adding VMS devices associated with
Unix /dev and /proc stuff?) Probably the whole list of $getdvi
itemcodes should be reviewed, as some of the $getdvi documentation can
skew toward cryptic. As part of this, the following
arcana points over to the basically non-existent $getdvi documentation:
"Also, on ODS-5 volumes, a SPECIAL_FILES flag is used to communicate to
RMS operations whether to follow symbolic links or not. The RMS
operations that follow symbolic links are SYS$OPEN, SYS$CREATE,
SYS$SEARCH and all directory path interpretations.
For more information on how to set the SPECIAL_FILES flag, see HP
OpenVMS System Services Reference Manual and HP OpenVMS DCL Dictionary."
A more general comment as you're getting familiar with second-era VMS
and as you're getting rolling with third-era VMS: remember to have a
look at the UPGRADE release notes for VMS and at the release notes for
various of the layered products such as TCP/IP Services, as there was
some support and documentation added into those release notes that was
apparently never backported into the main VMS documentation. With
TCP/IP Services had this in 5.7, for instance, both with the base 5.7
release notes and with the patch kits, which added NFSv3 support. I
don't recall whether there was any $getdvi stuff in this category, but
it would not surprise me.
Of the above, the DVI$_TT_ACCPORNAM and the degraded RAID storage have
been the biggest hassles in recent years. On balance and outside of
these two areas and of the pain involved when scanning for specific
sorts of devices present in a configuration, $getdvi hasn't been a
particular problem area.
Pure Personal Opinion | HoffmanLabs LLC