Read Diagnostic Parameter (RDP)

Edit online

TS7700 with 16Gb FICONs supports Read Diagnostic Parameters (RDP). RDP is useful in diagnosing performance problems and/or interface issues.

The command is issued in MVS, option s;log. The MVS command syntax is:

D M=DEV(devno,(chp)),LINKINFO={FIRST|LAST|REFRESH|COMPARE}

The LINKINFO parameter may only be specified when a path is specified on the D M=DEV command.

The example shows a switched configuration with 16Gb end to end ports.  The Buffer Credit and Forward Error Correction (FEC) uncorrected error counters are not available at this time.
  • FIRST - displays the link diagnostic information that was obtained during IPL or when the physical path was brought online for the first time after IPL.
    Figure 1. FIRST

    The command is issued in MVS, option s;log.

  • LAST - Displays the link diagnostic information that was last retrieved by the system. The system retrieves new information for a physical path every 24 hours or when LINKINFO=REFRESH is specified.
    Figure 2. LAST
  • REFRESH - Requests that the system obtain new link diagnostic information for the physical path and then displays that information. This causes the prior information to be replaced and a subsequent LINKINFO=LAST request will also show this new information.
    Note:
    1. A REFRESH request does not cause the entry switch port, exit switch port and control unit port to retrieve new optical transceiver information. It simply causes the last retrieved values to be returned to the channel subsystem. The frequency that a port retrieves its own optical transceiver information is manufacturer and model specific.
    2. A REFRESH request will be rejected if the channel specified in the command is already processing the maximum number of concurrent requests. These requests could be from this system or other systems on the same processor. The maximum number of concurrent requests allowed for a channel is model dependent.
    Figure 3. REFRESH
  • COMPARE - Displays a comparison of the first and last set of link diagnostic information that was retrieved by the system.
    Figure 4. COMPARE

Error counters are cumulative. The error counters are cumulative, so seeing a very large error counter may not indicate a problem. Observing how error counters change over time is what matters. During the attenuator test to degrade the optical signal between the channel and entry switch ports, interface control checks occurred because of the weak optical signal, which resulted in many IOS050I CHANNEL DETECTED ERROR messages. Notice how the error counters (Link Failures, Loss of Signal, Invalid Trans Word and Invalid CRC) changed as a result of the test.

Before
Figure 5. Before error
IOS050I CHANNEL DETECTED ERRORs occurring
Figure 6. Error occurrence
After
Figure 7. After error

TS7700 examples

Example #1: TS7700 host jobs failing due to link errors:

Figure 8. Comparison of stats from 12/16 to 12/26 to search for invalid CRC and FEC uncorrected value changes

Example #2: TS7700 host jobs failing due to link errors

For CHPID AB, It looks like there is a big power drop at the receiver of the CHPID. The CU Tx power says it's good, so maybe a problem with the SFP on the channel side (or the one link in that direction at the patch panel somewhere.
Figure 9. FEC uncorrected value

Example #3: dBm errors:

The "Rx Power (dBm)" value of ficon2 port1 was very bad than the other port. It was -15.9 dBm , although the others are approximately -1.5 through -2.5 dBm.
Figure 10. dBm errors