(ED) This is the third in a series of posts reflecting on the history of storage attachment for z Systems by Patty Driever who has the coolest Twitter handle given her speciality @mainframeIOlady
Having covered the early S/360 and S/370 I/O architecture in my last post, let’s take a look at the early parallel channel technology that supported that architecture and began the evolution towards today’s channels.
Early S/360 systems had a single ‘byte’ channel, and one to six ‘selector’ channels. Communication over these channels occurred using a new standardized ‘bus and tag’ interface to a new family of devices. The ‘bus’ carried the data, and the ‘tag’ provided the control signals. Parallel channels connected via ‘bus and tag’ cables to a circuit of multi-drop control units and devices (see picture below). The channel could communicate to only one device at a time, and there was an architectural limit of 256 devices per channel. Typical ‘bus and tag’ communications across the circuit began with an ‘initial selection’ sequence to establish a connection with a control unit….if the device address that accompanied the ‘select out’ tag was not recognized, the tag wrapped back through the circuit to the sending channel as ‘select in’. Once a device was selected, the data transfer sequence began, and the control unit always controlled the data transfer, with the transfer of each byte of data requiring 2-way communication in order to provide a reliable storage transport. For a read operation, the control effectively said ‘I’m sending a byte’ and the channel would respond ‘I received a byte’. For a write operation, the control would say ‘I’m ready for a byte’ and the channel would respond ‘Here’s a byte’. This sequence repeated over and over again until one side recognized that all of the available or required bytes had been transferred, at which point an ‘ending sequence’ occurred.
Parallel channels were distance/speed limited (initially ~200 feet distance between channel and device was supported) because of the skew between the bus and tag cables. When a tag (e.g. ‘address out’) was received on one side, all of the bits of the data on the bus (e.g. device address) had to be valid at that moment. There were multiple types of parallel channels that evolved over the years to match differences or improvements to devices to increase data transfer rates. Byte Multiplex channels allowed several devices to perform data transfer at the same time, as each device could disconnect between bytes of data transfer, freeing up the cable for other devices to use. Selector channels were used with devices with higher data transfer rates, allowing the channel to remain connected to the device until the entire chain of CCWs was executed. Tape devices are typical examples of devices that benefitted from selector channels. Eventually Block Multiplexor channels emerged, and on these channels devices could disconnect only after the entire block of data for the command was transferred (instead of after each byte). When the device was ready to be serviced again it would present the ‘request in’ tag to indicate such. A second pair of data transfer tags (‘data in’ and ‘data out’) were introduced to reduce round trips and increase distance. The fourth type of parallel channel, Data Streaming channels, further utilized these new tags in a way that enabled removal of the interlock between the channel and control unit before the next byte of data could be transferred. Each byte was still acknowledged, but the control unit kept a count of responses to know how much had been transferred. Data streaming channels enabled distances between servers and attached devices to grow to ~400 feet.
We’ve certainly come a long way from these early parallel channels, but the progress occurred in multiple steps, and involved multiple transitions in both technology and architecture. As you see above, each time the protocol is enhanced to make data transfer between the server and devices less ‘chatty’, performance gains are realized and distance between servers and devices is able to be extended. Next time I’ll talk about the transition to ESCON, including the changes to the I/O architecture that came about around the same time. Hope you stay tuned!
Editors Note – Patty’s other blogs on this site can be found here, and here. Check back next Friday for the next installment.