1745816 Members
3898 Online
108722 Solutions
New Discussion

Getting Disk Status

 
SOLVED
Go to solution
Jack Trachtman
Super Advisor

Getting Disk Status

I am writing a DCL script to get disk status, similar to what is shown by SHO DEV diskname.

 

The most common status's (statii?) that I see are: Mounted, Online, Offline, and Mount-Verify Timeout.

 

The Mount status can be easily gotten via F$GETDVI( diskname,  "MNT" ).

 

To get the other status's I took the value returned by F$GETDVI( diskname, "STS" ) and broke apart the bit-mapped info.  But this doesn't seem to be showing me something I can relate to Mount-Verify Timeout.

 

I was thinking of trying to decode the output from F$GETDVI( diskname, "DEVSTS"), but I'm wondering if I'm making this too complicated.

 

Can anyone suggest, or point me to some example DCL, that returns the above disk status info?

 

TIA

9 REPLIES 9
Craig A Berry
Honored Contributor

Re: Getting Disk Status

I don't know of anything in DCL that will decode those bitmaps.  The Perl extension VMS::Device will do the trick, though:

 

$ type devsts.pl
use strict; use VMS::Device qw(device_info decode_device_bitmap); my $i = VMS::Device::device_info($ARGV[0])->{STS}; my $status_hash = VMS::Device::decode_device_bitmap('STS', $i); for my $status (sort keys %$status_hash) { print "$status\n" if $$status_hash{$status}; } $ perl devsts.pl $23$dga13: EXFUNC_SUPP FAST_PATH LCL_VALID ONLINE UNLOAD VALID

 You should see TIMOUT in the list if that's what's happening on your device.

Craig A Berry
Honored Contributor

Re: Getting Disk Status

Actually, I think that's not the timeout you want.  From ucbdef.h:

 

/*   These fields count reasons for our returning SS$_MEDOFL to help us diagnose excessive Mount Verifies */
#define UCB$L_DK_TIMEOUT        912     /*   I/O Timed Out */
#define UCB$L_DK_DRVERR 916             /*   SS$_DRVERR returned from port */
#define UCB$L_DK_CTRLERR        920     /*   SS$_CTRLERR ... */
#define UCB$L_DK_DEVOFFLINE     924     /*   SS$_DEVOFFLINE ... */
#define UCB$L_DK_UNIT_ATTENTION 928     /*   Unit Attention CHECK CONDITION */
#define UCB$L_DK_VENDOR_SPECIFIC        932 /*    */
. . .

 but I don't know offhand (and couldn't quickly find in the docs) how to request whether UCB$L_DK_TIMEOUT has been detected.

Volker Halle
Honored Contributor

Re: Getting Disk Status

Jack,

 

the souce code of SHOW DEVICE (in this case [CLIUTL]SHODEVPRT) has the following comment for the MntVerifyTimeout state:

 

! If the volume is not valid AND mounted AND is Files-11, then it has failed
! mount verification and it should be marked "MntVerfyTimeout"

 

You should find all the state bits you're interested in in SYS$LIBRARY:LIB.REQ (looks below $UCBDEF)

 

Volker.

Jack Trachtman
Super Advisor

Re: Getting Disk Status

Volker,

 

Thank you VERY much for looking that up!

 

Do you think that MOUNTCNT is also a derived value in SHOW DEVICE? See below:

 

$ SHO DEV DSA200

Device Device Error Volume Free Trans Mnt
Name Status Count Label Blocks Count Cnt
DSA200: Mounted 0 SYSDISK2 52171136 2320 2  <===
$1$DGA1050: (INTEGD) ShadowSetMember 0 (member of DSA200:)
$1$DGA2050: (INTEGD) ShadowSetMember 0 (member of DSA200:)


$ WRITE SYS$OUTPUT F$GETDVI( "DSA200:", "MOUNTCNT" )
1  <===

 

 

