Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!psuvax1!burdvax!sdcrdcf!CAM.UNISYS.COM!mrc
From: mrc@CAM.UNISYS.COM (McLean Research Center guest)
Newsgroups: comp.arch
Subject: Re: Horizontal pipelining
Message-ID: <388@sdcjove.CAM.UNISYS.COM>
Date: Mon, 16-Nov-87 12:14:35 EST
Article-I.D.: sdcjove.388
Posted: Mon Nov 16 12:14:35 1987
Date-Received: Thu, 19-Nov-87 01:56:34 EST
References: <201@PT.CS.CMU.EDU> <8801@utzoo.UUCP> <8758@shemp.UCLA.EDU> <11711@orchid.waterloo.edu>
Organization: Unisys McLean Research Center
Lines: 51
Keywords: multiple users
Summary: IBM -- DID know how, but just didnt bother

In article <11711@orchid.waterloo.edu>, atbowler@orchid.waterloo.edu (Alan T. Bowler [SDG]) writes:
> ...
> GCOS is perfectly happy to let a CPU be released serviced by the
> field engineer, and returned to use with the user's never seeing
> ...
> and Univac did it with the 1100 series.  IBM announced it several
> times, but until the Sierra series never figured out how to make
> the operating system handle it,...

Well, I must take exception:

IBM did it in the System/360-40V (a prototype), S/360-67 (production),
S/370-158-AP, S/370-158-MP, S/370-168-AP, S/370-168-MP (all 4 as production).

Of course, in the S/370s, they bollixed the I/O channel addressing scheme.

True, they never did generally release a true multi-CPU opsys in their
main product line.  DOS never would have had a chance of running multi-CPU;
OS/MFT (which became SVS) never would have had a chance, either;
OS/MVT (when it became MVS) could have had a chance, but they
made a political decision.

But, they did have a system which did it all, namely TSS/360 --> TSS/370.
TSS was strictly a DATbox/relocating/virtualmemory system, and the S360/67
fit it (or verse vica) beautifully.  TSS was even so open-structured that
it was ported to S/370 in about a year (calendar) and did everything that
it did before, except for a couple features designed-out of the S/370 boxes.

TSS was inherently n-plex:  the released version could handle 4 CPUs, 4 I/O
channel CONTROLLERS (that's what the left nibble of the two-byte I/O address
was really for), up to 16 channels per controller, understood channels as
logically standalone and switchable/shareable across/between controllers,
up to 16 memory frames as partitionable re-base-addressable reconfigurable.

The most-plex customer system installed for S/360 had 2CPUs, 3CCUs, 8 MUs (I
think).  The most-plex customer system installed for S/370 had 2CPUs (168-MP),
logically 2CCUs (really each CPU frame's imbedded channel set), logically
16? MUs (severable chunks within the CPU frames' imbedded memory).

The most-plex ever run, up in the Mohansic Lab, and then at Poughkeepsie
(914 bldg?)  is reputed to have been a 4x4x16 S/360-67.  And it was, as
some might say, a HUMMER!

Just for drill, consider the fact that a 2-CPU S/370-168-MP ran a throughput
of 2.1 to 2.25 over a 1-CPU system, depending on just what we gave it for
workload.

There ain't nothing new under the sun.

Regardz,
Ken