Re: transactions vs interactive, was The Design of Design

John Levine wrote:

According to Scott Lurndal <slp53@pacbell.net>:

Among the many differences between IBM and DEC computers was that
IBM's had channels ...

 

Burroughs I/O subsystem offloaded even more than IBM channel
programs could provide.   It was fire and forget from the MCP
perspective (e.g. read a set of cards or read a bunch of sectors
was one instruction that initiated a high level operation (read
card/cards, print line/lines, read sector/sectors, write
sector/sectors, backspace tape, etc) and the hardware took care of
all the fiddley little details.

 
I can believe that Burroughs I/O was more flexible but IBM 360
channels could ran channel progarms that could be arbitrarily long and
had loops. If you wanted to write a channel program to read a dozen
cards or read all the records on a disk track, that wasn't hard. There
were even some self-modifying channel programs that were a pain to
virtualize on CP/67.

While IBM's channels did provide a lot of flexibility, it came at a
tremendous cost that, in the fullness of time, proved to be a bad
tradeoff.  I think it is unfair to compare IBM's mainframe
implementation to a DEC mini, but it is fair to compare them to the
other contemporous mainframe systems.  I can't speak to paper
peripherals, but I can about storage peripherals.

We have discussed some of the problems with CKD disks.  Others,
including at least Univac, Burroughs (both large and medium scale) and
CDC used disks with fixed block lengths. I don't know enough about
Honeywell, nor NCR to comment on those.  Sending a command to the
channel was straight forward. On the Univac, for example, you executed
a Load Function in Channel instruction to send a command to the
channel, followed by a Load input or Output channel with gave the
memory address and length of the data.  The actual function was
different depending upon the device, but was typically one or two words.

You mentioned reading all the records on a track.  With CKD, you had to
know how many records that was, and there was work by the channel
communicating with the disk controller for each record. With fixed
length blocks, you could just specify the number of blocks you wanted
in the initial command and would get interrupted when all of them had
been transferred.

With tape, I don't see an advantage in being able to read multiple
blocks at once, as if you had the memory to do that, it would have been
better to just write longer blocks to the tape and get better tape
untilization.

And, we have mentioned the bad decision to allow key searches on the
disk.  This persisted into the 1990s, since PDSs used key searches for
members.  A PDS with many members could tie up the channel for multiple
disk rotations at a time, which was only alleviated by the fast PDS
search capability, with, while it didn't speed up the (linear) search,
at least allowed the channel to be freed up during the search.

IBM tried to get away from CKD, supporting the fixed block 3370 for VM
and DOS, but supportoing it under MVS was to big a lift, and it died.
Today, of course, CKD (actually extended ECKD, which fixed some of the
problems) is actually emulated in the disk controller using actual
industry standard fixed block disks.


--
 - Stephen Fuld
(e-mail address disguised to prevent spam)