The FICON Control Unit Port (CUP) provides an in-band management interface defined by IBM that defines the channel command words (CCWs) that the FICON host can use for managing the switch. The protocol used is the IBM version of the ANSI FC-SB4 single-byte command code specification, which defines the protocol used for transporting CCWs to the switch, and for the switch to direct data and status back. FICON CUP is an optional licensed feature for FICON switching devices. Several new advanced diagnostic features have been added to FICON CUP over the past two years.
In this post I will review some basic FICON CUP functionality, and then introduce those new diagnostic features.
FICON CUP Functional Review
FICON CUP is a legacy of CUP on ESCON. The IBM 9032-5 ESCON Directors had an in-band management capability that utilized an embedded port in the control processing cards to provide a communications path to an MVS console. This was used for three primary purposes:
- Reporting hardware errors up to MVS (Helpdesk)
- Blocking and unblocking ports through the prohibit dynamic connectivity mask (PDCM)
- Basic performance monitoring. When switched FICON was being engineered, IBM wanted to make certain that its mainframe customers would have a consistent management look and feel between ESCON and FICON, so CUP was carried forward to FICON.
Today, CUP support is provided by all mainframe storage and SAN vendors, and FICON CUP is usually an optional licensed feature for the FICON switches and directors. It is still used for those three purposes listed above, with additional uses such as RMF reporting for the FICON switching devices and for FICON Dynamic Channel Path Management (DCM).
Traditional uses of FICON CUP
FICON CUP provides an interface for host in-band management and collection of FICON switch performance metrics using the Resource Measurement Facility (RMF) 74-7 record, more commonly known as the FICON Director Activity Report. Through the use of this record and report you can gain a good understanding about frame pacing delay. Frame pacing delay in the FICON Director Activity Report must be carefully analyzed, as numbers in this column of the report do not automatically mean there are inadequate buffer credits assigned.
Host-based management programs manage the FICON switches by sending commands to the switch control unit defined in the I/O Configuration Data Set (IOCDS) and hardware configuration definition (HCD). A FICON director or switch that supports CUP can be controlled by one or more host-based management programs or switch consoles. Control of the FICON switches can be shared between these options. CUP commands, or CCWs, monitor and control FICON switch functions. There are 39 CUP commands, or Channel Command Words (CCWs), for monitoring and control of the FICON director functions. CUP commands are oriented towards management of a single switch, even though the use of CUP in a cascaded FICON environment is fully supported.
Recent Enhancements of FICON CUP
The past two years have seen a series of enhancements introduced by FICON vendors (IBM, Brocade, Cisco, etc.) on FICON CUP. These technology advances have been geared towards making it easier for an enterprise’s z Systems team to get better insight into the FICON SAN fabric from their z Systems management tools. As z Systems environments have grown, and configurations become more complex, FICON fabric issues can result in unacceptable I/O service times. RMF device activity reports would show average service times higher than normal, while I/O queuing reports show abnormally high “initial command response” times on a subset of the paths to a device. Until these CUP enhancements were introduced, it was very problematic to identify a single root cause and where in the configuration the cause occurred.
IBM introduced IOS FICON SAN health checking functionality to provide real-time detection of disparate initial command response (CMR) times that can be a telltale sign of fabric issues. Initial Command Response (CMR) Time isolates the round trip fabric delay portion of the command execution. The z Systems host can then identify where the congestion is occurring and the assumption is the SAN fabric. Vendors have developed fabric diagnostic commands to provide improved data capture and diagnostics capture and reporting via CUP. When the SAN CMR Health Check detects abnormally high CMR times (abnormal meaning >5x average), diagnostic commands are triggered to CUP. The results of the diagnostics are reported on the z/OS management tools.
Fabric Operating System (FOS) 7.4 was qualified by IBM z Systems in June 2015 and included further enhancements to this CUP diagnostic capabilities. The Monitoring and Alerting Policy Suite (MAPS) can also now interface an IBM B-Type FICON director, via the FICON CUP, to the z Systems host, allowing the host to see, through CUP, what corrective automated actions are taken by the FICON director.
Conclusion
FICON CUP has been and remains an important management tool for FICON SAN end users. The simple hardware error and RMF reporting capabilities have been significantly enhanced with powerful diagnostic capabilities since 2013. These new diagnostic capabilities really have enhanced the visibility and end-to-end management capabilities for managing the FICON SAN from the z Systems management consoles.
FICON CUP has always been valuable, it is now even more so.
Steve Guendert, aka “Dr. Steve”, is in an IBM Z senior engineering role based in Poughkeepsie where he is on the IBM Z Hardware architecture team. He works on all aspects of IBM Z I/O and timing architecture, including the Server Time Protocol (STP), FICON and zHPF architectures. He is a member of the Mainframe Hall of Fame and the IBM Academy of Technology.