GETDVI for multipath

[Peter Zeiszler]

I use Big Brother to watch the majority of my VMS systems. I want to create a script to watch my multipath devices so that I can setup an alert when I have a path failure. All of my BB scripts are in DCL so that I know I can use them everywhere and for ease of modifications.

In the GETDVI I can check if a device is Multipath or what the current path is but I don't see anything that polls the number of available paths. On all of my FC connected disks I have 3 paths (2 through the FC cards and 1 through MSCP). I want to poll that both FC paths are available and if one drops then to update the BB information.

Is there another location to pull this information? I can see the details when I do a show dev/multi or if I do a show dev/full.

I run on Alpha servers. OpenVMS 7.3-1, 7.3-2, and 8.2.

[Phillip Thayer]

Check the DVI$_AVAILABLE_PATH_COUNT code of the $GETDVI finction.

[Robert Brooks_1]

Hi,
For V8.2 (and unofficially backported to V7.3-2), there is much greater support for multipath devices within $GETDVI.

One can now specify a particular path about which to get information. The pathname is an optional parameter for all of SYS$GETDVI, LIB$GETDVI, and F$GETDVI.

Of interest to you would be dvi$_path_not_responding.

dvi$_total_path_count may also be of use.

While there is also dvi$_path_available, that item code will not likely be particularly interesting -- for reasons that are too complex to explain here, that item code will always return "TRUE" (or 1).

The documentation for V8.2 does a reasonably good job of explaining the optional pathname parameter; the description of the various item codes in the "System Services Reference Manual" states which item codes can make use of that parameter.

If you have any questions about $GETDVI or multipath devices, or if you want to give me suggestions about additional item codes that would help you out, please let me know!

-- Rob (VMS Engineering -- I maintain $GETDVI and multipath).

[Peter Zeiszler]

Do you have sample code for making the call to sys$getdvi?

I do have a system that has the C compiler. I have never made use of a system call. If its possible to make use of the system calls in DCL that would really rock since thats where I have created 99.999% of my scripts. Only once have I had to work in macro and that was on VAX 5.5.

[Phillip Thayer]

Peter,

Use the DVI$_AVAILABLE_PATH_COUNT with the F$GETDVI lexical function in DCL to get what you are looking for.

Phil

[Peter Zeiszler]

I tried that and it returned:
write sys$output f$getdvi("$1$dga435:","DVI$_AVAILABLE_PATH_COUNT")

%DCL-W-IVKEYW, unrecognized keyword - check validity and spelling
\DVI$_AVAILABLE_PATH_COUNT\

[Robert Brooks_1]

when using lexical functions from DCL, you cannot include the "dvi$_" prefix.

an example . . .

$ write sys$output f$getdvi( "$1$dga33", "available_path_count" )
5

[Peter Zeiszler]

That works on the OpenVMS 7.3-2 and the 8.2 systems I have.

I went looking in the DVIDEF.H file and didn't find any references to the available path or path_count.

So I might or might not have a solution using C compiled on an openvms 7.3-2 or 8.2 system.

Any ideas on gaining this information on the 7.3-1 system?

[Robert Brooks_1 · Accepted solution]

Peter wrote . . .

That works on the OpenVMS 7.3-2 and the 8.2 systems I have.

I went looking in the DVIDEF.H file and didn't find any references to the available path or path_count.

So I might or might not have a solution using C compiled on an openvms 7.3-2 or 8.2 system.

Any ideas on gaining this information on the 7.3-1 system?

---

If you see my first reply, I said that the work was unofficially backported to V7.3-2.

What that means is that we don't generate new language-specific STARLET libraries (as in dvidef.h from sys$starlet_c.tlb). However, you can extract those definitions from a V8.2 system and insert them by hand into your V7.3-2 sys$library:sys$starlet_c.tlb.

You don't need to do anything to get the new stuff to work from DCL on V7.3-2 because when DCL was rebuilt for one of the kits you've installed, it gained knowledge of the new item codes automatically.

This work will never be backported to V7.3-1 -- sorry.

-- Rob

[Peter Zeiszler]

Guess this falls into just another reason to upgraded to a supported OS level :D

Thanks for all of the input. I am not sure if I will extract the libraries and change the current one or just created the script only for the supported OS levels.

Its nice to know that I can do the system calls in the lexicals. Might make for some better scripts for my monitoring.

[Peter Zeiszler]

Just closing the thread.