4 ms·

The System/360 I/O channels are kind of like a DMA (direct memory access) controller, so I/O can happen in the background instead of making the CPU wait. The Ra

by kens 5y ago

The System/360 I/O channels are kind of like a DMA (direct memory access) controller, so I/O can happen in the background instead of making the CPU wait. The Raspberry Pi PIO is more of a programmable state machine for low-level I/O protocols. So they are kind of similar in that they offload I/O tasks from the main CPU. But they also act at different levels: a System/360 channel does something like reading a block of data from tape, while a PIO deals with individual up and down transitions on a line.

bogomipz 5y ago
Is this I/O channel architecture basically the same thing that makes mainframes so reliable even today? Might you or anyone else have any recommendations on mainframe I/O architecture evolution? I've tried to look it up in the past but without much success.
- chiph 5y ago
  They are reliable through exhaustive testing of components, plus error-checking, plus redundancy (on some models). What channels get you is high I/O throughput. Especially in 80 character long records The machines (were and maybe still) are optimized to run COBOL, and what COBOL programs are commonly used for is operations like "Read a record, use columns 50 thru 59 to add to a total, repeat until EOF. Then print the total formatted as $**9,999.99" So the faster you can read records in, the better. Channels also did buffering when reading from devices like tape drives that did not like to start/stop their motion a lot. So the channel controller would tell the tape drive to read "a few" records and hold them for when the CPU asked for them. Mechanically, the tape reel would slow to a stop and a vacuum column would hold excess tape. The inertia of the reel did not allow for sudden starts/stops and if you tried you'd snap the tape. Curious Marc has a video: https://www.youtube.com/watch?v=7Lh4CMz_Z6M https://www.youtube.com/watch?v=7Lh4CMz_Z6M
  - bogomipz 5y ago
    I believe that on many you could actually hot swap the connected and active I/O components and power them up and down as well, no? Thanks for the link. This is great. Cheers.
  - BXLE_1-1-BitIs1 5y ago
    In 360 a channel could connect to a number of control units that each connected to a number of devices. Early on, just one IO could run on a channel; so all other devices were locked out until the IO was performed (several details omitted). Early disk IO held the channel until the desired record came under the head. That was after the arm was positioned. 370 brought in rotational position sensing allowing other disk IO to take place. Later on, tapes also accommodated record positioning. Forward Space File came with 360. Remember though that these days tapes are often archived in a virtual tape library physically on disk, but processed with tape channel commands. Back in 360,control units that could handle simultaneous IOs appeared. They were connected to two channels.
- therealbilly 5y ago
  The Apple Macintosh IIfx had IOP's which I think were 6809's as I/O controllers. I believe they only worked in System 6 and were not used in System 7. Somebody mentioned that the Mac Quadra 950 had IOP's as well.

by kens 5y ago

bogomipz 5y ago

Is this I/O channel architecture basically the same thing that makes mainframes so reliable even today? Might you or anyone else have any recommendations on mainframe I/O architecture evolution? I've tried to look it up in the past but without much success.

chiph 5y ago
They are reliable through exhaustive testing of components, plus error-checking, plus redundancy (on some models). What channels get you is high I/O throughput. Especially in 80 character long records The machines (were and maybe still) are optimized to run COBOL, and what COBOL programs are commonly used for is operations like "Read a record, use columns 50 thru 59 to add to a total, repeat until EOF. Then print the total formatted as $**9,999.99" So the faster you can read records in, the better. Channels also did buffering when reading from devices like tape drives that did not like to start/stop their motion a lot. So the channel controller would tell the tape drive to read "a few" records and hold them for when the CPU asked for them. Mechanically, the tape reel would slow to a stop and a vacuum column would hold excess tape. The inertia of the reel did not allow for sudden starts/stops and if you tried you'd snap the tape. Curious Marc has a video: https://www.youtube.com/watch?v=7Lh4CMz_Z6M https://www.youtube.com/watch?v=7Lh4CMz_Z6M
- bogomipz 5y ago
  I believe that on many you could actually hot swap the connected and active I/O components and power them up and down as well, no? Thanks for the link. This is great. Cheers.
- BXLE_1-1-BitIs1 5y ago
  In 360 a channel could connect to a number of control units that each connected to a number of devices. Early on, just one IO could run on a channel; so all other devices were locked out until the IO was performed (several details omitted). Early disk IO held the channel until the desired record came under the head. That was after the arm was positioned. 370 brought in rotational position sensing allowing other disk IO to take place. Later on, tapes also accommodated record positioning. Forward Space File came with 360. Remember though that these days tapes are often archived in a virtual tape library physically on disk, but processed with tape channel commands. Back in 360,control units that could handle simultaneous IOs appeared. They were connected to two channels.
therealbilly 5y ago
The Apple Macintosh IIfx had IOP's which I think were 6809's as I/O controllers. I believe they only worked in System 6 and were not used in System 7. Somebody mentioned that the Mac Quadra 950 had IOP's as well.