This is the fourth in a series of posts reflecting on the history of storage attachment for z Systems.  If you missed it, the first 3 entry can be found on the main blog.

Picking up where we left off……

The S/370 I/O architecture was powerful in that it established a means by which an operating system could drive I/O operations to storage devices of different types and from different vendors, so long as the device followed this communication architecture.  As was noted in my last post, the goals of this architecture included security/integrity, resiliency, and performance.  As technology evolved, it became clear that enhancements to this architecture were necessary.  The concept of a ‘channel subsystem’ was first introduced in the IBM 3081 servers, which allowed for greater flexibility and facilitated improvements in both performance and resiliency.  This concept of a ‘channel subsystem’ is extremely powerful, and really differentiates z System I/O.  In S/370, a set of channels were connected to a single CPU, and an individual channel could only be addressed by the CPU to which it was connected.  The operating system selected the channel, and then the device on that channel.  When an operation completed, the channel could also interrupt only that CPU to which it was connected.  Also, once a chain of operations was initiated with a device, the same channel path had to be used to complete the transfer of all data, commands and status (remember that with command chaining a single I/O operation could initiate multiple actions at the device and multiple interactions between the channel and the device).  With the new S/370-XA eXtended Architecture combined with the new ‘channel subsystem’ that was accessible to all CPUs on the server, any CPU could initiate an I/O function with any device and could likewise accept an I/O interruption from any device.  If the device disconnected partway through the I/O operation, it could now reconnect on any available path.  The channel subsystem also relieved the operating system from the burden of selecting a path….now the operating system selected a device number (corresponding to something internally called a ‘subchannel’), and the channel subsystem knew all the addressing necessary to get to that device and choose the best path.  

The S/370-XA architecture combined with the ‘semi-autonomous’ channel subsystem enabled improved performance in many ways.  First, all I/O instructions could now be executed asynchronously by the CPU with respect to the channel subsystem, freeing the processor up to do other things.  In addition, along with path selection being ‘off-loaded’ to the channel subsystem, I/O busy conditions were also handled by the channel subsystem without CPU involvement.  This reduced the CPU overhead previously required to process ‘no-longer-busy’ conditions and to process (possibly recurring) busy conditions that may have been encountered on path selection.   The function of the new channel subsystem also reduced the number of conditions that interrupted the CPU, eliminating things like ‘channel available’, ‘control unit end’, and ‘device-end-no-longer-busy’ conditions.  And because the operating system effectively handed over the channel program to the channel subsystem and allowed it to manage the execution of it with the device, all CPU code and cycles related to managing the differences between device types (such selector devices vs multiplexor devices) were eliminated.

The concept of a channel subsystem wasn’t the only technology advancement that accompanied the new architecture.  In 1990, on the 3090 system, IBM introduced ESCON channels, which used fiber optic (serial) connectivity instead of the prior copper cables used in parallel channels.  ESCON link technology supported 20MB/sec throughput (for reference, copper-based parallel ‘bus & tag’ channels were at best capable of 4.5MB/sec).  The first supported device was a communication device, followed closely by channel-to-channel support.  While devices were still circuit-connected (i.e. communication with only a single device at a time was possible), ESCON supported the introduction of the first modern storage area network (SAN) with dynamic switching capabilities.  Dynamic switching enables multiple hosts to access the same storage device, with atomicity controlled by the device itself.  When a connection is established between two ports, it appears as one continuous link.  The switch can establish or remove a dynamic connection via information in frame delimiters (at the beginning of the frame to indicate the establishment of a dynamic connection) or other sequences (at the end of a frame to indicate whether to retain or remove a connection).  With ESCON link technology and SANs, distance limitations (between server and device) also improved from the prior 400 up to 9km, as serial transmission enabled greater distances between communication points, limited by how far an LED could drive.  Each ESCON channel could support 1000 devices (up from the prior 256 limit), which was needed because multiple switch ports in the SAN now allowed connection to multiple control units.

ESCON continued to deliver on the foundational aspects of improved security, resilience, and performance, and the next post in this series will describe some of the mechanisms used to achieve that.

Editors Note: This post was authored by Patty Driever from IBM and is the 4th post in a series on I/O on the mainframe.  If you like this blog, suggest you follow Patty on Twitter @mainframeiolady or check back next week (hopefully Friday) for the next installment.