gathering I/O statistics from devices in SAN...

[The Brit]

Byron,
The two paths you see means that your system has two HBA's and is probably connected either both to a single fabric, or each to a separate fabric, in your SAN. The "current" path is the path that your system is currently using for IO. It is normally the same as the "Primary" path. Note, it doesn't have to be the same, see the "set device /switch=..." command.

The numbers indicate only (IO) Operations completed, and do not tell you anything about whether they were reads or writes.

Dave.

[Jan van den Ende]

Byron,

for the way of saying "thank you" in these forums, please see

http://forums1.itrc.hp.com/service/forums/helptips.do?#33

Proost.

Have one on me.

jpe

[Richard W Hunt]

We are also multi-pathed as a matter of both redundancy and load sharing. I, too, see counts on both paths.

Here's the situation, to the best of my understanding.

Though either path can be used to get to any disk on the SAN, there is a "preferred" path. At reboot, the device driver somehow apportions the drives to one path or the other. However, according to my SAN guy, both paths go active when I reboot (perhaps because multipathing is verifying the alternate path?) Try this command:

SHOW DEVICE/MULTIPATH

You should see all devices having redundant paths and, at the rightmost end of the line, you should see which path currently is primary for that device.

The error and operation counts for SHOW DEVICE/FULL will show path-based counts. If you used, say, F$GETDVI on the device's OPCNT or ERRCNT fields, you would get back the sum of those path counts. (I tried it before I wrote this.)

If you have a problem with where the device is currently pathed, you have the command

SET DEVICE ddcu: /SWITCH/PATH=path-name

that will try to reset the primary path to the name specified. I suggest looking at the example in HELP SET DEVICE/SWITCH to see the details.

As far as the EMC toolkit stuff, I hardly ever use it. OpenVMS tools work just fine if you bother to track such things. (Which I sometimes do...)

[Richard W Hunt]

Robert, the fibre_scan utility was added to OpenVMS 7.3-2 by the patch:

OpenVMS_FIBRE_SCSI version 13

The SYS$ETC:FIBRE_SCAN utility explores the fiber channel paths to see what will respond. The list can be pretty big, so you might wish to capture the output to a file rather than just letting it hit your screen.

Because I have a system with a gazillion little disks (don't ask... I inherited it that way), and I have FOUR x KGPSA (2 to HSG80, 2 to SAN), the output from that little utility overflows my scroll buffer on my one-lung terminal emulator.

But then, that's what I get for working with the government. They buy a system with a gazillion disks and then give me a relatively inadequate terminal emulator. Go figure.

[Byron Fowlkes]

well certainly thanks to all who have responded, I have learned things that I had no knowledge of before posting this thread.. by using the FC statistical display I have been able to gain some method to get rudimentary data on reads and writes on devices in the Fibrechannel.. I will continue to gratefully monitor this forum for any tips/techniques that can help me master this beast..

[Robert Brooks_1]

The error and operation counts for SHOW DEVICE/FULL will show path-based counts. If you used, say, F$GETDVI on the device's OPCNT or ERRCNT fields, you would get back the sum of those path counts. (I tried it before I wrote this.)

--

$GETDVI (SYS$, LIB$, and F$) supports the use of a pathname parameter for certain item codes to get path-specific information. Whilst OPCNT and ERRCNT are aggregated in the absence of a path specification, you can get the path-specific values for those item codes if you want. The documentation should have more detailed information.

Support for path names was first added for V8.2 (both Alpha and I64). It was backported to V7.3-2. Virtually all item codes that are current for V8.3-1H1 have been backported (unofficially and unsupported) to V7.3-2, V8.2, V8.2-1, and V8.3).

-- Rob

[Ian Miller.]

For more info on T4 see
http://trendsthatmatter.com/

I expect it is possible to integrate the data from the EMC tools into T4