T4 FC collection/monitor issue

[Peter Zeiszler]

Hoff - I think you nailed it being bug with Monitor.  Disk is accessed now from the Current path - we have to force them to specific paths for the EMC arrays.  But the first path detected during boot is the MSCP on some of the disks - usually the remote room's SAN array.

From documentation on monitor:

http://h71000.www7.hp.com/doc/84final/6048/6048pro_047.html

HP OpenVMS System Management Utilities Reference Manual

An "R" following the device name indicates that the displayed statistics represent I/O operations requested by nodes using remote access.

If an "R" does not appear after the device name, the displayed statistics represent I/O operations issued by nodes with direct access. These I/O operations might include those issued by the MSCP server on behalf of remote requests.

From Monitor - Notice the R after the volume name.

OpenVMS Monitor Utility
DISK I/O STATISTICS
on node POODLE
17-JUL-2015 11:37:13.39

I/O Operation Rate CUR AVE MIN MAX
$1$DGA60: (SETTER) IA64COMMON R 0.33 0.69 0.00 5.66

Show dev full on the disk (removed the other disk and shadow set info).  Notice Primary (first path found) is MSCP.  But Current is the direct path.

Disk $1$DGA60:, device type EMC SYMMETRIX, is online, device has multiple I/O
paths, member of shadow set DSA1000:, shadow set virtual unit, served to
cluster via MSCP Server, error logging is enabled.

Error count 0 Shadow member operation count 9668
Current preferred CPU Id 13 Fastpath 1
Host name "POODLE" Host type, avail HP BL860c i2 (1.60GHz/5.0MB), yes
Alternate host name "SETTER" Alt. type, avail HP BL860c i2 (1.60GHz/5.0MB), yes
Allocation class 1

I/O paths to device 5

Path MSCP (SETTER), primary
Error count 0 Operations completed 0
Last switched to time: Never Count 0
Last switched from time: 17-JUL-2015 10:45:36.48

Path FGA0.5006-048A-CAFE-4102 (POODLE)
Error count 0 Operations completed 53
Last switched to time: 17-JUL-2015 10:45:36.48 Count 1
Last switched from time: 17-JUL-2015 10:45:37.48

Path FGB0.5006-048A-CAFE-410D (POODLE), current
Error count 0 Operations completed 9509
Last switched to time: 17-JUL-2015 10:45:37.48 Count 1
Last switched from time: Never

Path FGC0.5006-048A-CAFE-4102 (POODLE)
Error count 0 Operations completed 53
Last switched to time: Never Count 0
Last switched from time: Never

Path FGD0.5006-048A-CAFE-410D (POODLE)
Error count 0 Operations completed 53
Last switched to time: Never Count 0
Last switched from time: Never

[Volker Halle]

Peter,

T4$FC_MONITOR_NEW.EXE is in no way related to MONITOR.EXE, but it may be using the same or similar code to determine, if a device to be monitored is a FC device with a LOCAL ACCESS PATH !

You will get the same '%SYSTEM-F-IVDEVNAM, invalid device name' error message from t4fcmon, if you try to monitor e.g. a local SCSI device. The code checking for a valid FC device with a local access path may be just checking the attributes of the 'primary' path instead the attributes of the 'current' path to the device. If it thinks it found a FC device via a MSCP-served access path, it correctly rejects monitoring that device.

Something in your configuration is causing the MSCP-path to the SAN devices to be configured BEFORE the local SAN path during boot. This seems to 'confuse' both MONITOR and T4$FC_MONITOR_NEW in the same way.

Volker.

[Peter Zeiszler]

It is probably using same code to determine remote vs local.  The MSCP being PRIMARY path is part of the timing we have had since day one using the EMC arrays.  Only now, after this latest reboot, it indicated ALL arrays LUNS primary path as the MSCP - which means it found the MSCP first.  The timing also includes delays in our boot and rescanning via sysman to see all paths for all disks prior to continuing to boot.

I tried adding a delay of 1 minute into the boot sequence in sypagswap before we scan for disks but that didn't help on discovering the remote room's SAN path first.   Unfortunately my "test' system is a stand alone system and never had this problem. 

When I do a monitor - it is showing all of the disks are R (remote) on this one system.  On other systems it is showing the "remote" disks as those that have primary path as MSCP. 

I think it is using the "primary path" when trying to determine what to read, and I think it should be using "current path".