Many I/O tasks can be complex and require logic to be applied to the data to convert formats and other similar duties.
Channel architecture avoids this problem by processing some or all of the I/O task without the aid of the CPU by offloading the work to dedicated logic.
When I/O transfer is complete or an error is detected, the controller typically communicates with the CPU through the channel using an interrupt.
In earlier implementations, any error, no matter how small, required CPU intervention, and the overhead was, consequently, much higher.
A program-controlled interruption (PCI) is still used by certain legacy operations, but the trend is to move away from such PCIs, except where unavoidable.
A real game-changer, and this forced IBM to redesign its mainframes to provide similar channel capability and flexibility.
The 1965 CDC 6600 supercomputer utilized 10 logically independent computers called peripheral processors (PPs) and 12 simple I/O channels for this role.
The rationale for these devices is the same as for the original channel controllers, namely off-loading transfer, interrupts, and context switching from the main CPU.
The reference implementation of channel I/O is that of the IBM System/360 family of mainframes and its successors, but similar implementations have been adopted by IBM on other lines, e.g., 1410 and 7010, 7030, and by other mainframe vendors, such as Control Data, Bull (General Electric/Honeywell) and Unisys.
It is not merely a medium of communication, despite the name; it is a programmable device that handles all details of I/O after being given a list of I/O operations to carry out (the channel program).
This flexibility frees the CPU from the overhead of starting, monitoring, and managing individual I/O operations.
Channel I/O is not unlike the Direct Memory Access (DMA) of microcomputers, only more complex and advanced.
On large mainframe computer systems, CPUs are only one of several powerful hardware components that work in parallel.
Special input/output controllers (the exact names of which vary from one manufacturer to another) handle I/O exclusively, and these, in turn, are connected to hardware channels that also are dedicated to input and output.
In IBM ESA/390 terminology, a channel is a parallel data connection inside the tree-like or hierarchically organized I/O subsystem.
In System/390 I/O cages, channels either directly connect to devices which are installed inside the cage (communication adapter such as ESCON, FICON, Open Systems Adapter) or they run outside of the cage, below the raised floor as cables of the thickness of a thumb and directly connect to channel interfaces on bigger devices like tape subsystems, direct access storage devices (DASDs), terminal concentrators and other ESA/390 systems.
In IBM terminology, a multiplexer channel supports a number of concurrent interleaved slow-speed operations, each transferring one byte from a device at a time.
A selector channel supports one high-speed operation, transferring a block of data at a time.
A block multiplexer supports a number of logically concurrent channel programs, but only one high-speed data transfer at a time.
The device control unit will search the track to find the requested record.
In some cases, the system software has the option of updating the track or cylinder number and redriving the I/O operation without interrupting the application program.
[10] The operating system is responsible for translating these channel programs before executing them, and for this particular purpose the Input/Output Supervisor (IOS) has a special fast fix function which was designed into the OS Supervisor just for those "fixes" which are of relatively short duration (i.e., significantly shorter than "wall-clock time").
Here the virtual memory is page-fixed for the life of the application, rather than fixing and freeing around each I/O operation.
An alternative to long-term page fixing is moving the entire application, including all its data buffers, to a preferred area of main storage.
Even bootstrapping of the system, or Initial Program Load (IPL) in IBM nomenclature, is carried out by channels, although the process is partially simulated by the CPU through an implied Start I/O (SIO) instruction, an implied Channel Address Word (CAW) at location 0 and an implied channel command word (CCW) with an opcode of Read IPL, also at location 0.
The IPL Text then locates, loads and transfers control to the operating system's Nucleus.
It is capable of IPL-ing from a card deck, from a magnetic tape, or from a direct access storage device, (DASD), e.g., disk, drum.
The DASD (direct access storage device) initialization program, IBCDASDI, or the DASD initialization application, ICKDSF, places a wait state PSW and a dummy CCW string in the 24 bytes, should the device be designated for data only, not for IPL, after which these programs format the VTOC and perform other hard drive initialization functions.