From: Del Cecchi on 25 Dec 2009 15:31
"Robert Myers" <rbmyersusa(a)gmail.com> wrote in message
On Dec 25, 4:07 am, Bill Todd <billt...(a)metrocast.net> wrote:
> Why try to use channel terminology to describe a configuration that
> doesn't really fit it? IIRC the XT (ISA) bus didn't support masters
> other than the host system: if so, then (at least from the hardware
> viewpoint) the host called the shots (as it does in the channel
> approach) but also handled the I/O devices (as it does not in the
> channel approach).
I wanted to elicit as specific an answer as I could, so I used a
concrete example. PCI/XT bus devices could do bus mastering, so far
as I know, but I'm not sure why it's relevant. It would have been not
all that difficult to have intercepted I/O going either way to the 32-
bit system and done whatever one cared to with it, so I'm still not
sure what a mainframe channel has, other than careful and expensive
engineering that pays far more attention to reliability than anything
available outside the world of mainframes.
Thanks for your explanations, which give me a much clearer picture of
the various choices.
Please note that mainframe channels were first used on S/360 which
came out in the mid 60's.
They have evolved considerably since then.
Perhaps you could discuss what the contemporary systems were doing at
the time? GE 60x, Sperry Univac, SDS? What was DEC building? PDP8?
PC's were not even a gleam in anyone's eye.
del (sorry for goofy attribution)
From: Del Cecchi on 25 Dec 2009 15:41
"Anne & Lynn Wheeler" <lynn(a)garlic.com> wrote in message
> hmy1 <hmy1(a)aol.com> writes:
>> IBM's System z (lastest mainframe brand name) I/O technology has
>> of value and is an industry standard (T11.org, FC-SB-4).
>> Just to mention a few differentiators from FCP:
> i've got lots of old email from the FCS mailing list about all the
> the pok channel engineers were causing ... trying to overlay
> half-duplex, end-to-end serialized paradigm on top of the underlying
> full-duplex asynchronous FCS.
> part of this was escon technology had been laying around pok,
> unannounced for possibly a decade (but used for mainframe channel
> paradigm was half-duplex, end-to-end serialization. one of the
> engineers took it, did some tweaking (which made it incompatible,
> full-duplex, etc). then he wanted to do a 800mbit version ... and we
> been involved in the FCS activity ... and managed to talk him into
> getting involved with FCS instead. Then the pok channel engineers
> involved in standardization activity (not so much on the basic
> ... but trying to overlay stuff on top of the underlying standard).
> alternative example was the serial copper, full-duplex asynchronous
> stuff that Hursley did (Harrier/9333) ... with effectively
> scsi commands. we spent some effort trying to get harrier morphed so
> that interoperated with FCS ... but in turned into "SSA" instead.
> referenceed here ... in old post related to ha/cmp & ha/cmp scaleup
> 40+yrs virtualization experience (since Jan68), online at home since
Lynn, you seem to have an allergy to ever mentioning Rochester,
Rochester engineers, or Rochester products. Who was this "RS6000
Engineer". And Pok had to be dragged kicking and screaming away from
their fixation on doing optics with LEDs instead of short wave lasers.
Rochester had independent line of systems (S/3, S/32, S/34, S/36,
S/38, AS/400 and follow ons). We also had independent line of CRT
Terminals, the 525x series, connected to the system by our own twinaxe
loop protocol that predated token ring. Rochester also had a line of
Key to disk systems and intelligent workstations 5208. Yet your posts
have an almost sovietesque aversion to mentioning them.
From: Anne & Lynn Wheeler on 25 Dec 2009 16:38
"Del Cecchi" <delcecchi(a)gmail.com> writes:
> Lynn, you seem to have an allergy to ever mentioning Rochester,
> Rochester engineers, or Rochester products. Who was this "RS6000
> Engineer". And Pok had to be dragged kicking and screaming away from
> their fixation on doing optics with LEDs instead of short wave lasers.
> Rochester had independent line of systems (S/3, S/32, S/34, S/36,
> S/38, AS/400 and follow ons). We also had independent line of CRT
> Terminals, the 525x series, connected to the system by our own twinaxe
> loop protocol that predated token ring. Rochester also had a line of
> Key to disk systems and intelligent workstations 5208. Yet your posts
> have an almost sovietesque aversion to mentioning them.
Most of the stuff is things that I did and/or at least had dealings with
(or maybe my wife).
for instance ... there was this 16-way 370 SMP thing ... which everybody
thought was just great. we had even convinced some of the processor
development 3033 engineers to work on it in their spare time ... which
is where I some of the blow-by-blow about 303x stuff. somewhere along
the way ... somebody informed the head of POK that it might be decades
before the POK favorite son operating system had 16-way support ... at
which point some number of people were invited to not visit pok again
(and the 3033 engineers directed to get their noses back to the
i had little to do with rochester ... did do a lot with pok and san jose
.... and was in austin for a time and did ha/cmp & some ha/cmp cluster
scaleup (before it got transferred and we were told we couldn't work on
anything with more than four processors). some related old email
the referenced rs6000 engineer then shows up as "secretary" for FCS
committee and managing the FCS standards documents.
there was some number of people that left IBM austin and joined dell
.... and some of the austin area computer meetings were hosted at dell.
one of the rochester ibm fellows that did work on s/38 showed up at
I believe I never even visited the rochester location.
from the days when my wife was in POK and charge of (mainframe)
loosely-coupled (cluster) architecture ... and responsible
for peer-coupled shared data architecture
she also was an inventor on IBM "ring" patent that I believe initially
shows up as S/1 "chat ring". In any case, "peer-coupled shared data" saw
very little uptake, except for IMS hot-standby ... until much later with
sysplex ... big reason that she didn't stay long in the position.
One of the guys in rochester that I had some dealings with worked on
RCHVM (virtual machine) systems and VNET support ... and had some
dealings when I was doing HSDT (high-speed data transport) activity
Most dealings that I had with rochester was that the made the chips for
the rs/6000 serial link adapter (SLA ... aka the full-duplex tweaked
escon ... 220mbits instead of 200mbits, etc). Since it was "proprietary"
and didn't connect to anything else ... tried to figure out how to use
it in "open system" environment. We talked NSC (HYPERChannel & later
other stuff) into providing an SLA interface in their high-speed router
.... however we had to make the chips available to them first. Turns out
that we couldn't just send chips from Rochester to Minneapolis ... they
had to be transferred from rochester to austin (at a 300% mark-up) and
then austin had to transfer them from austin to minneapolis (at another
300% markup ... now 900% markup). This was for something that they
thought we should be paying them for doing, as a favor for us.
i was involved in some early 801 iliad & romp stuff
the precursor to rs/6000 was the pc/rt. the pc/rt originally started out
as ROMP processor with pl8 and cpr for follow-on to displaywriter (aka
Austin was office product division ... OPD). When that was canceled,
they looked around and settled on selling it into the unix workstation
market instead. They got the company that had done the AT&T unix port to
the ibm/pc (for PC/IX) to do one for ROMP (aka pc/rt). misc. other posts
mentioning 801, romp, rios, iliad, etc
To: wheeler (as well as others)
From: <corporate NETMAP>
Date: 01/22/80 14:21:40
There are 2 new nodes that should be added to the network:
BCRCPS which is a 148 VM system located in Boca Raton connected to
BCR68A via a 4800 line.
RCHVM1 which is a 158AP VM system located in Rochester, Minn
connected to RCH648 via a 9.6 line
.... snip ...
The internal network was larger than the arpanet/internet from just
about the beginning until sometime late '85 or early '86 ... some
I did an edit macro that would take "structured" network notifications
and automatically do the correct thing ... post with some of the
structured notifications in '83 (when arpanet moved to internetworking
protocol and started to exceed 255 nodes ... and the internal network
exceeded 1000 nodes)
as well as list of corporate locations that had new/additional
nodes added during 1983.
Date: 02/21/80 06:23:27
From: <somebody in rochester>
Its been a L-O-N-G time, but I finally made it ! With this VMSG
I am announcing that I am again back on the NETWORK at a new node
in Rochester, Mn (GSD) named 'RCHVM1'. My userid is 'xxxxxx' (as
in Boulder). Please change all nickname files to reflect this
Its good to be "home".
.... snip ...
40+yrs virtualization experience (since Jan68), online at home since Mar1970
From: Anne & Lynn Wheeler on 25 Dec 2009 17:08
.... addenda ... in 1980 ... i wrote a bunch of mainframe software to
support (NSC) HYPERChannel use at corporate internal datacenters ... and
then tried to have a joint release (with NSC) of the software to
customers (NSC eventually had to recreate the stuff from scratch).
it appeared that major objection preventing me from releasing that
software ... was from the channel people in POK trying to get their
fiber technology out as ESCON (viewing hyperchannel as competition)
.... some possibly later involved in all the gorp of overlaying FICON on
top of FCS.
one of the disk engineers in san jose that I worked some with ... got
'78 patent on raid technology (predates "RAID" by nearly a decade).
However, I believe S/38 had the first ship of raid technology. S/38
treated all the available disks as one large pool ... simplifying a lot
of things ... common failure mode was single disk failure ... which in
common pool design, brought down the whole system. RAID was needed to
mask such single disk failures ... (from taking down the whole
infrastructure). However, s/38 then required full infrastructure backup
.... and full infrastructure restore ... to handle other kinds of
failure/recovery. s/38 configurations were somewhat notorious for taking
a long time for getting something back up and running ... since complete
restore could take a long time.
misc. past posts in this thread:
http://www.garlic.com/~lynn/2009s.html#18 Larrabee delayed: anyone know what's happening?
http://www.garlic.com/~lynn/2009s.html#20 Larrabee delayed: anyone know what's happening?
http://www.garlic.com/~lynn/2009s.html#22 Larrabee delayed: anyone know what's happening?
http://www.garlic.com/~lynn/2009s.html#23 Larrabee delayed: anyone know what's happening?
http://www.garlic.com/~lynn/2009s.html#29 channels, was Larrabee delayed: anyone know what's happening?
http://www.garlic.com/~lynn/2009s.html#30 Larrabee delayed: anyone know what's happening?
http://www.garlic.com/~lynn/2009s.html#31 Larrabee delayed: anyone know what's happening?
http://www.garlic.com/~lynn/2009s.html#32 Larrabee delayed: anyone know what's happening?
40+yrs virtualization experience (since Jan68), online at home since Mar1970
From: Stephen Fuld on 25 Dec 2009 17:36
Del Cecchi wrote:
> Perhaps you could discuss what the contemporary systems were doing at
> the time? GE 60x, Sperry Univac, SDS? What was DEC building? PDP8?
> PC's were not even a gleam in anyone's eye.
I can do some of that. But before I do, let me make clear that a lot of
what has loosely be called channel functionality is really implemented
not in the channel, but in the disk controller. Thus, search, for
example, is not available on channel attached tape systems.
So, let's start by saying that AFAIK no other vendor did CKD (the
functionality that allowed a lot of the ingenious but baroque
functionality) or things like it. It is generally regarded, even by
IBM, as a mistake, for a large number of reasons.
AFAIK, every other vendor, and even IBM with its Rochester designed
systems, and even VM and DOS/VS on the S/360 follow ons, supported disks
formatted into an "array" of fixed length blocks, though of course
different systems used different block lengths.
But other vendors did things like channels. Sperry/Univac, dating back
even further than the S/360 had channels, though despite the same name,
were different from what IBM called channels. For example, the 1108,
which was roughly contemporaneous with the S/360 had up to 16 channels
per CPU. Each had two cables, one for input, the other for output.
Each cable had 36 data lines (to correspond with the 36 bit words of the
1108, and a few control lines. They were "activated" by CPU
instructions; there were no "channel programs". But it took typically
only two to three instructions to initiate an I/O so this wasn't a
hardship. The channels supported scatter/gather as well as termination
by either an external interrupt (from the device) or based on a word
I believe that Burroughs had an I/O backplane, into which different
cards (called data link processors, or DLPs) could be placed. There
were different types of DLPs for different peripheral types.
CDC, had separate CPUs, called Peripheral Processors to do I/O.
I don't know about any others.
- Stephen Fuld
(e-mail address disguised to prevent spam)