Channel I/O
In
Overview
Many I/O tasks can be complex and require logic to be applied to the data to convert formats and other similar duties. In these situations, the simplest solution is to ask the
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. Channels are logically
A CPU typically designates a block of storage as, or sends, a relatively small channel program to the channel in order to handle I/O tasks, which the channel and controller can, in many cases, complete without further intervention from the CPU (exception: those channel programs which utilize 'program controlled interrupts', PCIs, to facilitate program loading, demand paging and other essential system tasks).
When I/O transfer is complete or an error is detected, the controller typically communicates with the CPU through the channel using an interrupt. Since the channel normally has direct access to the main memory, it is also often referred to as a direct memory access (DMA) controller.
In the most recent implementations, the channel program is initiated and the channel processor performs all required processing until either an ending condition or a program controlled interrupt (PCI). This eliminates much of the CPU—Channel interaction and greatly improves overall system performance. The channel may report several different types of ending conditions, which may be unambiguously normal, may unambiguously indicate an error or whose meaning may depend on the context and the results of a subsequent sense operation. In some systems an I/O controller can request an automatic retry of some operations without CPU intervention. 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.
History
The first use of channel I/O was with the IBM 709[2] vacuum tube mainframe, whose Model 766 Data Synchronizer was the first channel controller, in 1957. Its transistorized successor, the IBM 7090,[3] had two to eight 6-bit channels (the 7607) and a channel multiplexor (the 7606) which could control up to eight channels. The 7090 and 7094 could also have up to eight 8-bit channels with the 7909.
While IBM used data channel commands on some of its computers, and allowed command chaining on, e.g., the 7090, most other vendors used channels that dealt with single records. However, some systems, e.g., GE-600 series, had more sophisticated I/O architectures.
Later, the
Much later, the channels were implemented as an on-board processor residing in the same box as the CPU, generally referred to as a "channel processor", and which was usually a
Some of the earliest commercial non-IBM channel systems were on the
The 1965
SCSI introduced in 1981 as a low cost channel equivalent to the IBM Block Multiplexer Channel[5] is now ubiquitous in the form of Fibre Channel and Serial Attached SCSI.
Modern computers may have channels in the form of
Channel controllers have been made as small as single-chip designs with multiple channels on them, used in the NeXT computers for instance.
Description
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.,
.Computer systems that use channel I/O have special hardware components that handle all input/output operations in their entirety independently of the systems' CPU(s). The CPU of a system that uses channel I/O typically has only one
A channel is an independent hardware component that coordinates all I/O to a set of controllers or devices. 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).
Each channel may support one or more controllers and/or devices, but each channel program may only be directed at one of those connected devices. A channel program contains lists of commands to the channel itself and to the controller and device to which it is directed. Once the operating system has prepared a complete list of channel commands, it executes a single I/O machine instruction to initiate the channel program; the channel thereafter assumes control of the I/O operations until they are completed.
It is possible to develop very complex channel programs, including testing of data and conditional branching within that channel program. This flexibility frees the CPU from the overhead of starting, monitoring, and managing individual I/O operations. The specialized channel hardware, in turn, is dedicated to I/O and can carry it out more efficiently than the CPU (and entirely in parallel with the CPU). Channel I/O is not unlike the
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. There may be several CPUs and several I/O processors. The overall architecture optimizes input/output performance without degrading pure CPU performance. Since most real-world applications of mainframe systems are heavily I/O-intensive business applications, this architecture helps provide the very high levels of
In
Types of channels
Channels differ in the number and type of concurrent I/O operations they support. 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.
Channels may also differ in how they associate peripheral devices with storage buffers. In UNIVAC terminology, a channel may either be internally specified index (ISI), with a single buffer and device active at a time, or externally specified index (ESI), with the device selecting which buffer to use.
Channel program
A channel program is a sequence of channel command words (CCWs) that are executed by the I/O channel subsystem in the IBM System/360 and subsequent architectures. A channel program consists of one or more channel command words. The operating system signals the I/O channel subsystem to begin executing the channel program with an SSCH (start sub-channel) instruction. The central processor is then free to proceed with non-I/O instructions until interrupted. When the channel operations are complete, the channel interrupts the central processor with an I/O interruption. In earlier models of the IBM mainframe line, the channel unit was an identifiable component, one for each channel. In modern mainframes, the channels are implemented using an independent RISC processor, the channel processor, one for all channels. IBM System/370 Extended Architecture[6] and its successors replaced the earlier SIO (start I/O) and SIOF (start I/O fast release) machine instructions (System/360 and early System/370) with the SSCH (start sub-channel) instruction (ESA/370 and successors).
Channel I/O provides considerable economies in input/output. For example, on IBM's
Channel command words
A channel command word (CCW) is an
CCWs are organized into channel programs by the operating system, and I/O subroutine, a utility program, or by standalone software (such as test and diagnostic programs). A limited "branching" capability, hence a dynamically programmable capability, is available within such channel programs, by use of the "status modifier" channel flag and the "transfer-in-channel" CCW.
Chaining
IBM CCWs are chained to form the channel program. Bits in the CCW indicates that the following location in storage contains a CCW that is part of the same channel program. The channel program normally executes sequential CCWs until an exception occurs, a Transfer-in-Channel (TIC) CCW is executed, or a CCW is executed without chaining indicated. Command chaining tells the channel that the next CCW contains a new command. Data chaining indicates that the next CCW contains the address of additional data for the same command, allowing, for example, portions of one record to be written from or read to multiple data areas in storage (gather-writing and scatter-reading).[7]
Self-modifying channel programs
Channel programs can modify their own operation during execution based on data read. For example, self modification is used extensively in OS/360 ISAM.[8]
Channel program example
The following example[9] reads a disk record identified by a recorded key. The track containing the record and the desired value of the key is known. The device control unit will search the track to find the requested record. In this example <> indicate that the channel program contains the storage address of the specified field.
SEEK <cylinder/head number> SEARCH KEY EQUAL <key value> TIC *-8 Back to search if not equal READ DATA <buffer>
The TIC (transfer in the channel) will cause the channel program to branch to the SEARCH command until a record with a matching key (or the end of the track) is encountered. When a record with a matching key is found the DASD controller will include Status Modifier in the channel status, causing the channel to skip the TIC CCW; thus the channel program will not branch and the channel will execute the READ command.
The above example is correct for unblocked records (one record per block). For blocked records (more than one record per block), the recorded key must be the same as the highest key within that block (and the records must be in key sequence), and the following channel program would be utilized:
SEEK <cylinder/head number> SEARCH KEY HIGH OR EQUAL <key value> TIC *-8 Back to search if not high or equal READ DATA <buffer>
If the dataset is allocated in tracks, and the end of the track is reached without the requested record being found the channel program terminates and returns a "no record found" status indication. Similarly, if the dataset is allocated in cylinders, and the end of the cylinder is reached without the requested record being found the channel program terminates and returns a "no record found" status indication. 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.
Channel programs in virtual storage systems
This section may be weighted too heavily toward only one aspect of its subject.(May 2021) |
On most systems channels operate using real (or physical) addresses, while the channel programs are built using virtual addresses.[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"). Pages containing data to be used by the I/O operation are locked into real memory, or page fixed. The channel program is copied and all virtual addresses are replaced by real addresses before the I/O operation is started. After the operation completes, the pages are unfixed.
As page fixing and unfixing is a CPU-expensive process long-term page fixing is sometimes used to reduce the CPU cost. Here the virtual memory is page-fixed for the life of the application, rather than fixing and freeing around each I/O operation. An example of a program that can use long-term page fixing is Db2.
An alternative to long-term page fixing is moving the entire application, including all its data buffers, to a preferred area of main storage. This is accomplished by a special SYSEVENT in MVS/370 through z/OS operating systems, wherein the application is, first, swapped-out from wherever it may be, presumably from a non-preferred area, to swap and page external storage, and is, second, swapped-in to a preferred area (SYSEVENT TRANSWAP). Thereafter, the application may be marked non-swappable by another special SYSEVENT (SYSEVENT DONTSWAP). Whenever such an application terminates, whether normally or abnormally, the operating system implicitly issues yet another special SYSEVENT on the application's behalf if it has not already done so (SYSEVENT OKSWAP).
Booting with channel I/O
Even
To load a system, the implied Read IPL CCW reads the first block of the selected IPL device into the 24-byte data area at location 0, the channel continues with the second and third double words, which are CCWs, and this channel program loads the first portion of the system loading software elsewhere in main storage. The first double word contains a PSW which, when fetched at the conclusion of the IPL, causes the CPU to execute the IPL Text (bootstrap loader) read in by the CCW at location 8. The IPL Text then locates, loads and transfers control to the operating system's Nucleus. The Nucleus performs or initiates any necessary initialization and then commences normal OS operations.
This IPL concept is device-independent. It is capable of IPL-ing from a card deck, from a magnetic tape, or from a
DASD controllers accept the X'02' command, seek to cylinder X'0000' head X'0000', skip to the index point (i.e., just past the track descriptor record (R0)) and then treat the Read IPL command as if it were a Read Data (X'06') command. Without this special DASD controller behavior, device-independent IPL would not be possible. On a DASD, the IPL Text is contained on cylinder X'0000', track X'0000', and record X'01' (24 bytes), and cylinder X'0000', track X'0000', and record X'02' (fairly large, certainly somewhat more than 3,000 bytes). The volume label is always contained on cylinder X'0000', track X'0000', and block X'03' (80 bytes). The volume label always points to the VTOC, with a pointer of the form HHHH (that is, the VTOC must reside within the first 65,536 tracks). The VTOC's Format 4 DSCB defines the extent (size) of the VTOC, so the volume label only needs a pointer to the first track in the VTOC's extent, and as the Format 4 DSCB, which describes the VTOC, is always the very first DSCB in the VTOC, HHHH also points to the Format 4 DSCB.
If an attempt is made to IPL from a device that was not initialized with IPL Text, the system simply enters a wait state. 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
See also
- Autonomous peripheral operation
- Booting
- Bus and Tag
- Execute Channel Program
- GEC 4000 series
- GCOS (operating system)
- I2O
- IBM System z9
- IBM System z10
- Initial program load
- Intel 8089
- System/360
- UNIVAC 1110
- z/Architecture
References
- ^ "IBM 3705 Communications Controller" (PDF). Datapro Reports on Data Communications. McGraw-Hili. April 1990 [May 1987]. Retrieved April 3, 2022.
Cycle-stealing is a form of interrupt in which the component needing access to memory or to the processor takes control for an entire machine cycle.
- ^ "IBM Archives: 709 Data Processing System". 03.ibm.com. 23 January 2003. Retrieved 2014-01-22.
- ^ "IBM Archives: 7090 Data Processing System (continued)". 03.ibm.com. 1958-12-30. Retrieved 2014-01-22.
- ^ A Guide to the IBM 3033 Processor Complex, Attached Processor Complex, and Multiprocessor Complex of System/370 (PDF) (Fifth ed.). IBM. April 1979. p. 3. GC20-1859-4.
- ^ SCSI Forum. Technology Forums. October 1986. p. 202.
* Similarities to Mainframe, * System 360 Block Multiplexed Channel, *Trend to Microcomputers
- ^ IBM System/370 Extended Architecture Principles of Operation, SA22-7085-0
- ^ IBM Corporation (1968). Student Text: Introduction to IBM System/360 Architecture (PDF). IBM Corporation. p. 22.
- .
- ^ IBM Corporation (1969). IBM System/360 Component Descriptions: 2314 Direct Access Storage Facility and 2844 Auxiliary Storage Control (PDF). IBM Corporation. p. 50.2. Archived from the original (PDF) on 2011-03-22.
- ^ IBM Corporation (1978). OS/VS2 MVS Overview (PDF). pp. 8–12. Archived from the original (PDF) on 2011-03-16.
- ^ See System/370 Principles of Operation, GA22–7000–4, pp 54—55, Initial Program Loading; System/370 Extended Architecture is quite similar, although XA utilizes an "implied" Start Subchannel (SSCH) instead of an "implied" Start I/O.
Notes
- ^ a b Some microcoded channels ran by cycle stealing[1] rather than with completely independent hardware.
- ^ Typically the specification of the interface includes both the signals and the external cabling.
- ^ Using explicit tests of channel status and the instructions
- 70 IAN
- Input to A from Channel d
- 71 IAM
- Input (A) words to m from channel d
- 72 OAN
- Output from A to channel d
- 73 OAM
- Output (A) words from m to channel d
- 74 ACN
- Activate channel d
- 75 DCN
- Disconnect channel d
- 76 FAN
- Function (A) on channel d
- 77 FNC
- Function m on channel d