IOS_FABRIC_MONITOR

Typically, a fabric network requires careful planning, implementation, and maintenance in order to provide healthy operation. When a switch determines that there is a performance problem with a path, it will signal to z/OS® that such a problem has been found and that diagnostic data is available. This action results in the route being monitored by z/OS. At regular intervals, z/OS will obtain health diagnostic data. This health check report contains the formatted diagnostic data.

The check issues an exception if a switch has indicated to z/OS there is a possible health problem. The report will be updated at regular intervals with the latest diagnostic data until two hours after the switch stops reporting a health problem.

Example behavior:

A switch with CUP diagnostics support signals to z/OS that there is a health problem. z/OS initiates monitoring for the path, requesting diagnostic data from the switch at regular intervals. The problem may require intervention, i.e. MVS™ system commands or I/O configuration. Once no errors or health issues have been detected by the switch for at least 2 hours, the monitoring of the route is stopped and will no longer appear in the report.

Report information:

The report will indicate path information, the time of the exception, and the diagnostic data provided by the switch.

PARM(’LOG(NO|YES),SHOW(LATEST|ALL)’)

LOG(NO|YES)

LOG determines if z/OS should request that a diagnostic log should be generated by the switch. The diagnostic log will only be generated when the first unusual condition is detected if the YES option us used. The switch log is not generated if the NO option is used.

The switch log may be useful in diagnosing the fabric problem and its contents are defined by the switch vendor.

Supported values: NO and YES

Default: NO

SHOW(LATEST|ALL)

SHOW determines how many diagnostic records should be formatted in the health check report. If LATEST is used, only the most recent diagnostic data is reported. If ALL is used, all diagnostic records since monitoring began will be provided.

The historical data may be useful in diagnosing the problem.

Supported values: LATEST and ALL

Default: LATEST

Note: If any parameter is changed, the check results may not reflect these changes for several minutes because the check must gather a few minutes worth of data before performing analysis using the new parameters.

The following sample shows the defaults for customizable values for this check. Use this sample to make permanent check customizations in an HZSPRMxx parmlib member used at IBM Health Checker for z/OS startup. If you just want a one-time only update to the check defaults, omit the first line (ADDREPLACE POLICY) and use the UPDATE statement on a MODIFY hzsproc command. Note that using non-POLICY UPDATEs in HZSPRMxx can lead to unexpected results and is therefore not recommended.

ADDREPLACE POLICY[(policyname)] [STATEMENT(name)]
UPDATE
CHECK(IBMIOS,IOS_FABRIC_MONITOR)
ACTIVE
VERBOSE(NO)
INTERVAL(00:30)
SEVERITY(MED)
DATE(’date_of_the_change’)
PARM('SHOW(LATEST),LOG(NO)')
REASON(’Your reason for making the update’)

• IOSHC119E