Channel I/O

Channel I/O
Company type	Computer architecture component
Industry	Computing, Computer hardware
Founded	1957
Products	I/O channels, channel programs, channel controllers

In computing, channel I/O refers to a high-efficiency input/output (I/O) system architecture utilized across numerous computing platforms, notably mainframe computers. Historically, these channels were custom-built units known by various names such as channel, I/O processor, I/O controller, I/O synchronizer, or DMA controller.

Overview

Performing I/O operations often involves intricate logic for data transformation and format management. When such tasks are handled by the CPU, it can lead to inefficiencies because the CPU may remain idle while waiting for slower I/O devices, a scenario described as being 'I/O bound'.

Channel architecture mitigates this issue by delegating I/O processing to specialized hardware units. These channels are designed as logically autonomous entities equipped with sufficient control logic and storage to manage I/O independently. Some possess enough processing power to act as coprocessors—for example, the 7909 Data Channel used in IBM 7090/7094 systems—although most are less complex. Depending on the system design, channels utilize either CPU-addressable memory or internal hardware buffers. They connect to peripheral devices via standardized interfaces, enabling multiple channels to operate simultaneously.

Generally, the CPU initiates an I/O operation by sending a concise channel program—a set of instructions—to the channel, which then executes the I/O task autonomously unless program controlled interrupts (PCIs) are required for system-level functions such as program loading or demand paging.

Channels notify the CPU of completion or errors through interrupts. Since channels typically have direct access to main memory, they often function as direct memory access (DMA) controllers.

Contemporary channel implementations allow the channel processor to carry out entire channel programs without CPU involvement until either completion or a PCI occurs, substantially reducing CPU-channel communication and enhancing overall performance. Channels report various termination statuses indicating successful completion or errors, sometimes necessitating additional sensing operations. Certain controllers can automatically retry failed operations without CPU intervention. Earlier designs demanded CPU involvement for every error, increasing overhead. Although PCIs remain in use for some legacy operations, modern systems minimize their frequency except when essential.

History

The inception of channel I/O dates back to 1957 with the IBM 709 vacuum tube mainframe, whose Model 766 Data Synchronizer was the pioneering channel controller. Its transistor-based successor, the IBM 7090, featured two to eight 6-bit channels (the 7607) alongside a channel multiplexor (the 7606) capable of managing up to eight channels. Additionally, the 7090 and 7094 supported up to eight 8-bit channels using the 7909.

While IBM incorporated data channel commands and enabled command chaining on certain systems, most other manufacturers implemented channels that processed single records at a time. Some architectures, such as the GE-600 series, offered more sophisticated I/O designs.

Subsequently, the IBM System/360 and System/370 series integrated channel I/O across all models. Entry-level systems implemented channels in microcode running on the CPU itself, operating in either "CPU Mode" or "Channel Mode," where channel mode shared CPU cycles with other tasks. Larger configurations employed distinct physical channel hardware like the IBM 2860 Selector channel, IBM 2870 Byte multiplexor channel, and IBM 2880 Block multiplexor channel. In the 303x systems, channels were realized as separate channel directors housed within the same cabinet as the CPU.

Eventually, channel units evolved into embedded processors inside the CPU enclosure—often RISC processors or System/390 microprocessors executing specialized microcode—in IBM's CMOS mainframes.

The Amdahl Corporation took a different approach with System/370-compatible channels by introducing a single internal "C-Unit" that supported up to sixteen channels using uniform hardware adaptable to selector, byte multiplexor, or block multiplexor functions via maintenance commands. Systems could be equipped with two "C-Units" for a maximum of 32 channels. Each "C-Unit" functioned as a "shifting channel state processor," a dedicated finite-state machine updating channel states every CPU cycle. This architecture included integrated channel-to-channel adapters (CCAs), providing flexibility that influenced IBM to redesign its mainframes for similar capabilities.

Non-IBM commercial systems featuring channel architectures appeared early on platforms like the UNIVAC 490, CDC 1604, Burroughs B5000, UNIVAC 1107, and GE 635. Since then, channel controllers have become standard components in mainframe designs, offering significant advantages over smaller computing systems.

