Discussion:
Looking for suggestions for new $GETDVI item codes
(too old to reply)
Robert A. Brooks
2014-10-18 03:03:56 UTC
Permalink
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. I received many good ideas over the years, among them
the LAN_* item codes that first appeared in V8.3 (and quietly backported
to V7.3-2).

It is with more pleasure than you can imagine that I get to make that query
again as a proud member of the VMS Software, Inc engineering staff!

This time, I'm also interested in suggestions for enhancements to various
utilities, such as $ SHOW DEVICE. The likelihood of my ever
implementing any of these ideas is directly proportional to the ease of said
suggestion.

Don't forget that our releases will be for IA64 only (until we release an x86
version). I'll offer any enhancements back to HP for inclusion in the Alpha
source tree.

The caveats:

There is no guarantee that any suggestion will ever be implemented, no matter
how reasonable it is.

It's highly unlikely that any new item codes will appear in our first release
in the Spring of 2015, given that our focus is Poulson-specific for that release.

OK, go ahead -- I'm listening!
--
Robert Brooks VMS Software -- I/O Exec Group ***@vmssoftware.com
Dale Dellutri
2014-10-18 11:56:01 UTC
Permalink
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. I received many good ideas over the years, among them
the LAN_* item codes that first appeared in V8.3 (and quietly backported
to V7.3-2).
It is with more pleasure than you can imagine that I get to make that query
again as a proud member of the VMS Software, Inc engineering staff!
This time, I'm also interested in suggestions for enhancements to various
utilities, such as $ SHOW DEVICE. The likelihood of my ever
implementing any of these ideas is directly proportional to the ease of said
suggestion.
Don't forget that our releases will be for IA64 only (until we release an x86
version). I'll offer any enhancements back to HP for inclusion in the Alpha
source tree.
There is no guarantee that any suggestion will ever be implemented, no matter
how reasonable it is.
It's highly unlikely that any new item codes will appear in our first release
in the Spring of 2015, given that our focus is Poulson-specific for that release.
OK, go ahead -- I'm listening!
Two enhancements:

1. BACKUP /STATISTICS, modeled after SORT /STATISTICS. When I do
a backup, I'd like to know how much of the tape I've used to
estimate how much space is left on the tape. Right now I do
it by figuring out how many disk blocks I write:
$ inuse_before = f$getdvi(d,"MAXBLOCK") - f$getdvi(d,"FREEBLOCKS")
where d is the disk device. In some of my backup procedures,
I write multiple savesets to the same tape.

2. Allow F$GETSYI to retrieve any item which would be available
Post by Robert A. Brooks
show
auto_action RESTART
...
--
Dale Dellutri <***@panQQQix.com> (lose the Q's)
V***@SendSpamHere.ORG
2014-10-18 12:43:24 UTC
Permalink
This post might be inappropriate. Click to display it.
Stephen Hoffman
2014-10-18 13:35:21 UTC
Permalink
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
can do.

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

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

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
<http://h71000.www7.hp.com/doc/84final/5763/5763profile_021.html>
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
Craig A. Berry
2014-10-18 14:41:46 UTC
Permalink
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 quagmire.)
I think you can get the angry fruit salad colors from SMH without
leaving your desk, assuming you can hold your nose and close your eyes
to the various glaring faults of SMH. Don't know how it does it, but
maybe there's something in the SNMP giblets that are part of SMH that
could be cleaned up and made fit for general consumption.
Stephen Hoffman
2014-10-18 15:12:15 UTC
Permalink
...assuming you can hold your nose and close your eyes to the various
glaring faults of SMH....
"Glaring faults" in SMH meaning "wildly insecure", among its various
other issues. I'd expect latent and known remote code executions,
given the fixes that have gone into SMH on other platforms.

As for these sorts of tasks distributed tasks, HP seems to have gone to
Helion[1][2]. Where VSI might decide to go with their error-logging
and error-reporting strategy?

Better SNMP support would be handy but the VMS version never got to
SNMPv3 and encryption. One of may security problems latent in VMS.

Mr Brooks had specifically asked for $getdvi suggestions, so I've held
off on listing the many, many other suggestions for improvements
elsewhere in VMS. There are rather more of those other suggestions
than (I have) suggestions for $getdvi, too.



