Read Diagnostic Parameters (RDP) is a fiber channel extended link service invented by IBM. RDP is implemented by the DS8000 family of storage systems, the IBM z13 processor, FICON directors and the z/OS operating system. RDP provides z/OS and SAN tooling an in-band mechanism for retrieving link instrumentation data that provides data conveying the health of the port. With z/OS exploitation of the z13 RDP capabilities, the time and effort required to diagnose the root cause of SAN errors is greatly reduced.

Read Diagnostic Parameters (RDP) Details

RDP exploitation was introduced by IBM in 2016 with the GA2 version of the z13 server. When connected to the DS8870 Release 7.4 firmware, and beyond, the z System server’s channel subsystem firmware automatically retrieves the RDP data for the entire I/O configuration. This includes the channel RDP data, the entry port to the SAN, the SAN exit port and the storage control unit port. The data is refreshed by the channel subsystem once each day. The z/OS operating system gathers the data up each day and writes it to SMF records for future analysis.

z/OS also has the ability to gather diagnostic data for the ISL links. This will be the subject of a future blog entry.

Figure 1: Read Diagnostic Parameters (RDP) – RDP is a fiber channel extended link service that provides an in-band mechanism for retrieving link instrumentation data from the channel port, SAN entry port, SAN exit port and storage system port.

Further details of RDP capabilities are available in the following publications:

Real Life Diagnostic Example
The example shown in figure 2 below is for a point-to-point FICON connection between a z13 processor and a DS8886 storage system. The client noticed the IOS050I message indicating that interface control check errors were occurring. On prior generations of equipment the client would need to insert optical light meters to detect the optical signal strength from the channel, to the patch panels and into the storage system. This is disruptive to normal operations in that light is lost when unplugging the optical connection from the server or storage to insert the light meter. This needs to be coordinated with the operations staff so as not to cause any additional errors such as not operational conditions (IOS001E, IOS002A or IOS444I messages). It is possible that the wrong cables can be disrupted, causing errors to occur on otherwise perfectly operating equipment.
As can be seen in the example in figure 2, the in-band RDP data clearly shows the control unit port as the source of the errors. The control unit port is transmitting with a degraded optical signal strength, as detected by the channel.

Figure 2: Real Client Experience – Client configuration consists of point to point links between the DS8000 storage system and the IBM z13 server. In this example the channel is detecting that the optical signal strength of the control unit attached to channel path 8E was significantly degraded at IPL time and has gotten worse over time. The control unit is the source of the interface control checks that have been occurring.

Conclusion
The Read Diagnostic Parameters extended link services invented by IBM and delivered in the IBM z13 server, FICON Directors, DS8000 family of storage and exploited by z/OS. RDP simplifies SAN problem determination by eliminating disruptions to the production work load required in order to insert light meters into the optical connections formally needed to find the source of a degraded kink connection.
RDP prevents possible manual errors that can occur if the wrong links are disrupted, reduces manual effort and eliminates the time and cost of running around the machine room floor inserting and removing light meters.

Learn more about the IBM DS8880 family today.

1 comment on"Rapid SAN Problem Determination with DS8880 Fiber Channel Diagnostic Parameters"

  1. […] an example application of this technology, see Rapid SAN Problem Determination with DS8880 Fiber Channel Diagnostic Parameters. The IBM DS8880 release 8.3 (3Q2017) provides even more access to RDP by providing visibility to […]

Join The Discussion

Your email address will not be published. Required fields are marked *