The 1965 CDC 6600 supercomputer employed ten peripheral processors (PPs) alongside twelve simple I/O channels. The PPs were adapted versions of CDC's early personal computers running operating system tasks. Unlike traditional DMA-capable channels, these I/O channels lacked direct memory access and interrupt capabilities; data transfers were orchestrated through synchronous instructions executed by PPs.

Introduced in 1981, SCSI emerged as an affordable alternative to IBM's Block Multiplexer Channel and evolved into widely adopted standards such as the Fibre Channel Protocol and Serial Attached SCSI.

In modern computing environments, channels exist as bus mastering peripheral devices like PCI-based direct memory access (DMA) controllers that offload data transfer and interrupt management from the CPU—continuing the original purpose behind channel controllers.

Channel controller technology has been condensed into single-chip solutions supporting multiple channels simultaneously; an example of this miniaturization is evident in their deployment within NeXT computers.

Description

The quintessential example of channel I/O implementation is found in IBM System/360 mainframes and their successors, with comparable architectures employed by IBM in other systems such as the 1410 and 7030, as well as by manufacturers like Control Data, Bull (GE/Honeywell), and Unisys.

In systems utilizing channel I/O, specialized hardware autonomously manages all input/output functions, independent of the central processor. The CPU generally uses a single instruction to initiate I/O operations by dispatching channel programs to this dedicated hardware. Once started, the I/O process operates independently until it either completes or triggers an interrupt that alerts the operating system.

A channel is a self-contained, programmable hardware unit responsible for coordinating I/O activities across multiple controllers or devices. Each channel program is designed for one device and consists of command sequences directed at the channel, controller, and device levels. After the operating system assembles these commands, a single instruction activates the channel program, which then executes the I/O tasks until finished.

Sophisticated channel programs may incorporate conditional branching and data verification, thereby relieving the CPU from overseeing I/O management. The dedicated channel hardware executes these operations more efficiently and concurrently with CPU processes. This advanced approach to I/O resembles Direct Memory Access (DMA) used in microcomputers but offers greater complexity and capability.

In large-scale mainframe environments, multiple processors function alongside specialized I/O controllers connected via dedicated channels. This design maximizes I/O throughput without compromising CPU performance—an essential factor for enterprise applications that demand intensive input/output processing and high data transfer rates.

Within IBM ESA/390 architectures, a channel represents a parallel data pathway within a layered I/O subsystem. Channels either connect internally to devices housed in I/O enclosures (such as ESCON or FICON adapters) or extend externally through cables to larger peripherals like tape libraries, DASDs, terminal concentrators, or even other ESA/390 systems.

Types of channels

Channels differ based on their capacity for simultaneous input/output operations and data transfer methods. According to IBM terminology, a multiplexer channel supports numerous interleaved low-speed transfers by moving data one byte at a time. In contrast, a selector channel handles a single high-speed operation by transferring entire blocks of data in one go. A block multiplexer allows multiple logically concurrent channel programs but restricts actual high-speed data transfers to one at any given moment.

Channels also vary in how they associate peripheral devices with storage buffers. In UNIVAC nomenclature, channels may be classified as internally specified index (ISI), where only one buffer and device are active simultaneously, or externally specified index (ESI), where the device itself determines buffer selection.

Channel program

Within IBM System/360 and subsequent systems, a channel program consists of a series of channel command words (CCWs) executed by the I/O channel subsystem. The operating system initiates this sequence using an SSCH (start sub-channel) instruction, allowing the CPU to continue other processing until an interrupt signals completion. Earlier IBM mainframes deployed separate physical channel units per channel; however, modern architectures utilize an independent RISC-based processor shared among multiple channels. The System/370 Extended Architecture replaced earlier SIO instructions with SSCH to enhance operational efficiency.

Channel I/O delivers substantial improvements in input/output efficiency. For instance, on IBM's Linux on IBM Z, formatting an entire DASD track requires only a single channel program invocation (one I/O instruction), although it comprises multiple CCWs (one per data block). This approach transfers workload to the dedicated I/O processor and frees the CPU to concentrate on application-level tasks.

Channel command words

A channel command word (CCW) serves as an instruction directed to the dedicated I/O channel processor, triggering actions such as "read," "write," or "sense" on connected peripherals. Given that all devices link through channels in these systems, every I/O operation relies on CCWs.