(OpenVMS v8.4, latest patches)

Volker Halle
Honored Contributor

Re: Getting Disk Status

Jack,

 

F$GETDVI(device,"MOUNTCNT") shows the mount count on the local node, whereas SHOW DEVICE shows the cluster-wide mount count of the disks (obtained by scanning cluster-wide locks - see [CLIUTL]SHOWDEVCLU routine scan_cluster_locks). Not something that could be done by a DCL procedure.

 

Volker.

Jack Trachtman
Super Advisor
Solution

Re: Getting Disk Status

Thanks again Volker!

Hoff
Honored Contributor

Re: Getting Disk Status

 

FWIW, common VMS system management problems have often already been solved once or twice.

 

There's somebody else presently re-solving a very similar problem in comp.os.vms for instance.

 

There are archives of existing resources; decuslib.com has a large archive of DCL tools and procedures, as does the Google Groups search when targeting comp.os.vms, and there are other resources and sites around.  If the archives don't have exactly what you need for your environment, you'll usually find a related example that can be modified and used.

 

If you're interested in a different approach, there are tools around that use SNMP to monitor disk status remotely, too.  See if your IT environment monitors this, as VMS can present a variety of disk data via the add-on SNMP MIB bits.  

 

More on SNMP and MIBs and related: snmpwalk, AgentX, Nagios NRPE, beware of the SMH security bugs, etc. 

 

 

ps: "Not something that could be done by a DCL procedure"?    Sure it can.   Two ways:  first and easiest, use the DVI$_MOUNTCNT_CLUSTER itemcode.   (Works from DCL and f$getdvi("ddcu:","MOUNTCNT_CLUSTER"), too.)   If you're not within the last ~seven years or so with patches or are running further back than OpenVMS Alpha V7.3-2, then DCL DECnet task-to-task can gather the data on each host.

 

"Given the above, the arrival of the new item code DVI$_MOUNTCNT_CLUSTER may be of interest. This item code will "first" appear in OpenVMS I64 V8.3-1H1, expected to ship some time in the fall of 2007. As V8.3-1H1 is a limited hardware release targeted for I64 blade systems, there will be no release for Alpha; the next general purpose release for OpenVMS Alpha will be V8.4. No backport for OpenVMS VAX will be done. This item code has been backported to V7.3-2, V8.2, V8.2-1, and V8.3, and will require future SYS (for $GETDVI) and DCL (for F$GETDVI) kits. There will be no backport for the RTL routine LIB$GETDVI. I expect that the kits for the above versions will be available in the next month or so."  

 

(Haven't looked to see if this stuff was added into the patch notes, but I think it was...  That's where the documentation for various feature updates got moved; away from the release notes and new features manuals.  That's pretty well hidden from the search engines, too.)

 

Ah, hello "Your post has been changed because invalid HTML was found in the message body. The invalid HTML has been removed. Please review the message and submit the message when you are satisfied."   Um, no, I didn't insert any rogue HTML.  You did.   

 

Jack Trachtman
Super Advisor

Re: Getting Disk Status

Hoff,

 

Thanks for the info about the "MOUNTCNT_CLUSTER" arg to F$GETDVI.   I wonder what other available arguments aren't listed in the HELP text.

Hoff
Honored Contributor

Re: Getting Disk Status

 re: "I wonder what other available arguments aren't listed in the HELP text."

 

Donno.

 

When the manuals haven't been opened and updated for an OpenVMS release, there'll obviously be omissions.

 

I usually just read the header files, then refer back to the manuals when necessary.  (If you're inclined to check for yourself, then use  DIFFERENCES across two versions, and have a look...)

 

HP announced that any enhancements were going to be arriving via UPDATE kits a while back, so the patch release notes also became the documentation to check for those changes, too.

 

Why, hello "Your post has been changed because invalid HTML was found in the message body. The invalid HTML has been removed. Please review the message and submit the message when you are satisfied.", we meet again.