####
[1]
<http://docs.openstack.org/openstack-ops/content/logging_monitoring.html>,
<https://wiki.openstack.org/wiki/LoggingStandards>, etc.
[2] Yes, I've been saving that one.
--
Pure Personal Opinion | HoffmanLabs LLC
V***@SendSpamHere.ORG
2014-10-18 16:30:46 UTC
Permalink
This post might be inappropriate. Click to display it.
JF Mezei
2014-10-18 21:30:01 UTC
Permalink
Post by Stephen Hoffman
what DECnet did: get DVI$_TT_ACCPORNAM to identify the origin of remote
TCP/IP telnet and ssh connections via TCP/IP Services.
YES YES YES !
Post by Stephen Hoffman
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,
And vice versa too.
Post by Stephen Hoffman
An item code for easier scanning and detecting optical media, and
another for detecting flash media, and SSD.
Detection of SSD media type may be required eventually to implement TRIM
commands by the file system. TRIM_CAPABLE might be another item code,
although not sure it is necessary.

For SSDs, the file system might want to know the PAGE size and BLOCK
size. (page = smallest writeable unit, block = smallest erasable unit.)
These may be transparent to the file system though.


For all drives, itemcodes to access the device's SMART data on disk health.

You may also want to think about access to the power supply/supplies as
a device. (voltage, temperatures, fan speeds, current amperage, whether
battery or power).

Similarly, integration with UPS systems via USB or whatever may present
the UPS as a device that one can interrogate via F$GETDVI.
Dirk Munk
2014-10-18 23:50:51 UTC
Permalink
Post by JF Mezei
Post by Stephen Hoffman
what DECnet did: get DVI$_TT_ACCPORNAM to identify the origin of remote
TCP/IP telnet and ssh connections via TCP/IP Services.
YES YES YES !
Post by Stephen Hoffman
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,
And vice versa too.
Post by Stephen Hoffman
An item code for easier scanning and detecting optical media, and
another for detecting flash media, and SSD.
Detection of SSD media type may be required eventually to implement TRIM
commands by the file system.
Without TRIM you shouldn't use SSD, you will run into big performance
problems. But I'm sure you know that.
Post by JF Mezei
TRIM_CAPABLE might be another item code,
although not sure it is necessary.
Every SSD supports TRIM I assume.
Post by JF Mezei
For SSDs, the file system might want to know the PAGE size and BLOCK
size. (page = smallest writeable unit, block = smallest erasable unit.)
These may be transparent to the file system though.
I don't think a file system erases. It just marks blocks as free, and
the SSD will erase them at a convenient moment.
Post by JF Mezei
For all drives, itemcodes to access the device's SMART data on disk health.
Excellent idea.
Post by JF Mezei
You may also want to think about access to the power supply/supplies as
a device. (voltage, temperatures, fan speeds, current amperage, whether
battery or power).
Normally motherboards gather that information, so you have to get it
from there.
Post by JF Mezei
Similarly, integration with UPS systems via USB or whatever may present
the UPS as a device that one can interrogate via F$GETDVI.
That should work for a small UPS with USB status information.
JF Mezei
2014-10-19 00:08:47 UTC
Permalink
Post by Dirk Munk
I don't think a file system erases. It just marks blocks as free, and
the SSD will erase them at a convenient moment.
Well, the file system does an "erase on delete" except instead of
writing 0s back over the blocks used by the file, it sends a "TRIM"
command for those blocks. The SSD controller then zaps those block so
they can be written to again.
Post by Dirk Munk
Normally motherboards gather that information, so you have to get it
from there.
GETDVI should still be able to provide a documented way with item codes
etc to get power supply info (voltage, amps, temperature, fan speed etc)
Dirk Munk
2014-10-18 23:15:52 UTC
Permalink
Post by Stephen Hoffman
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.
I think it is save to say that all new SATA disks have 4kB sectors,
smaller ones (500GB) included. The cluster size for these disks must be
a multiple of 8 blocks to avoid misalignment. In fact all IO operations
should be done in multiples of 4kB on aligned file systems, otherwise
these disks will get very busy with rectifying misaligned IOs
Post by Stephen Hoffman
DVI$_DEVBUFSIZ gets you want VMS sees, not what the disk can
do.
I suppose you mean the cache size of a disk (32MB or 64MB these days).
It should also be nice if we can see if the write cache of a disk is
enabled, I'm not sure if that is visible now.
Post by Stephen Hoffman
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.
Yes, 10TB disk have been announced.
Post by Stephen Hoffman
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,
That is visible on the name of the device isn't it? DG = FC, DK = SCSI
etc, iSCSI hasn't been implemented yet.

