Let’s talk about the zEC12, FICON directors, cars and tires. Huh? Bear with me for a few minutes.
On Aug. 28, 2012, IBM announced the zEnterprise EC12 (aka zEC12). Most of you are well aware through firsthand use that it’s quite an impressive machine in terms of performance, scalability and management. I'd like to focus on the channel subsystem enhancements introduced with the zEC12. They all deal with a very important topic: overall performance of the FICON environment.
IBM enhanced the I/O subsystem of the zEC12 to provide improved throughput and I/O service times when abnormal conditions occur. These abnormal conditions include multi-system resource contention in the Storage Area Network (SAN) or at the control unit ports, SAN congestion, improperly defined SAN configurations, dynamic changes in fabric routing, firmware failures, hardware failures (such as link speeds not initializing correctly), cabling errors and destination port congestion. When these abnormal conditions occur, they can cause an imbalance in I/O performance characteristics (such as latency and throughput) across a set of channel paths to the control unit. The zEC12 channel subsystem is designed to intelligently utilize the channels that provide optimal performance. This enhancement is accomplished by exploiting the in-band I/O instrumentation and metrics of the System z FICON and System z High Performance FICON (zHPF) protocols and new intelligent algorithms in the channel subsystem designed to exploit this information.
When conditions occur that cause an imbalance in performance (I/O latency/throughput), the channel subsystem will bias the path selection away from poorer performing paths toward the well-performing paths. This channel subsystem enhancement is exclusive to the zEC12, is supported on all FICON channels when configured as CHPID type FC and is transparent to the operating system. To coincide with these enhancements, IBM introduced an enhancement to the RMF Direct Access Device Activity report. This enhancement, Average Interrupt Delay Time (AVG INT DLY), is measured in units of milliseconds encountered for I/O requests to a device. For each I/O request, the time is measured from when a subchannel is made status pending with primary status to when the status is cleared by TSCH and executed in the operating system.
These are some pretty impressive capabilities for zEC12 installations to utilize. But I digress ...
Years ago, I was the “proud” owner of a 1995 Chevy Cavalier. That was a step up from the 1984 dark brown Plymouth Horizon I had driven earlier in my life. One thing the two cars had in common, besides the lawn mower engine, were tires with a track width the size of bicycle tires. This was fine, since such cars weren’t made for performance and high-speed cornering.
Now, let's say I wanted to upgrade that 1995 Cavalier to a 2013 Chevy Corvette ZR1, which is a high-performance super car. Comparing the performance of a Chevy Corvette to that 1995 Cavalier is like comparing the I/O performance of a new IBM zEC12 to an IBM z900. However, suppose that to save some money, I decided that rather than pay the extra money for the Michelin Pilot Sport Cup tires, I would simply keep the tires from my Cavalier and move them to the Corvette.
Guess what happens the first time I drive that Corvette, step on the gas and try to take advantage of that 638 horsepower/604 ft-lbs of torque 6.2 liter V-8 motor going around a corner?
The point I’m trying to make is that your FICON SAN is the tires of your mainframe infrastructure. If you’re upgrading your mainframe from an older platform (Chevy Cavalier) to a newer, high-performance machine (Chevy Corvette) and not upgrading your FICON infrastructure (tires), you aren’t going to get the best use and performance from your expensive investment in the new machine (zEC12).
Far too many end users who have undergone mainframe upgrades in the past and have FICON directors that are five-plus years old have elected to upgrade the processor and storage without upgrading the tires and they continued with the old FICON SAN infrastructure. Do you think they achieved the I/O performance they paid a premium for? While the older M6140, Mi10K, USDX and Edge 3000 were great FICON SAN platforms, they were designed for the mainframe technology of their time (2002 to 2006). Why run a zEC12 with a z990 era FICON SAN?