Jan 17 ’14

Enterprise Networks: FICON Dynamic Channel Path Management (DCM)

by Steve Guendert, Ph.D. in Enterprise Tech Journal

My October/November column discussed the July 23, 2013 set of IBM System z announcements and how those announcements encourage channel consolidation by IBM System z customers. One of the items I briefly covered was Dynamic Channel Path Management (DCM) for FICON. Here I will discuss DCM in more detail and make the case for why you should seriously consider implementing DCM.

DCM support for native FICON channels was originally introduced in z/OS V1.11 with support for a single, intermediate FICON switching device between the FICON channel and storage control units. In IBM z/OS V2.1, DCM was significantly enhanced to support FICON channel path connections through two intermediate FICON switching devices; i.e., DCM for FICON now supports cascaded FICON configurations.

This really is an important step in the evolution of System z I/O architectures. With DCM for FICON now supporting cascaded configurations, it will be much easier to use fewer channels (channel consolidation) and optical fiber connections for FICON I/O, particularly for multisite installations that rely on cascaded FICON. Remember, z/OS V2.1 also introduced support for up to 24K subchannels per FICON channel.

DCM enables the system to automatically manage FICON I/O paths connected to DASD subsystems in response to changing workload demands. 

According to the IBM Whitepaper “FICON DCM for Systems Programmers,” the objectives for FICON DCM are fivefold:

1. Simplify I/O configuration planning and definition
2. Reduce the customer skills required to manage z/OS
3. Dynamically balance I/O channel resources
4. Use channel resources more efficiently
5. Enhance availability.

DCM does all this by letting customers identify FICON channels they wish to be “managed.” Managed channels are channels that aren’t assigned to any specific control unit by the customer. Instead, these channels are viewed as a pool of FICON channels that may be assigned dynamically to control units at the discretion of the system.

By assigning channels to the pool of managed channels, the system is able to respond to peaks in control unit demand for I/O channel bandwidth. In addition, this reduces the complexity of defining the I/O configuration: The end user is no longer required to define a configuration that will adequately address any variations in workload. This allows him to specify a much “looser” configuration.

One of the things that’s readily apparent, as I meet with many of you around the world, is how overconfigured I/O architectures are. Yes, you absolutely need to plan for redundancy in the event of some type of failure somewhere in the configuration. But there’s a difference between planning for redundancy and overkill. And when your configuration has two to three times the number of FICON channels configured than what you actually use during periods of peak production workloads, you have overkill along the lines of what the U.S. and Soviet Union had with their nuclear arsenals back in the ’80s.

FICON channels have improved remarkably in terms of I/O performance over the last five years, particularly when implementing IBM System z High Performance FICON (zHPF). Yet, most of your configurations have changed very little to take advantage of those improvements, or improvements such as DCM or the enhanced channel load balancing algorithms. We’re still doing the same ol’, same ol’ architectures. When we upgrade to a new processor with new channels, we still get the same exact number of channels; there’s no channel consolidation at all. 

What boggles my mind even further is how many end-user installations haven’t even taken the time to do some form of testing and analysis to see if and how they could consolidate their FICON channels, and how DCM and the other enhancements may benefit them.

I’d encourage you to take a long, serious look at FICON DCM. Do some analysis to see how it would work in your environment. Look at your channels and conduct a study of how you could consolidate channels yet still keep sufficient redundancy. Reagan and Gorbachev got rid of some overkill; you could, too, and likely save your organization some serious money and make your job easier.