Operating systems and utility programs arrange CCWs into channel programs. These programs incorporate limited dynamic branching capabilities by utilizing status modifiers and "transfer-in-channel" (TIC) commands, allowing for adaptable and efficient management of I/O processes.

Chaining

IBM's CCWs are linked together to create a channel program. Specific bits within a CCW denote that the subsequent memory address holds another CCW belonging to the same sequence. The channel executes these CCWs consecutively until encountering an exception, a TIC command, or a CCW without chaining. Command chaining indicates that the following CCW initiates a new command, whereas data chaining signifies additional data associated with the current command, facilitating operations such as gather-writing and scatter-reading.

Self-modifying channel programs

Channel programs are capable of altering their execution flow dynamically based on data retrieved during processing. This technique is notably applied in OS/360 ISAM to enhance processing efficiency.

Channel program example

Consider an example where a disk record is read using a recorded key. With knowledge of the track and key, the device control unit searches for the desired record. The channel program comprises:

  SEEK             <cylinder/head number>
  SEARCH KEY EQUAL <key value>
  TIC              *-8 Loop back to SEARCH if not equal
  READ DATA        <buffer>

The TIC loops execution back to SEARCH until either a matching key is located or the track ends. Once found, the DASD controller directs the channel to bypass the TIC and perform the READ operation.

For blocked records—where multiple records exist per block and keys are sequential—the program adjusts as follows:

  SEEK                     <cylinder/head number>
  SEARCH KEY HIGH OR EQUAL <key value>
  TIC                      *-8 Loop back if key not high or equal
  READ DATA                <buffer>

If no matching record is found by track or cylinder end, the program concludes with a "no record found" status. System software may then update track or cylinder parameters and attempt I/O again without disrupting running applications.

Channel programs in virtual storage systems

Typically, channels function with real (physical) addresses, while channel programs reference virtual addresses. Prior to execution, the operating system translates these virtual addresses into real ones. The Input/Output Supervisor (IOS) offers a specialized fast fix service designed for brief address translations. During this process, pages containing I/O data are locked into real memory (page fixed), the channel program is duplicated with virtual addresses replaced by physical addresses, and once complete, pages are released.

Because fixing and releasing pages demand considerable CPU effort, some systems employ long-term page fixing to minimize CPU load by locking virtual memory for the duration of an application's execution. An example of this method is used by Db2.

Alternatively, applications along with their data buffers can be relocated into designated preferred main storage areas through specific SYSEVENTs within MVS/370 up to z/OS environments. This procedure involves swapping out the application from non-preferred storage and swapping it into preferred storage (SYSEVENT TRANSWAP), followed by marking it as non-swappable (SYSEVENT DONTSWAP). When the application terminates, the operating system issues SYSEVENT OKSWAP if necessary.

Booting via channel I/O

The process of system startup, known as Initial Program Load (IPL), is executed through channels, although the CPU partially emulates this by using implied instructions alongside channel command words (CCWs). The implied Read IPL CCW fetches the initial block from the designated IPL device into memory, triggering a channel program that loads the bootstrap loader, referred to as the IPL Text.

Following this, the IPL Text identifies and loads the operating system's Nucleus, subsequently handing over control. The Nucleus is responsible for system initialization and commencing standard OS functions.

This boot procedure remains independent of the device type, enabling startup from various media such as card decks, magnetic tapes, or direct access storage devices (DASD) like disks or drums. While the Read IPL command adapts its behavior according to the device, it guarantees uniform loading across all supported media.

For DASD controllers, executing the Read IPL command involves seeking cylinder 0, head 0, bypassing the track descriptor record, and processing it as a Read Data command. The IPL Text is located at cylinder 0, track 0, records 1 and 2. The volume label found in record 3 points to the Volume Table of Contents (VTOC), which outlines the disk’s structure and capacity.

Should an IPL be attempted on a device lacking IPL Text, the system transitions into a wait state. To prepare devices not intended for IPL, DASD initialization utilities such as IBCDASDI or ICKDSF insert a wait state PSW and a placeholder CCW sequence into the initial bytes before formatting the VTOC and completing other configuration tasks.

External links

IBM System/370 Principles Of Operation (GA22-7000-4), chapter on Input/Output Operations