The VMS SCSI-3 driver expects a lun 0 to communicate with a storage
array, in accordance with the SCSI-3 standards. Unfortunately some
arrays (EMC) and iSCSI don't offer a lun 0. That can be a problem. I
don't know what kind of information lun 0 can offer, but perhaps a
$GETDVI for lun 0 could be nice too.
Post by Stephen Hoffman
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 encryption.
Brocade switches will only accept certain types/brands of USB sticks for
firmware updates, I think they use STEC sticks. The reasons is that they
only trust these sticks, others are not reliable enough. Quite similar
to the time that VMS would only accept known SCSI drives. Perhaps such a
check could be used for VMS installations as well, assuming that in
future installations and updates can be done from a USB stick.
Post by Stephen Hoffman
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,
I agree with you that the Cylinder, Heads, Sector information is
completely bogus, however these values are reported in the SCSI pages,
and as I noticed with Solaris, sometimes you need them. Silly, but true.
Post by Stephen Hoffman
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 quagmire.)
I suppose that is the kind of information lun 0 could be offering you.
Post by Stephen Hoffman
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
<http://h71000.www7.hp.com/doc/84final/5763/5763profile_021.html> 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.
Jilly
2014-10-18 17:28:30 UTC
Permalink
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. I received many good ideas over the years, among them
the LAN_* item codes that first appeared in V8.3 (and quietly backported
to V7.3-2).
PERCENT_USED or PERCENT_FREE for disks so as to avoid DCL math
Dirk Munk
2014-10-18 19:25:09 UTC
Permalink
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. I received many good ideas over the years, among them
the LAN_* item codes that first appeared in V8.3 (and quietly backported
to V7.3-2).
It is with more pleasure than you can imagine that I get to make that
query again as a proud member of the VMS Software, Inc engineering staff!
I have no suggestions at the moment, but congratulations on your new
job, and the best wishes for the whole VSI team and VMS.
David Froble
2014-10-18 21:12:16 UTC
Permalink
Post by Robert A. Brooks
Don't forget that our releases will be for IA64 only (until we release
an x86 version). I'll offer any enhancements back to HP for inclusion
in the Alpha
source tree.
Ok, since you mentioned it.

Do you know, and if so can you say, what is going to happen to Alpha VMS
and VAX VMS? Will VSI have access to the products? Will they be
allowed to provide new releases of them, should they decide to do so?

I'm pretty sure HP isn't going to do anything with either, I'm just
wondering whether they are killing them off?
Jan-Erik Soderholm
2014-10-18 22:30:44 UTC
Permalink
Post by David Froble
Post by Robert A. Brooks
Don't forget that our releases will be for IA64 only (until we release an
x86 version). I'll offer any enhancements back to HP for inclusion in
the Alpha
source tree.
Ok, since you mentioned it.
Do you know, and if so can you say, what is going to happen to Alpha VMS
and VAX VMS? Will VSI have access to the products? Will they be allowed
to provide new releases of them, should they decide to do so?
I'm pretty sure HP isn't going to do anything with either, I'm just
wondering whether they are killing them off?
I think I read that when VAX and Alpha are de-supported from
HP according to the currelnt *HP* roadmap, VSI will be able to
take up those platforms. Until then, thay are HP's babies...

Jan-Erik.
David Froble
2014-10-19 01:05:08 UTC
Permalink
Post by Jan-Erik Soderholm
Post by David Froble
Post by Robert A. Brooks
Don't forget that our releases will be for IA64 only (until we release an
x86 version). I'll offer any enhancements back to HP for inclusion in
the Alpha
source tree.
Ok, since you mentioned it.
Do you know, and if so can you say, what is going to happen to Alpha VMS
and VAX VMS? Will VSI have access to the products? Will they be allowed
to provide new releases of them, should they decide to do so?
I'm pretty sure HP isn't going to do anything with either, I'm just
wondering whether they are killing them off?
I think I read that when VAX and Alpha are de-supported from
HP according to the currelnt *HP* roadmap, VSI will be able to
take up those platforms. Until then, thay are HP's babies...
Jan-Erik.
Thanks.

And we can speculate as to why HP has retained them. There will be no
work done, just milking ....

I doubt VSI is going to have any time to even mention the words Alpha or
VAX for a while, but, while some might think they are dead products, it
seems as if there is still some old hardware in use, and, then, there
are those running the emulators.

I'd think the more revenue streams that can be supported would be good
for VSI.

Continue reading on narkive:
Loading...