Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

The ICL 2900

1,661 views
Skip to first unread message

Quadibloc

unread,
Jan 22, 2017, 6:49:34 PM1/22/17
to
I had been interested in finding out about the ICL 1900, because it was a
computer with a 24-bit word.

There are some manuals for it on Bitsavers now, but where I first found
information about it was on a different site.

I happened to glance at a Bible, in the Revised Standard Version, which had small illustrations in with the text, and which was also unusual in that some parts were in smaller type and in three columns, while most of the text was in two.

At the start was a note that the book had been typeset by an I.C.T. 1500 computer.

I looked it up, and found that it was a copy of the RCA 301, made under license.

But that led me to look at other items about the history of ICT and ICL. And then I learned that the ICL 2900 was a computer designed as a successor to the series of machines which was based on the RCA Spectra computers.

A computer designed to be better than the IBM 360, due to using more advanced concepts of design, sounded interesting.

So I did a web search, and found two documents on Fujitsu's web site in PDF
format.

One was a book, "The ICL 2900 Series", by J. K. Buckle.

Another was an issue of the ICL Technical Journal - Volume 7, Number 2,
November 1990.

The latter was typeset conventionally - but I noticed that the former, the buck
by J. K. Buckle, was done on some form of the IBM Selectric Composer.

So we come full circle as far as typesetting is concerned.

In any event, the ICL Technical Journal describes an SX series of machines,
which was claimed to be more efficient than an Amdahl 5800 series machine
despite being made with the same hardware technology from Fujitsu.

As to the ICL 2900 architecture, it was a lot like the Burroughs machines, but
it used IBM 360-like datatypes, not a 48-bit word like they did, and instead of
being focused on one language (ALGOL 60), it was designed to work equally well
with any higher-level language.

John Savard

Bob Eager

unread,
Jan 22, 2017, 7:24:41 PM1/22/17
to
Loosely based on the Manchester MU5. It had a single accumulator and a
single index register, was stack and descriptor based, and had caching on
the 'business' end of the stack to compensate for the lack of registers.
An easy machine to write compilers for, as I know!

The accumulator was variable size - 32, 64 and 128 bits. One could choose
the size when it had something loaded into it. Certain multiplication and
division operations would alter the size, as might be expected.

Full 32 bit addressing, segmented and paged. 1kB pages and 256kB
segments. Half the segments were 'public' (shared between processes) and
half were 'private' (process-local).

Ring based security with 16 Access Control Levels via a special register
(ACR).

It could also assume two other 'personalities', and switch betwqeen them.
One was the ICL 1900 (the previous 24 bit system). The other was the
English Electric System 4, so not dissimilar to a 360.

If anyone wants to know more, please ask. I worked on one for several
years, and helped in the development of a home-brew operating system. I
also ended up patching the microcode to get round a hardware design
error. For more details on that, see:

http://www.bobeager.uk/anecdotes.html

and scroll down a bit.

I am currently working on a 2900 emulator.


--
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
http://www.mirrorservice.org

Anonymous

unread,
Jan 22, 2017, 8:22:35 PM1/22/17
to
Quadibloc wrote:

> I had been interested in finding out about the ICL 1900, because it was a
> computer with a 24-bit word.

See:

http://www.ourcomputerheritage.org/ict_15.htm

http://www.icl1900.co.uk

and

http://www.findlayw.plus.com/ICL1900/index.html

The last of these contains the second (and vastly better, not being based
on a Zurich original)
ICL 1900 Pascal compiler.

BTW, Bob, Delwyn Holroyd at TNMoC, Bletchley Park, has a MT I donated that
contains 2900 Pascal.
There are some problems reading the object files due to read errors that
Delwyn thinks may be correctable,
but I have managed to reconstruct seemingly valid source texts of the
compiler, diagnostic system,
and related SCL macros.


Bob Eager

unread,
Jan 22, 2017, 8:25:17 PM1/22/17
to
Thanks - I know Delwyn, and I'll ask him when I see him next (probably in
the pub!)

Anonymous

unread,
Jan 22, 2017, 8:25:49 PM1/22/17
to
Anonymous <no_e...@invalid.invalid> wrote:
> Quadibloc wrote:
>
>> I had been interested in finding out about the ICL 1900, because it was a
>> computer with a 24-bit word.
>
> See:
>
> http://www.ourcomputerheritage.org/ict_15.htm
>
> http://www.icl1900.co.uk
>
> and
>
> http://www.findlayw.plus.com/ICL1900/index.html
>

This [{#%}] s/w keep losing my id!

The quoted message was from moi, namely:

--
Bill Findlay




Bill Findlay

unread,
Jan 22, 2017, 8:29:56 PM1/22/17
to
Bob Eager <news...@eager.cx> wrote:
> On Mon, 23 Jan 2017 01:22:33 +0000, Anonymous wrote:
>
>> Quadibloc wrote:
>>
>>> I had been interested in finding out about the ICL 1900, because it was
>>> a computer with a 24-bit word.
>>
>> See:
>>
>> http://www.ourcomputerheritage.org/ict_15.htm
>>
>> http://www.icl1900.co.uk
>>
>> and
>>
>> http://www.findlayw.plus.com/ICL1900/index.html
>>
>> The last of these contains the second (and vastly better, not being
>> based on a Zurich original)
>> ICL 1900 Pascal compiler.
>>
>> BTW, Bob, Delwyn Holroyd at TNMoC, Bletchley Park, has a MT I donated
>> that contains 2900 Pascal.
>> There are some problems reading the object files due to read errors that
>> Delwyn thinks may be correctable,
>> but I have managed to reconstruct seemingly valid source texts of the
>> compiler, diagnostic system, and related SCL macros.
>
> Thanks - I know Delwyn, and I'll ask him when I see him next (probably in the pub!)


If you want the 2900 sources, let me know.

--
Bill Findlay

Stephen Wolstenholme

unread,
Jan 23, 2017, 9:55:13 AM1/23/17
to
In the 1970s I was working on IBM 360 compatible ICL 4/70. Later I
worked on the ICL 2900 and then it's replacement S39. On the customer
sites I was working on the ICL systems were faster than IBM systems
doing the same jobs but the IBM machines were more reliable. An
interesting thing I noticed was that most customers went for neither
ICL or IBM when the systems were replaced.

Steve

--
Neural Network Software for Windows http://www.npsnn.com

albi...@gmail.com

unread,
Jan 23, 2017, 11:23:01 AM1/23/17
to
I worked on the 2900 and later, the 3900 in the 80s, - initially at a large chain store, but later as part of a team which ported the Software-AG products (ADABAS and Natural) from the IBM-370 type machines to the ICL kit. As a result we were one of the few customers to work with S3 and SFL (ICLs "assembly language").

That was a load of fun. I'd enjoy playing with that again if an emulator ever happened.

Of course, getting the OS and software might be problematic.

Bob Eager

unread,
Jan 23, 2017, 12:55:39 PM1/23/17
to
On Mon, 23 Jan 2017 08:22:59 -0800, albiorix wrote:

> I worked on the 2900 and later, the 3900 in the 80s, - initially at a
> large chain store, but later as part of a team which ported the
> Software-AG products (ADABAS and Natural) from the IBM-370 type machines
> to the ICL kit. As a result we were one of the few customers to work
> with S3 and SFL (ICLs "assembly language").

I used SFL quite a lot. I even have a manual somewhere.

> That was a load of fun. I'd enjoy playing with that again if an
> emulator ever happened.
>
> Of course, getting the OS and software might be problematic.

I would be using the homebrew one.

If you look at the website, you'll see we were doomed to use VME/K.
Rolling 13 week MTBF of the system was about 20 hours. With our own
system, it was 2000 hours.

Bob Eager

unread,
Jan 23, 2017, 12:56:32 PM1/23/17
to
On Mon, 23 Jan 2017 14:54:44 +0000, Stephen Wolstenholme wrote:

> In the 1970s I was working on IBM 360 compatible ICL 4/70. Later I
> worked on the ICL 2900 and then it's replacement S39. On the customer
> sites I was working on the ICL systems were faster than IBM systems
> doing the same jobs but the IBM machines were more reliable. An
> interesting thing I noticed was that most customers went for neither ICL
> or IBM when the systems were replaced.

Reliability (hardware wise) was dreadful. A lot of the stuff in our
operating system was recovery from transient errors.

Peter Flass

unread,
Jan 23, 2017, 3:40:05 PM1/23/17
to
Stephen Wolstenholme <st...@easynn.com> wrote:
> In the 1970s I was working on IBM 360 compatible ICL 4/70. Later I
> worked on the ICL 2900 and then it's replacement S39. On the customer
> sites I was working on the ICL systems were faster than IBM systems
> doing the same jobs but the IBM machines were more reliable. An
> interesting thing I noticed was that most customers went for neither
> ICL or IBM when the systems were replaced.

Where did they go?

--
Pete

Bob Eager

unread,
Jan 23, 2017, 4:18:50 PM1/23/17
to
We went for DEC; they won the tender.

IBM also bid but had an incompetent sales team.

Bob Eager

unread,
Jan 23, 2017, 5:11:03 PM1/23/17
to
On Mon, 23 Jan 2017 22:05:05 +0000, Huge wrote:

> On 2017-01-23, Bob Eager <news...@eager.cx> wrote:
>> On Mon, 23 Jan 2017 13:40:03 -0700, Peter Flass wrote:
>>
>>> Stephen Wolstenholme <st...@easynn.com> wrote:
>>>> In the 1970s I was working on IBM 360 compatible ICL 4/70. Later I
>>>> worked on the ICL 2900 and then it's replacement S39. On the customer
>>>> sites I was working on the ICL systems were faster than IBM systems
>>>> doing the same jobs but the IBM machines were more reliable. An
>>>> interesting thing I noticed was that most customers went for neither
>>>> ICL or IBM when the systems were replaced.
>>>
>>> Where did they go?
>>
>> We went for DEC; they won the tender.
>>
>> IBM also bid but had an incompetent sales team.
>
> There's a sentence I never thought I'd see; an incompetent IBM sales
> team!

I think it was their first account. It was wide open and should have been
easy for them.

hanc...@bbs.cpcn.com

unread,
Jan 23, 2017, 5:17:56 PM1/23/17
to
On Monday, January 23, 2017 at 9:55:13 AM UTC-5, Stephen Wolstenholme wrote:

> In the 1970s I was working on IBM 360 compatible ICL 4/70. Later I
> worked on the ICL 2900 and then it's replacement S39. On the customer
> sites I was working on the ICL systems were faster than IBM systems
> doing the same jobs but the IBM machines were more reliable. An
> interesting thing I noticed was that most customers went for neither
> ICL or IBM when the systems were replaced.

Back then some customers had emotional prejudices which influenced
their selection of computer. As we know, many customers felt, "you
never get fired for buying IBM", and went that way, even if the
price/performance/quality might have been better with alternatives.
On the other hand, there were some customers who disliked IBM for
various reasons, and refused to consider an IBM machine.

David Wade

unread,
Jan 23, 2017, 6:09:42 PM1/23/17
to
In general you could get better price/performance elsewhere. IBM's
technique was to sell to high management, and convince them. The
technical sales teams were not used to having to work.

I remember when the company I worked for was looking at buying a new
machine around the same time as ICL2900 appeared, IBM suggested that we
run on-line during the day and batch overnight. Went down like a lead
balloon with management.

We were Honeywell and bought a Honeywell L66/10 and did run batch and
on-line at the same time, albeit after a memory upgrade...

Dave
G4UGM

Bob Eager

unread,
Jan 23, 2017, 6:31:56 PM1/23/17
to
Our 2900 was really very underpowered. It could just about run one batch
stream and struggled to support 32 on-line users at the same time. There
were some terrible short cuts in the operating system (e.g. "If in doubt,
crash")

When we changed to the homebrew system, the MTBF increased 100-fold. It
also supported two batch streams and 48 on-line users.

Stephen Wolstenholme

unread,
Jan 24, 2017, 4:47:40 AM1/24/17
to
On Mon, 23 Jan 2017 13:40:03 -0700, Peter Flass
It varied. Of the ones I stayed in contact with, one went with
Honeywell but is now back with IBM, one went with Univac and then
Fujitsu. The customer site where I worked the longest is now a car
park!

Peter Flass

unread,
Jan 24, 2017, 9:02:36 AM1/24/17
to
IMO DEC was getting into the same league just before the end. The equipment
was about as reliable, the software was good and covered a great number of
areas customers wanted. Field service was excellent. Sales were OK, but it
was still much of "do it yourself". That's what makes Dec's demise that
much sadder.

--
Pete

Bob Eager

unread,
Jan 24, 2017, 9:09:36 AM1/24/17
to
Yes, we got a VAXcluster (the base CPU power of an 8800, running SMP, was
a bit under the IBM offering, so they chucked in a couple of 8200s). In
fact, since it was on VMS 4.6, it couldn't do SMP anyway, and didn't for
years.

jmfbahciv

unread,
Jan 24, 2017, 9:43:36 AM1/24/17
to
DEC's customers wanted "do it yourself". That's why they bought DEC
instead of IBM. IBM didn't allow cusotmers to tweak anything. So
DEC sold the hardware, providing the monitor software and other
OS "tools" so that the customer could develope or run whatever
they wanted. They could also build or buy other kinds of hardware
and include the software support in the monitor and CUSPs because
we shipped the sources. Compuserv, ADP, ORNL and First Data all had
their own tweaks which were applicable to their business (but
not to other kinds of computing).

Then the -20 happened...

/BAH

jmfbahciv

unread,
Jan 24, 2017, 9:43:36 AM1/24/17
to
Bob Eager wrote:
> On Mon, 23 Jan 2017 14:54:44 +0000, Stephen Wolstenholme wrote:
>
>> In the 1970s I was working on IBM 360 compatible ICL 4/70. Later I
>> worked on the ICL 2900 and then it's replacement S39. On the customer
>> sites I was working on the ICL systems were faster than IBM systems
>> doing the same jobs but the IBM machines were more reliable. An
>> interesting thing I noticed was that most customers went for neither ICL
>> or IBM when the systems were replaced.
>
> Reliability (hardware wise) was dreadful. A lot of the stuff in our
> operating system was recovery from transient errors.

Hardware was always dreadful back then. It was up to the software to
deal with it and make the system work well despite the hardware
limitations.

/BAH

jmfbahciv

unread,
Jan 24, 2017, 9:43:36 AM1/24/17
to
Bob Eager wrote:
> On Mon, 23 Jan 2017 22:05:05 +0000, Huge wrote:
>
>> On 2017-01-23, Bob Eager <news...@eager.cx> wrote:
>>> On Mon, 23 Jan 2017 13:40:03 -0700, Peter Flass wrote:
>>>
>>>> Stephen Wolstenholme <st...@easynn.com> wrote:
>>>>> In the 1970s I was working on IBM 360 compatible ICL 4/70. Later I
>>>>> worked on the ICL 2900 and then it's replacement S39. On the customer
>>>>> sites I was working on the ICL systems were faster than IBM systems
>>>>> doing the same jobs but the IBM machines were more reliable. An
>>>>> interesting thing I noticed was that most customers went for neither
>>>>> ICL or IBM when the systems were replaced.
>>>>
>>>> Where did they go?
>>>
>>> We went for DEC; they won the tender.
>>>
>>> IBM also bid but had an incompetent sales team.
>>
>> There's a sentence I never thought I'd see; an incompetent IBM sales
>> team!
>
> I think it was their first account. It was wide open and should have been
> easy for them.
>
IBM sales people could be arrogant because they didn't believe they had
any competition.

/BAH

Bob Eager

unread,
Jan 24, 2017, 10:34:47 AM1/24/17
to
Well, no. The reliabity of our DEC stuff was good. And the reliability of
that machine's immediate predecessor was a lot better too.

Bob Eager

unread,
Jan 24, 2017, 10:35:38 AM1/24/17
to
These two (women) were not arrogant, just inexperienced.

Scott Lurndal

unread,
Jan 24, 2017, 11:06:23 AM1/24/17
to
jmfbahciv <See....@aol.com> writes:
>Peter Flass wrote:

>>
>> IMO DEC was getting into the same league just before the end. The equipment
>> was about as reliable, the software was good and covered a great number of
>> areas customers wanted. Field service was excellent. Sales were OK, but it
>> was still much of "do it yourself". That's what makes Dec's demise that
>> much sadder.
>>
>DEC's customers wanted "do it yourself". That's why they bought DEC
>instead of IBM. IBM didn't allow cusotmers to tweak anything.

I'm sorry - but it was quite common for IBM customers to
tweek the OS. Significantly in many cases. I don't doubt that
many also had custom block-mux channels for various purposes.

Anne & Lynn Wheeler

unread,
Jan 24, 2017, 12:44:09 PM1/24/17
to

Bob Eager <news...@eager.cx> writes:
> Yes, we got a VAXcluster (the base CPU power of an 8800, running SMP, was
> a bit under the IBM offering, so they chucked in a couple of 8200s). In
> fact, since it was on VMS 4.6, it couldn't do SMP anyway, and didn't for
> years.

old reference to announce of "real" VMS SMP ("DEC Stalks Big Game with
Symmetrical VMS")
http://www.garlic.com/~lynn/2007.html#email880329

old reference with decade of vax sales, sliced&diced by year, model, etc
(8800, 30-1986, 170-1987) http://www.garlic.com/~lynn/2002f.html#0

We had started IBM HA/CMP project with RS/6000
http://www.garlic.com/~lynn/subtopic.html#hacmp

... including working with some of the "open system" RDBMS vendors, old
reference to Jan1992 meeting in ellison's conference room on cluster
scaleup http://www.garlic.com/~lynn/95.html#13

that had VMS/cluster support in their same source base ... to ease port,
I did API for global lock manager that emulated the VMS/cluster
semantics. The implementation also benefited from list that the RDBMS
vendors had about what VMS/cluster could have done better.

Then at ACM SIGOPS conference, I got in dustup with Jim Gray ... a
decade earlier, I had worked with Jim at San Jose Research on the
original SQL/relational implementation
http://www.garlic.com/~lynn/submain.html#systemr

the dust-up was over whether you could do high-availability with
"commodity" systems (at the time he was working for DEC DBMS). Then when
DEC DBMS was sold to Oracle, he took a sabbatical ... and then shows up
as head of Microsoft San Francisco Research. I got my "revenge" when he
shows up on stage with CEO of Microsoft announcing microsoft
high-availability on intel platforms.

As I've mentioned before, within a few weeks of the Jan1992 Ellison
meeting, cluster scaleup was transferred, announced as IBM supercomputer
for technical/scientific *ONLY* (we had also been working with national
labs on cluster scaleup uses), and we were told we couldn't work on
anything with more than four processors. Contributing was that the
mainframe DB2 group were complaining if I was allowed to go ahead, it
would be at least 5yrs ahead of what they were doing.

--
virtualization experience starting Jan1968, online at home since Mar1970

Anne & Lynn Wheeler

unread,
Jan 24, 2017, 1:17:17 PM1/24/17
to
sc...@slp53.sl.home (Scott Lurndal) writes:
> I'm sorry - but it was quite common for IBM customers to
> tweek the OS. Significantly in many cases. I don't doubt that
> many also had custom block-mux channels for various purposes.

re:
http://www.garlic.com/~lynn/2017.html#58 The ICL 2900

that got a lot more difficult with the OCO-wars (ibm stop providing
source). in the wake of various legal actions, ibm has the 23jun1969
"unbundling" announcement ... starting to charge for software,
maintenance, SE services, etc
http://www.garlic.com/~lynn/submain.html#unbundle

... however, IBM managed to make the case that kernel software should
still be free. during the FS period (was completely different than
360/370 and was completely replace 360/370), 370 efforts were being
shutdown. The lack of 370 offerings during the FS period is credited
with giving clone processor makers market foothold
http://www.garlic.com/~lynn/submain.html#futuresys

when FS imploded, there was a mad rush to get stuff back into the 370
pipelines ... that contributed to decision to release a bunch of 370
stuff I had been doing all during the FS period (I would also
periodically ridicule FS activities, which wasn't exactly career
enhancing).

In the morph of CP67 to VM370 there was lots of stuff dropped that I had
been doing back to time I was undergraduate. I then migrated a bunch of
the stuff to VM370 and one of my hobbies was providing production
enhanced operating systems for internal data centers ... some old email
http://www.garlic.com/~lynn/2006v.html#email731212
http://www.garlic.com/~lynn/2006w.html#email750102
http://www.garlic.com/~lynn/2006w.html#email750430

at the time "csc/vm" was running on couple hundred systems. A lot of my
stuff was picked up for vm370 release 3. However, the rise of clone
processors also motivated the decision to transition to charging for
kernel software ... and bunch of my stuff (kernel reorg for SMP, but not
SMP support itself, redo of paging & virtual memory support, and dynamic
adaptive resource management) was selected as guinea pig
http://www.garlic.com/~lynn/subtopic.html#fairshare
http://www.garlic.com/~lynn/subtopic.html#wsclock
http://www.garlic.com/~lynn/subtopic.html#smp

IBM went thru transition period ... that previous kernel software was
still free, but increasingly amounts were charged for ... until switched
to all kernel software was priced. Then came the "OCO-wars" where source
was no longer shipped. Part of the IBM argument was that customer
changes inhibited moving customers to new versions of software and
hardware models (possibly even software that was increasingly difficult
to run on clone processors).

trivia: TYMSHARE started offering their (vm370) CMS-based online
computer conferencing to (IBM mainframe user group) SHARE for free as
VMSHARE in Aug1976. The VMSHARE archives are here
http://vm.marist.edu/~vmshare/

which includes some amount of customer discussions about the OCO-wars
... some past posts referencing VMSHARE archive OCO-war discussions.
http://www.garlic.com/~lynn/2004p.html#5 History of C
http://www.garlic.com/~lynn/2004p.html#21 need a firewall
http://www.garlic.com/~lynn/2007f.html#67 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007k.html#15 Data Areas Manuals to be dropped
http://www.garlic.com/~lynn/2007u.html#8 Open z/Architecture or Not
http://www.garlic.com/~lynn/2007u.html#9 Open z architecture and Linux questions
http://www.garlic.com/~lynn/2008r.html#66 OCO, documentation, support from IBM-Main, etc
http://www.garlic.com/~lynn/2011g.html#29 Congratulations, where was my invite?
http://www.garlic.com/~lynn/2012j.html#20 Operating System, what is it?
http://www.garlic.com/~lynn/2012j.html#30 Can anybody give me a clear idea about Cloud Computing in MAINFRAME ?
http://www.garlic.com/~lynn/2012j.html#31 How smart do you need to be to be really good with Assembler?
http://www.garlic.com/~lynn/2013m.html#55 'Free Unix!': The world-changing proclamation made 30 years ago today
http://www.garlic.com/~lynn/2013o.html#45 the nonsuckage of source, was MS-DOS, was Re: 'Free Unix!
http://www.garlic.com/~lynn/2014.html#19 the suckage of MS-DOS, was Re: 'Free Unix!
http://www.garlic.com/~lynn/2014m.html#35 BBC News - Microsoft fixes '19-year-old' bug with emergency patch
http://www.garlic.com/~lynn/2015d.html#59 Western Union envisioned internet functionality

Anne & Lynn Wheeler

unread,
Jan 24, 2017, 1:39:00 PM1/24/17
to
hanc...@bbs.cpcn.com writes:
> Back then some customers had emotional prejudices which influenced
> their selection of computer. As we know, many customers felt, "you
> never get fired for buying IBM", and went that way, even if the
> price/performance/quality might have been better with alternatives.
> On the other hand, there were some customers who disliked IBM for
> various reasons, and refused to consider an IBM machine.

http://www.garlic.com/~lynn/2017.html#59 The ICL 2900

I had co-worker at IBM Research that left and was doing a lot of
consulting work in silicon valley. For a long time, he had major chip
design customer ... working for the Senior VP for Engineering (that had
started using cp67/cms as young silicon valley engineer in the 60s). He
had done port of AT&T C compiler to vm370/cms with a lot of 370
performance optimizations and ported a lot of UCB chip design tools.

He was then doing ethernet support ... for connecting SGI graphics
terminals to backup 370 "server". The IBM salesman came by and asked him
what he was doing. The IBM salesman then told him that he should do
token-ring support instead ... or he might find that mainframe service
wouldn't be as timely as it had been in the past. I then got an hour
phone call that involved a lot of four letter words. The next morning
the senior VP of Engineering held press conference to announce that they
were moving off IBM mainframes to sun servers.

Then there was a lot of internal task-forces looking at technical
reasons that chip industry was moving off IBM mainframes ... totally
ignoring the salesman issue.

We saw something similar from the communication group with internal
politics (sna, vtam, token-ring, etc) ... recent post mentioning
internal politics preventing us from bidding on NSFNET (precursor to
modern internet).
http://www.garlic.com/~lynn/2017.html#47 Putting The Times's First Email Address to Bed
other past posts
http://www.garlic.com/~lynn/subnetwork.html#nsfnet

also for various reasons the original mainframe TCP/IP product appeared
to be significantly crippled (possibly to make sure that sna/vtam was
faster). I then did the changes to support RFC1044 ... and in some tests
at cray research between 4341 and cray ... demonstrated sustained
channel media throughput using only modest amount of 4341 CPU (possibly
500 times improvement in bytes moved per instruction executed)
http://www.garilc.com/~lynn/subnetwork.html#rfc1044

Rich Alderson

unread,
Jan 24, 2017, 2:45:26 PM1/24/17
to
Anne & Lynn Wheeler <ly...@garlic.com> writes:

> Bob Eager <news...@eager.cx> writes:

>> Yes, we got a VAXcluster (the base CPU power of an 8800, running SMP, was
>> a bit under the IBM offering, so they chucked in a couple of 8200s). In
>> fact, since it was on VMS 4.6, it couldn't do SMP anyway, and didn't for
>> years.

> old reference to announce of "real" VMS SMP ("DEC Stalks Big Game with
> Symmetrical VMS")
> http://www.garlic.com/~lynn/2007.html#email880329

Which was greeted with hoots of laughter from the (sadly moribund) 36-bit DEC
customers, who had SMP on the PDP-10 architecture nearly a decade earlier. :-(

--
Rich Alderson ne...@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

hanc...@bbs.cpcn.com

unread,
Jan 24, 2017, 4:35:10 PM1/24/17
to
On Monday, January 23, 2017 at 6:09:42 PM UTC-5, g4ugm wrote:

> In general you could get better price/performance elsewhere. IBM's
> technique was to sell to high management, and convince them. The
> technical sales teams were not used to having to work.

In terms of hardware, the other companies generally offered
a better deal in terms of price/performance.

However, in terms of support, IBM generally was superior.

In my personal experience with employers utilizing IBM, Burroughs,
Wang, and Univac hardware, the superior support provided by IBM far
outweighed the superior hardware by the competition. Indeed,
one employer had an IBM on third-party lease (which IBM hated),
so technically we weren't even an IBM customer. None the less,
we still received valuable support from IBM.

We found that IBM employees were far better trained and supported
than employees of the competitors. For hardware issues, spare
parts were readily at hand, even for older machines, and they
quickly brought in experts to fix difficult problems. The
Univac and Burroughs people were really nice folks, but they
just didn't have the training or resources.

In terms of exaggerated claims to make a sale, we found Burroughs,
Univac, and Wang did that plenty, too.

hanc...@bbs.cpcn.com

unread,
Jan 24, 2017, 4:37:39 PM1/24/17
to
On Tuesday, January 24, 2017 at 9:43:36 AM UTC-5, jmfbahciv wrote:

> Hardware was always dreadful back then. It was up to the software to
> deal with it and make the system work well despite the hardware
> limitations.

What is "back then" Our S/360-40 generally was extremely reliable
in the late 1970s, when it was technically obsolete.

Our Univac 90/30 was clearly a "lightweight" in terms of durability
and mechanical reliability.

hanc...@bbs.cpcn.com

unread,
Jan 24, 2017, 4:43:03 PM1/24/17
to
On Tuesday, January 24, 2017 at 9:43:36 AM UTC-5, jmfbahciv wrote:

> IBM sales people could be arrogant because they didn't believe they had
> any competition.

In the early years of System/360, IBM had tremendous sales. Likewise
in the postwar era with tabulating machines. However, beyond those
two relatively limited time frames, IBM always had competition in
various ways. Before WW II IBM had to convince customers of the
benefits of automation, despite the high costs of machines, cards,
and skilled operators. After S/360, IBM had to competitors who
offered a better price. Further, IBM had several delays in
delivering S/360 software and hardware, which cost it business and
reputation. By S/370 days, there was plug compatible competition
and then mini-computer competition.

IBM's S/3x series had heavy mini-computer competition. Personally,
I saw a lot more Wang, Data General, and DEC out there than S/3x.

Anne & Lynn Wheeler

unread,
Jan 24, 2017, 5:18:55 PM1/24/17
to
Rich Alderson <ne...@alderson.users.panix.com> writes:
> Which was greeted with hoots of laughter from the (sadly moribund) 36-bit DEC
> customers, who had SMP on the PDP-10 architecture nearly a decade earlier. :-(

http://www.garlic.com/~lynn/2017.html#60 The ICL 2900

I periodically mention that Charlie had invented compare&swap when he
was working on CP67 fine-grain kernel multiprocessing locking at the
science center (came up with "compare&swap" because CAS are Charlie's
initials)
http://www.garlic.com/~lynn/subtopic.html#545tech

in the initial morph from CP67 to VM370 lots of my stuff was dropped
(back to my days as undergraduate) ... but also SMP support.

we had a number of projects to put SMP support into VM370 ... thus my
upthread comment about including kernel reorg for SMP ... but not actual
SMP support itself.

however the kernel reorg stuff was included as part of my "charged-for"
resource manager (as well as bunch of my other stuff) ... during the
transition period, older kernel code and hardware support would still be
free ... but could charge for new (non-hardware) support kernel
software. The problem with shipping SMP support in VM370 Release 4 (for
free) was that the kernel reorged needed for SMP support was already
part of my charged for kernel add-on. The eventual resolution was to
moved nearly 90% of the code from my charged for kernel add-on into the
free kernel base (w/o changing the price for my kernel add-on).
http://www.garlic.com/~lynn/subtopic.html#fairshare
http://www.garlic.com/~lynn/subtopic.html#wsclock

also, the initial effort to get compare&swap added to 370 architecture
was rebuffed, the POK favorite son operating system people saying that
test&set (from 360) days was more than adequate. The 370 architecture
owners said that to justify compare&swap for 370 ... uses other than
just kernel SMP locking was required ... thus was born the descriptions
(still in appendix of principles of operation) for use by large
multi-thread applications (like large DBMS transaction systems). In the
80s, you start to see other plaforms implementing compare&swap (or
instructions with similar semantics) for large multi-thread commercial
applications.
http://www.garlic.com/~lynn/subtopic.html#smp

Bob Eager

unread,
Jan 24, 2017, 5:19:27 PM1/24/17
to
On Tue, 24 Jan 2017 14:45:25 -0500, Rich Alderson wrote:

> Anne & Lynn Wheeler <ly...@garlic.com> writes:
>
>> Bob Eager <news...@eager.cx> writes:
>
>>> Yes, we got a VAXcluster (the base CPU power of an 8800, running SMP,
>>> was a bit under the IBM offering, so they chucked in a couple of
>>> 8200s). In fact, since it was on VMS 4.6, it couldn't do SMP anyway,
>>> and didn't for years.
>
>> old reference to announce of "real" VMS SMP ("DEC Stalks Big Game with
>> Symmetrical VMS")
>> http://www.garlic.com/~lynn/2007.html#email880329
>
> Which was greeted with hoots of laughter from the (sadly moribund)
> 36-bit DEC customers, who had SMP on the PDP-10 architecture nearly a
> decade earlier. :-(

We did too. Our 2900 had it on our homebrew operating system. It worked
well, once I'd worked out how to do the inter-CPU control (I had to
reverse engineer the microcode to get a register spec). I didn't writye
the code, but there were model-specific issues.

The guy who wrote *that* SMP code was later hired by DEC (VMS
Engineering). Guess what he worked on.

Quadibloc

unread,
Jan 24, 2017, 5:23:38 PM1/24/17
to
On Tuesday, January 24, 2017 at 3:19:27 PM UTC-7, Bob Eager wrote:

> The guy who wrote *that* SMP code was later hired by DEC (VMS
> Engineering). Guess what he worked on.

Hmm. When it comes to the VAX, "steal from the best" seems to have applied both
ways...

John Savard

Bob Eager

unread,
Jan 24, 2017, 6:01:39 PM1/24/17
to
It'll be interesting if I ever get my 2900 emulator to do two CPUs.

(note: they weren't called CPUs; they were called OCPs - Order Code
Processors)

Jon Elson

unread,
Jan 24, 2017, 6:33:03 PM1/24/17
to
Interesting. I don't know so much about the smaller ones, but we did know
that the larger models (/50 and /65) were pretty sensitive to power
disturbances. The 360/50 at Washington University had an uptime of MAYBE 5
hours. When they upgraded to a 360/65, it seemed to do better. They rented
a Dranetz analyzer and quickly found a correlation between system crashes
and power disturbances. We used to have really ROTTEN power here, due to
crummy underground cables. Too late for the /50 and /65, they finally
discovered shielded cable in the late 1970's and the power problems largely
went away. (The old plain rubber-covered cable was pulled into buried
conduits that leaked groundwater, so the cables with 4160 V AC on them were
partially immered in dirty water, and the corona degraded the rubber. The
cables would flash over for a few weeks before going to catastrophic
failure, and you could see the fluorescent lights flicker all the time.)
Later, the industry moved to shielded cable that had an expanded copper
screen over the main insulation, then covered with a thin outer cover. This
got rid of the electric field on the outside of the cable, and stopped the
corona degradation of the insulation. Some cable somewhere on campus used
to fail every 1-2 months before, I suspect a bunch of the first shielded
cables are still in the ground 40+ years later.

So, anyway, they were able to correlate at least 50% of the system crashes
with a disturbance reported by the Dranetz. The bought a big DPP (Digital
Power Products) system with isolation transformers and breaker panels, but
these could not get rid of actual dropouts in the mains voltages.

The larger 360's, at least, had "converter inverters" that converted 208 V
3-phase mains power to 300 V DC, and then inverted that to 120 V 2500 Hz
sine-wave power, to run all the power supplies around the computer. The
individual supplies had minimal energy storage, and the converter inverter
had a bank of "computer grade" caps in it, but only gave a few milliseconds
of holdup time. So, the system was pretty susceptible to crummy power.
Some other locations that had similar machines didn't seem to suffer this
trouble, as their power was apparently more stable.

370's put in motor generator sets that really isolated the machine from
momentary dips.

Jon

jmfbahciv

unread,
Jan 25, 2017, 8:56:30 AM1/25/17
to
Rich Alderson wrote:
> Anne & Lynn Wheeler <ly...@garlic.com> writes:
>
>> Bob Eager <news...@eager.cx> writes:
>
>>> Yes, we got a VAXcluster (the base CPU power of an 8800, running SMP, was
>>> a bit under the IBM offering, so they chucked in a couple of 8200s). In
>>> fact, since it was on VMS 4.6, it couldn't do SMP anyway, and didn't for
>>> years.
>
>> old reference to announce of "real" VMS SMP ("DEC Stalks Big Game with
>> Symmetrical VMS")
>> http://www.garlic.com/~lynn/2007.html#email880329
>
> Which was greeted with hoots of laughter from the (sadly moribund) 36-bit
DEC
> customers, who had SMP on the PDP-10 architecture nearly a decade earlier.
:-(
>
VMS management tried to get Husvedt(sp?) to plan and do SMP on the VAX.
He was sent to JMF and TW to find out about the solutions, problems,
and what JMF/TW would have done if they could do it over. The fucking
idiot got an immediate NIH attitude and left the meeting swearing that
VMS would NEVER have SMP. So that's why it was implemented too late.

/BAH

jmfbahciv

unread,
Jan 25, 2017, 8:56:30 AM1/25/17
to
You had PDP-10s? Reliability of any hardware was good only if PMs
were religiously done according to FS recommendations. Even then,
the hardware could suck big. Systems should be up and running 24/7
but that was never accomplished back then. The CMs (corrective
maintenance) were usually minimal but only if the PMs (preventive
maintenance) had been done regularly.

Mechanical things and power fluctuations along with environmental
vagaries created many headaches and down times.

/BAH

jmfbahciv

unread,
Jan 25, 2017, 8:56:30 AM1/25/17
to
That was later. I was thinking about ( and should have written)
late 60s and early 70s.

/BAH

jmfbahciv

unread,
Jan 25, 2017, 8:56:30 AM1/25/17
to
Bob Eager wrote:
> On Tue, 24 Jan 2017 14:45:25 -0500, Rich Alderson wrote:
>
>> Anne & Lynn Wheeler <ly...@garlic.com> writes:
>>
>>> Bob Eager <news...@eager.cx> writes:
>>
>>>> Yes, we got a VAXcluster (the base CPU power of an 8800, running SMP,
>>>> was a bit under the IBM offering, so they chucked in a couple of
>>>> 8200s). In fact, since it was on VMS 4.6, it couldn't do SMP anyway,
>>>> and didn't for years.
>>
>>> old reference to announce of "real" VMS SMP ("DEC Stalks Big Game with
>>> Symmetrical VMS")
>>> http://www.garlic.com/~lynn/2007.html#email880329
>>
>> Which was greeted with hoots of laughter from the (sadly moribund)
>> 36-bit DEC customers, who had SMP on the PDP-10 architecture nearly a
>> decade earlier. :-(
>
> We did too. Our 2900 had it on our homebrew operating system. It worked
> well, once I'd worked out how to do the inter-CPU control (I had to
> reverse engineer the microcode to get a register spec). I didn't writye
> the code, but there were model-specific issues.

Kewl. How many CPUs did you run? Did you have any problems with
configurations? PDP-10s only had 2 ports on each disk drive so
designing configurations so that the drives (diskpacks) could be available
100% if a CPU was off-line.
>
> The guy who wrote *that* SMP code was later hired by DEC (VMS
> Engineering). Guess what he worked on.

VMS Engineering didn't have DEC's SMP experts available; they
did have people who had worked with JMF but none of those
were involved in the initial design, specifications or implementation.

/BAH

Bob Eager

unread,
Jan 25, 2017, 12:15:29 PM1/25/17
to
On Wed, 25 Jan 2017 13:56:14 +0000, jmfbahciv wrote:

>> We did too. Our 2900 had it on our homebrew operating system. It worked
>> well, once I'd worked out how to do the inter-CPU control (I had to
>> reverse engineer the microcode to get a register spec). I didn't writye
>> the code, but there were model-specific issues.
>
> Kewl. How many CPUs did you run? Did you have any problems with
> configurations? PDP-10s only had 2 ports on each disk drive so
> designing configurations so that the drives (diskpacks) could be
> available 100% if a CPU was off-line.

This system wasn't built in a very conventional way. (what I describe is
the P series, not the later S series)

The central component was the Store Multiple Access Unit (SMAC. This
contained the memory (full ECC). It had four ports; two of those were for
attaching OCPs. The other two were for attaching Store Access Units
(SACs). Each SAC had eight trunks, and a trunk was attached to a
controller. Typical controllers were General Peripheral Controller (GPC)
- used for card reader, card punch, printer, OPER (operator station) and
tape drives; DFC (Disc File Controller) - for, obviously, exchangeable
disks; SFC (Sectored File Controller) - fixed head disk, drum-like; CLC
(Communications Link Controller) - for comms. We had a PDP-11 attached to
the GPC to interface with our network; homebrew software in ther,
obviously. The 'ports' on the controllers were called 'streams'.

So there weren't any dual-ported peripherals; OCPs could talk to both
SACS, so it was symmetrical.

(I hasten to add that the system was developed at the University of
Edinburgh; I just got involved with soem interesting bits)

>> The guy who wrote *that* SMP code was later hired by DEC (VMS
>> Engineering). Guess what he worked on.
>
> VMS Engineering didn't have DEC's SMP experts available; they did have
> people who had worked with JMF but none of those were involved in the
> initial design, specifications or implementation.

Perhaps he didn't go to VMS Engineering - I just assumed he would have.
His name is in the microfiched sources though!

Charlie Gibbs

unread,
Jan 25, 2017, 12:47:38 PM1/25/17
to
On 2017-01-24, hanc...@bbs.cpcn.com <hanc...@bbs.cpcn.com> wrote:

> In terms of exaggerated claims to make a sale, we found Burroughs,
> Univac, and Wang did that plenty, too.

You bet. All too often in my Univac days, a salesman would walk in
and say, "Celebration! I just got the ABC account! All we have to
do is give them X, Y, Z..." We techies would - after an appropriate
moment of stunned silence - reply: "You said WHAT?!"

The first time we ate a man-year on a project, I swore that if it
ever happened again I'd be gone. Not only did it happen again,
it was the same salesman who did it. And yes, I was gone - although
I was hired back to come in evenings and finish the project.

--
/~\ cgi...@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!

Rich Alderson

unread,
Jan 25, 2017, 3:19:32 PM1/25/17
to
jmfbahciv <See....@aol.com> writes:

> Bob Eager wrote:

>> Well, no. The reliabity of our DEC stuff was good. And the reliability of
>> that machine's immediate predecessor was a lot better too.

> You had PDP-10s? Reliability of any hardware was good only if PMs
> were religiously done according to FS recommendations. Even then,
> the hardware could suck big. Systems should be up and running 24/7
> but that was never accomplished back then. The CMs (corrective
> maintenance) were usually minimal but only if the PMs (preventive
> maintenance) had been done regularly.

> Mechanical things and power fluctuations along with environmental
> vagaries created many headaches and down times.

Barb,

At Stanford's Low Overhead Timesharing Systems (LOTS), the academic computing
facility where I spent 7 wonderful years, we did not allow FS to do PM except
in the break between academic quarters, because it was unfair to students who
needed the systems up to do their coursework and research to have it down for
4 hours every month. We ran 4 KL-10s with 1 RP06 and 1 RP07 each (until the
RA81s and HSC50 clustering came along in TOPS-20 6.0) on a 24x7 schedule for
10 weeks at a time, and saw fewer hardware issues than the other Stanford sites
who did allow monthly PM.

Rich Alderson

unread,
Jan 25, 2017, 3:29:33 PM1/25/17
to
When Barb said "DEC's SMP experts", she was referring to the wizards from the
PDP-10 side of the house (the Large Computer Group). Your guy might very well
have gone into VMS Engineering, but might not have been allowed^Wassigned to
work on the VMS SMP implementation.

hanc...@bbs.cpcn.com

unread,
Jan 25, 2017, 5:39:14 PM1/25/17
to
On Tuesday, January 24, 2017 at 6:33:03 PM UTC-5, Jon Elson wrote:

> Interesting. I don't know so much about the smaller ones, but we did know
> that the larger models (/50 and /65) were pretty sensitive to power
> disturbances. The 360/50 at Washington University had an uptime of MAYBE 5
> hours. When they upgraded to a 360/65, it seemed to do better. They rented
> a Dranetz analyzer and quickly found a correlation between system crashes
> and power disturbances. We used to have really ROTTEN power here, due to
> crummy underground cables. Too late for the /50 and /65, they finally
> discovered shielded cable in the late 1970's and the power problems largely
> went away. (The old plain rubber-covered cable was pulled into buried
> conduits that leaked groundwater, so the cables with 4160 V AC on them were
> partially immered in dirty water, and the corona degraded the rubber. The
> cables would flash over for a few weeks before going to catastrophic
> failure, and you could see the fluorescent lights flicker all the time.)
> Later, the industry moved to shielded cable that had an expanded copper
> screen over the main insulation, then covered with a thin outer cover. This
> got rid of the electric field on the outside of the cable, and stopped the
> corona degradation of the insulation. Some cable somewhere on campus used
> to fail every 1-2 months before, I suspect a bunch of the first shielded
> cables are still in the ground 40+ years later.

The NYC subway system is _now_ sensitive to power fluctuations as
the trains are all-electronic and thus sensitive. The older trains
used electro-mechanical controls which could accommodate a wide range
of voltage variations. Ironically, the modern motors are AC which are
supposedly more reliable but the control systems are sensitive.

Bob Eager

unread,
Jan 25, 2017, 6:40:39 PM1/25/17
to
On Wed, 25 Jan 2017 15:29:32 -0500, Rich Alderson wrote:

> Bob Eager <news...@eager.cx> writes:
>
>> On Wed, 25 Jan 2017 13:56:14 +0000, jmfbahciv wrote:
>
>>>> The guy who wrote *that* SMP code was later hired by DEC (VMS
>>>> Engineering). Guess what he worked on.
>
>>> VMS Engineering didn't have DEC's SMP experts available; they did have
>>> people who had worked with JMF but none of those were involved in the
>>> initial design, specifications or implementation.
>
>> Perhaps he didn't go to VMS Engineering - I just assumed he would have.
>> His name is in the microfiched sources though!
>
> When Barb said "DEC's SMP experts", she was referring to the wizards
> from the PDP-10 side of the house (the Large Computer Group). Your guy
> might very well have gone into VMS Engineering, but might not have been
> allowed^Wassigned to work on the VMS SMP implementation.

As I said, his name was prominent in the code last time I looked.

Andrew Swallow

unread,
Jan 25, 2017, 6:50:02 PM1/25/17
to
On 25/01/2017 22:39, hanc...@bbs.cpcn.com wrote:
> The NYC subway system is _now_ sensitive to power fluctuations as
> the trains are all-electronic and thus sensitive. The older trains
> used electro-mechanical controls which could accommodate a wide range
> of voltage variations. Ironically, the modern motors are AC which are
> supposedly more reliable but the control systems are sensitive.

The electronics will have to run from batteries.

To filter out spikes the charging circuit may have to be

Rail AC -> small electric motor with fly wheel mechanically connected to
DC generator
DC generator wired to batteries through smoothing circuit (capacitors
and coils)

Peter Flass

unread,
Jan 26, 2017, 8:41:16 AM1/26/17
to
Bob Eager <news...@eager.cx> wrote:
> On Wed, 25 Jan 2017 13:56:14 +0000, jmfbahciv wrote:
>
>>> We did too. Our 2900 had it on our homebrew operating system. It worked
>>> well, once I'd worked out how to do the inter-CPU control (I had to
>>> reverse engineer the microcode to get a register spec). I didn't writye
>>> the code, but there were model-specific issues.
>>
>> Kewl. How many CPUs did you run? Did you have any problems with
>> configurations? PDP-10s only had 2 ports on each disk drive so
>> designing configurations so that the drives (diskpacks) could be
>> available 100% if a CPU was off-line.
>
> This system wasn't built in a very conventional way. (what I describe is
> the P series, not the later S series)
>
> The central component was the Store Multiple Access Unit (SMAC. This
> contained the memory (full ECC). It had four ports; two of those were for
> attaching OCPs. The other two were for attaching Store Access Units
> (SACs). Each SAC had eight trunks, and a trunk was attached to a
> controller. Typical controllers were General Peripheral Controller (GPC)
> - used for card reader, card punch, printer, OPER (operator station) and
> tape drives; DFC (Disc File Controller) - for, obviously, exchangeable
> disks; SFC (Sectored File Controller) - fixed head disk, drum-like; CLC
> (Communications Link Controller) - for comms. We had a PDP-11 attached to
> the GPC to interface with our network; homebrew software in ther,
> obviously. The 'ports' on the controllers were called 'streams'.

Sounds like the way the GE-645 was designed.

>
> So there weren't any dual-ported peripherals; OCPs could talk to both
> SACS, so it was symmetrical.
>
> (I hasten to add that the system was developed at the University of
> Edinburgh; I just got involved with soem interesting bits)
>
>>> The guy who wrote *that* SMP code was later hired by DEC (VMS
>>> Engineering). Guess what he worked on.
>>
>> VMS Engineering didn't have DEC's SMP experts available; they did have
>> people who had worked with JMF but none of those were involved in the
>> initial design, specifications or implementation.
>
> Perhaps he didn't go to VMS Engineering - I just assumed he would have.
> His name is in the microfiched sources though!
>
>



--
Pete

jmfbahciv

unread,
Jan 26, 2017, 8:43:46 AM1/26/17
to
WOW! Maybe I'm biased because I was in DEC machine rooms. We were always
the first ones to get the new hardware. And we were also FS' first
site for all the gear. We just knew how to get work done in a mess. ;-)
Getting around a hardware glitch until FS could fix it was second
nature for us. Same thing was true with software glitches. When
we were working on a new development cycle of the monitor, system
crashes would occur often, where "often" could be every 5 minutes
to every hour. As the production cycle aged, the crashes became
fewer/day.

/BAH

jmfbahciv

unread,
Jan 26, 2017, 8:43:47 AM1/26/17
to
Bob Eager wrote:
> On Wed, 25 Jan 2017 13:56:14 +0000, jmfbahciv wrote:
>
>>> We did too. Our 2900 had it on our homebrew operating system. It worked
>>> well, once I'd worked out how to do the inter-CPU control (I had to
>>> reverse engineer the microcode to get a register spec). I didn't writye
>>> the code, but there were model-specific issues.
>>
>> Kewl. How many CPUs did you run? Did you have any problems with
>> configurations? PDP-10s only had 2 ports on each disk drive so
>> designing configurations so that the drives (diskpacks) could be
>> available 100% if a CPU was off-line.
>
> This system wasn't built in a very conventional way. (what I describe is
> the P series, not the later S series)
>
> The central component was the Store Multiple Access Unit (SMAC. This
> contained the memory (full ECC). It had four ports; two of those were for
> attaching OCPs. The other two were for attaching Store Access Units
> (SACs). Each SAC had eight trunks, and a trunk was attached to a
> controller. Typical controllers were General Peripheral Controller (GPC)
> - used for card reader, card punch, printer, OPER (operator station) and
> tape drives; DFC (Disc File Controller) - for, obviously, exchangeable
> disks; SFC (Sectored File Controller) - fixed head disk, drum-like; CLC
> (Communications Link Controller) - for comms. We had a PDP-11 attached to
> the GPC to interface with our network; homebrew software in ther,
> obviously. The 'ports' on the controllers were called 'streams'.

Very kewl and odd to me. I've never met a system where the memroy was
the central piece of hardware.
>
> So there weren't any dual-ported peripherals; OCPs could talk to both
> SACS, so it was symmetrical.

Could your SMP implementation removed and add pieces of the system's
hardware while running without interrupting the processing?

>
> (I hasten to add that the system was developed at the University of
> Edinburgh; I just got involved with soem interesting bits)

Understood...but they're very interesting bits :-). You must have
had fun.

>
>>> The guy who wrote *that* SMP code was later hired by DEC (VMS
>>> Engineering). Guess what he worked on.
>>
>> VMS Engineering didn't have DEC's SMP experts available; they did have
>> people who had worked with JMF but none of those were involved in the
>> initial design, specifications or implementation.
>
> Perhaps he didn't go to VMS Engineering - I just assumed he would have.
> His name is in the microfiched sources though!

I'm sure he did go; he just went after Dick's influence went away.

/BAH

jmfbahciv

unread,
Jan 26, 2017, 8:43:47 AM1/26/17
to
Rich Alderson wrote:
> Bob Eager <news...@eager.cx> writes:
>
>> On Wed, 25 Jan 2017 13:56:14 +0000, jmfbahciv wrote:
>
>>>> The guy who wrote *that* SMP code was later hired by DEC (VMS
>>>> Engineering). Guess what he worked on.
>
>>> VMS Engineering didn't have DEC's SMP experts available; they did have
>>> people who had worked with JMF but none of those were involved in the
>>> initial design, specifications or implementation.
>
>> Perhaps he didn't go to VMS Engineering - I just assumed he would have.
>> His name is in the microfiched sources though!
>
> When Barb said "DEC's SMP experts", she was referring to the wizards from
the
> PDP-10 side of the house (the Large Computer Group). Your guy might very
well
> have gone into VMS Engineering, but might not have been allowed^Wassigned to
> work on the VMS SMP implementation.
>
Oh, I'm sure he did go to VMS Engineering; that's the only place the work
would be done. However, I'm sure he went after Dick cracked his head
open and stopped working.

/BAH

Bob Eager

unread,
Jan 26, 2017, 9:39:18 AM1/26/17
to
Yes. And put together the spare pieces and IPL it separately, if one of
the OCPs and one SAC and one SMAC was included.

>> (I hasten to add that the system was developed at the University of
>> Edinburgh; I just got involved with soem interesting bits)
>
> Understood...but they're very interesting bits :-). You must have had
> fun.

Great fun! Hence the emulator.

Bob Eager

unread,
Jan 26, 2017, 9:41:28 AM1/26/17
to
On Thu, 26 Jan 2017 06:41:13 -0700, Peter Flass wrote:

>> The central component was the Store Multiple Access Unit (SMAC. This
>> contained the memory (full ECC). It had four ports; two of those were
>> for attaching OCPs. The other two were for attaching Store Access Units
>> (SACs). Each SAC had eight trunks, and a trunk was attached to a
>> controller. Typical controllers were General Peripheral Controller
>> (GPC) - used for card reader, card punch, printer, OPER (operator
>> station) and tape drives; DFC (Disc File Controller) - for, obviously,
>> exchangeable disks; SFC (Sectored File Controller) - fixed head disk,
>> drum-like; CLC (Communications Link Controller) - for comms. We had a
>> PDP-11 attached to the GPC to interface with our network; homebrew
>> software in ther, obviously. The 'ports' on the controllers were called
>> 'streams'.
>
> Sounds like the way the GE-645 was designed.

Worth saying that the diagram of interconnection on Wikipedia is
completely wrong. Must fix that.

Stephen Wolstenholme

unread,
Jan 26, 2017, 11:38:19 AM1/26/17
to
On Thu, 26 Jan 2017 06:41:13 -0700, Peter Flass
<peter...@yahoo.com> wrote:

>Sounds like the way the GE-645 was designed.

I didn't see any GE design docs and so far as I know neither did any
other 2900 development people. Some may have visited a Multics
conference and been influenced unconsciously. It's too far back for my
memory!

Steve

--
Neural Network Software for Windows http://www.npsnn.com

Bob Eager

unread,
Jan 26, 2017, 11:47:27 AM1/26/17
to
On Thu, 26 Jan 2017 16:37:49 +0000, Stephen Wolstenholme wrote:

> On Thu, 26 Jan 2017 06:41:13 -0700, Peter Flass <peter...@yahoo.com>
> wrote:
>
>>Sounds like the way the GE-645 was designed.
>
> I didn't see any GE design docs and so far as I know neither did any
> other 2900 development people. Some may have visited a Multics
> conference and been influenced unconsciously. It's too far back for my
> memory!

The main impetus came from the MU5, I believe. But that was more in the
instruction set architecture and virtual memory, bot in physical
arrangements.

Stephen Wolstenholme

unread,
Jan 26, 2017, 1:07:39 PM1/26/17
to
On 26 Jan 2017 16:47:25 GMT, Bob Eager <news...@eager.cx> wrote:

>On Thu, 26 Jan 2017 16:37:49 +0000, Stephen Wolstenholme wrote:
>
>> On Thu, 26 Jan 2017 06:41:13 -0700, Peter Flass <peter...@yahoo.com>
>> wrote:
>>
>>>Sounds like the way the GE-645 was designed.
>>
>> I didn't see any GE design docs and so far as I know neither did any
>> other 2900 development people. Some may have visited a Multics
>> conference and been influenced unconsciously. It's too far back for my
>> memory!
>
>The main impetus came from the MU5, I believe. But that was more in the
>instruction set architecture and virtual memory, bot in physical
>arrangements.

At least one of the 2900 architects was on MU5.

Bob Eager

unread,
Jan 26, 2017, 6:50:19 PM1/26/17
to
Yes, I think I knew that.

Have you read the 'ICL anthologies' (scurrilous stories)?

For general entertainment, here is one (the 2900 was 'New Range, if
anyone didn't know):
-----
At a meeting of the "New Range Upper Sub-Range Primitive Interface
Interpretive Committee", chaired by John Bowthorpe, there was a lengthy
debate one day about the proposed implementation of the SWEQ (Scan While
Equal) and SWNE (Scan While Not Equal) instructions. Near the end of the
meeting, one of the engineers got up and said that he was happy with the
implementation but unhappy with the names of the instructions.

He explained that he came from Oldham, and that in parts of Lancashire
"while" meant "until", so that any Lancastrian engineers and programmers
would interpret the instructions in exactly the opposite way to that
intended. An action was duly placed for the Architects to rule on this.

At the next meeting, the chairman came to this action and solemnly
declared that the matter had been duly considered and the instruction
names would remain as they were. It was felt that "ICL specifications
could not be written to cater for ethnic minorities".

Quadibloc

unread,
Jan 27, 2017, 2:07:53 AM1/27/17
to
On Thursday, January 26, 2017 at 4:50:19 PM UTC-7, Bob Eager wrote:

> He explained that he came from Oldham, and that in parts of Lancashire
> "while" meant "until", so that any Lancastrian engineers and programmers
> would interpret the instructions in exactly the opposite way to that
> intended. An action was duly placed for the Architects to rule on this.
>
> At the next meeting, the chairman came to this action and solemnly
> declared that the matter had been duly considered and the instruction
> names would remain as they were. It was felt that "ICL specifications
> could not be written to cater for ethnic minorities".

I remember hearing that this particular linguistic difficulty once
resulted in a boiler explosion...

Clearly, the programming language could not have been made
Lancastrian, as that would have confused nearly everyone else. But the
manual could have been written so as to make the sense of the words
involved unambiguous...

John Savard

Stephen Wolstenholme

unread,
Jan 27, 2017, 4:55:00 AM1/27/17
to
On 26 Jan 2017 23:50:17 GMT, Bob Eager <news...@eager.cx> wrote:

>He explained that he came from Oldham, and that in parts of Lancashire
>"while" meant "until", so that any Lancastrian engineers and programmers
>would interpret the instructions in exactly the opposite way to that
>intended. An action was duly placed for the Architects to rule on this.

I come from Rochdale which is almost next door to Oldham. I never
thought "while" meant "until". It must be just Oldham speak! I'm not
sure but I think I know who the engineer could be. Another ex MU5?

Bob Eager

unread,
Jan 27, 2017, 5:33:23 AM1/27/17
to
On Fri, 27 Jan 2017 09:54:30 +0000, Stephen Wolstenholme wrote:

> On 26 Jan 2017 23:50:17 GMT, Bob Eager <news...@eager.cx> wrote:
>
>>He explained that he came from Oldham, and that in parts of Lancashire
>>"while" meant "until", so that any Lancastrian engineers and programmers
>>would interpret the instructions in exactly the opposite way to that
>>intended. An action was duly placed for the Architects to rule on this.
>
> I come from Rochdale which is almost next door to Oldham. I never
> thought "while" meant "until". It must be just Oldham speak! I'm not
> sure but I think I know who the engineer could be. Another ex MU5?

No idea. But I have relatives who live in Lancaster, and although they
don't use that 'meaning', they know people who do!

Bob Eager

unread,
Jan 27, 2017, 5:33:55 AM1/27/17
to
I have the manual. It is unambiguous.

jmfbahciv

unread,
Jan 27, 2017, 8:45:05 AM1/27/17
to
The old DEC docs would have included a footnote for the Oldhamers :-)

/BAH

jmfbahciv

unread,
Jan 27, 2017, 8:45:05 AM1/27/17
to
I wish we had heard about yours when we started designing ours.

>
>>> (I hasten to add that the system was developed at the University of
>>> Edinburgh; I just got involved with soem interesting bits)
>>
>> Understood...but they're very interesting bits :-). You must have had
>> fun.
>
> Great fun! Hence the emulator.

Now I'll ask a question that most people won't understand so, if you don't,
that's OK...

How was the feel of the machine? When we had 3 CPUs hooked up, the feel
of our machine was wonderful. It felt like computing was whooshing
faster than the speed of light. It had my backbone humming; the humming
was similar to the feel whenever I read the Fundamental Theorem of
Calculus.

/BAH

Bob Eager

unread,
Jan 27, 2017, 9:29:53 AM1/27/17
to
It felt pretty good in the machine room; less so back at my desk. And not
good when we were still using the manufacturer's operating system; partly
because it was slow, and partly because you were waiting for the next
crash.

In the machine room, I always had the speaker volume turned up so I could
'hear' what it was doing.

Neil Thompson

unread,
Jan 27, 2017, 10:06:06 AM1/27/17
to
Yeah, I enjoyed the ICL OCP speakers as well. Didn't they make a record using sounds from them? Or was that the 1900s?

Gordon Henderson

unread,
Jan 27, 2017, 10:23:13 AM1/27/17
to
In article <eel0q7F...@mid.individual.net>,
Bob Eager <news...@eager.cx> wrote:

> http://www.bobeager.uk/anecdotes.html

Nice read. I used EMAS for a very brief time in the early 80's in
Edinburgh, and it's offspring; Mouses at Moray House. Although I was
in-between school and university then it did seem way ahead of its
time..

Gordon

Mike Causer

unread,
Jan 27, 2017, 12:41:05 PM1/27/17
to
On Fri, 27 Jan 2017 09:54:30 +0000
Stephen Wolstenholme <st...@easynn.com> wrote:

> I come from Rochdale which is almost next door to Oldham. I never
> thought "while" meant "until". It must be just Oldham speak! I'm not
> sure but I think I know who the engineer could be. Another ex MU5?

It's pretty common in Yorkshire and I think I've heard it in
Nottinghamshire too.

For real confusion I can still do the Black Country dialect of my youth.


Mike

David Wade

unread,
Jan 27, 2017, 1:16:32 PM1/27/17
to
Whilst its not marketed that way System/360 worked that way. The CPU and
Channels were directly attached to the store. The channels execute
channel programs, and access store directly...

Jon Elson

unread,
Jan 27, 2017, 2:29:55 PM1/27/17
to
David Wade wrote:


> Whilst its not marketed that way System/360 worked that way. The CPU and
> Channels were directly attached to the store. The channels execute
> channel programs, and access store directly...
Well, that would actually be true on larger 360s, only. Anything including
up to the 360/50 used the CPU to perform channel functions. I think you
could add additional external channels to the 360/50, but not many
installations needed to. On the 360/30, the CPU was so slow, and the memory
was only one byte wide, so the CPU was locked out for the duration of at
least selector channel operation. (Not so sure if that was true for the
multiplexer channel.)

The channel function (whether physical or emulated) did, indeed, execute its
programs out of main storage.

Jon

Gene Wirchenko

unread,
Jan 27, 2017, 3:24:57 PM1/27/17
to
On 27 Jan 2017 10:33:53 GMT, Bob Eager <news...@eager.cx> wrote:

>On Thu, 26 Jan 2017 23:07:52 -0800, Quadibloc wrote:

[snip]

>> Clearly, the programming language could not have been made Lancastrian,
>> as that would have confused nearly everyone else. But the manual could
>> have been written so as to make the sense of the words involved
>> unambiguous...
>
>I have the manual. It is unambiguous.

See <https://en.wikipedia.org/wiki/Yorkshire_dialect>,
"Vocabulary and grammar" where it states: "<i>While</> is often used
in the sense of <i>until</> (e.g. <i>unless we go at a fair lick,
we'll not be home while seven</>.) <i>Stay here while it shuts</>
might cause a non-local to think that they should stay there
<i>during</> its shutting, when the order really means that they
should stay only <i>until</> it shuts.[47]'

Given this meaning exists, is the manual still unambiguous?

Sincerely,

Gene Wirchenko

David Wade

unread,
Jan 27, 2017, 4:14:11 PM1/27/17
to
On 27/01/2017 19:30, Jon Elson wrote:
> David Wade wrote:
>
>
>> Whilst its not marketed that way System/360 worked that way. The CPU and
>> Channels were directly attached to the store. The channels execute
>> channel programs, and access store directly...
> Well, that would actually be true on larger 360s, only. Anything including
> up to the 360/50 used the CPU to perform channel functions. I think you
> could add additional external channels to the 360/50, but not many
> installations needed to. On the 360/30, the CPU was so slow, and the memory
> was only one byte wide, so the CPU was locked out for the duration of at
> least selector channel operation. (Not so sure if that was true for the
> multiplexer channel.)
>

Ah I started on a 360/67 which definitely had separate channel boxes.

The Honeywell 6000/L66/DPS8 series machines also predated the 2900 and
had the same sort of configuration, with CPU's and I/O controllers
attached to the Memory. Like the ICL2900 CPU's could be taken off line
and the dual CPU system we had could be reconfigured as two single CPU
systems.

I have no idea how wide the memory access was but I do know that when
doing tape I/O the CPUs were locked out.

Download

http://bitsavers.trailing-edge.com/pdf/honeywell/series6000/DA48_series6000_summary_1971.pdf

and take a look at the picture on page 4. Central memory modules with
ports to which CPU's or IO Multiplexors could be attached.


> The channel function (whether physical or emulated) did, indeed, execute its
> programs out of main storage.
>
> Jon
>

Dave

Bob Eager

unread,
Jan 27, 2017, 4:21:34 PM1/27/17
to
On Fri, 27 Jan 2017 07:06:04 -0800, Neil Thompson wrote:

> Yeah, I enjoyed the ICL OCP speakers as well. Didn't they make a
> record using sounds from them? Or was that the 1900s?

Never heard of either. But there were a lot more 1900s.

Bob Eager

unread,
Jan 27, 2017, 4:25:41 PM1/27/17
to
As you know, EMAS started off on the System 4. Then it was ported to the
2900 (famous paper, of which I have a copy: "An Experiment In Doing It
Again, But Very Well This Time"). I did some of the later 2960 stuff
(including, as you will have seen, the SMP bits specific to that model).

Then it was ported onto the Amdahl systems. I did a lot of the work (and
all of the early testing) on porting it to XA. That involved a two anbd a
half hour trip (each way) to the nearest IBM facility, with a mag tape,
three times a week. And then we got a VAX.

Bob Eager

unread,
Jan 27, 2017, 4:26:14 PM1/27/17
to
This was Lancashire! .-)

Anne & Lynn Wheeler

unread,
Jan 27, 2017, 5:42:31 PM1/27/17
to
David Wade <dave....@gmail.com> writes:
> Ah I started on a 360/67 which definitely had separate channel boxes.
>
> The Honeywell 6000/L66/DPS8 series machines also predated the 2900 and
> had the same sort of configuration, with CPU's and I/O controllers
> attached to the Memory. Like the ICL2900 CPU's could be taken off line
> and the dual CPU system we had could be reconfigured as two single CPU
> systems.
>
> I have no idea how wide the memory access was but I do know that when
> doing tape I/O the CPUs were locked out.
>
> Download
>
> http://bitsavers.trailing-edge.com/pdf/honeywell/series6000/DA48_series6000_summary_1971.pdf
>
> and take a look at the picture on page 4. Central memory modules with
> ports to which CPU's or IO Multiplexors could be attached.

re:
http://www.garlic.com/~lynn/2017.html#58 The ICL 2900
http://www.garlic.com/~lynn/2017.html#59 The ICL 2900
http://www.garlic.com/~lynn/2017.html#60 The ICL 2900
http://www.garlic.com/~lynn/2017.html#61 The ICL 2900

360 65, 67 and higher models had dedicated separate channel boxes.

360 50, 40 & lower end had integrated channels (processor was shared
executing channel microcode and 360 microcode)

370 165/168 & higher end had dedicated separate channels boxes

370 155/158 & lower end had integrated channels (processor executed both
channel microcode and 370 micrcode)

There was exception for 370/115 & 370/125 done by Boeblingen (or
Boblingen with the umlaut, just check internet, says in german it is
always transliterated to "e", but in Swedish it is dropped), Germany
... and folklore is that they got their hands slapped by corporate.

They did memory bus with positions for up to nine microprocessors
... all identical ... running different microcode for 370, i/o, device
controllers, etc. 125 was identical to 115 except that the
microprocessor running 370 microcode was 50% faster than the other
processors. At one point, I was sucked into designing a 370/125
multiprocessor where up to 5 of the bus positions would running the 370
multiprocessor microprocessors. some past posts
http://www.garlic.com/~lynn/submain.html#bounce

it was never announced/shipped ... in part because the 138/148 people
complained it overlapped their throughput at better
price/performance. At the time, I had also been sucked into doing
370/148 stuff ... so in some escalation meetings ... I was required to
represent both sides of the table and argue with myself. part of the
138/148 effort was the ECPS microcode ... dropping operating system
stuff directly into native microcode, getting 10:1 speedup:
http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist

I was working on superset of ECPS for the 125 ... but also something
that was superset of what would become SSCH for 370-xa ... because I had
all the system microcode in the same box.
http://www.garlic.com/~lynn/94.html#27 370 ECPS VM microcode assist

during Future System period ... they were shutting down 370 efforts
(since FS was going to completely replace 360/370)
http://www.garlic.com/~lynn/submain.html#futuresys

with the implosion of FS, there was mad rush to get 370 stuff back into
product pipelines ... including kicking off 303x & 3081 in parallel ...
some (FS, 303x, 3081) history:
http://www.jfsowa.com/computer/memo125.htm

for 303x external channel box, they took the 158 integrated channel
microcode (w/o the 370 microcode). A 3031 was a 158 processor with just
the 370 microcode and 2nd 158 processor with just the integrated channel
microcode. A 3032 was a 168 processor with a 158 processor as external
channel. A 3033 started out as 168 logic mapped to faster chips (and one
or more 158 processors for external channels).

360/65 and 360/67 single processors were nearly identical except for
addition of virtual memory hardware for 360/67.

360/65 and 360/67 multiple processor were a lot more different. 360/65
multiprocessor shared real memory ... but not I/O, external channel
boxes were only attached to single processor. To simulate shared I/O
they used "multi-tail" controllers (that could be connected to multiple
channels) that were configured at same addresses on the respective
processor channels.

360/67 functional characteristic
http://bitsavers.org/pdf/ibm/360/funcChar/A27-2719-0_360-67_funcChar.pdf

360/67 multiprocessor shared both real memory and each processor could
be configured to access/share all channels ... there was director
... and memory was multi-ported with independent path for I/O). 360/65
& 360/67 single processor had to share same memory ports with
I/O. Mutli-ported 360/67 memory had slightly longer latency for all
accesses (resolving multi-port protocol) ... but in heavy i/o loads,
could have overall higher throughput (because allowing concurrent
activity, some configurations even ran 67-2 with only single
processor). Pg. 43 starts instruction times and gives formulas. Pg. 46
starts average instruction times and shows the difference between single
processor (67-1) and 67-2 multi-ported memory (with slightly increased
latency).

shows the multiprocessor director (2167,pg29) which could reconfigure
for complete sharing ... or partition hardware in number of ways. It also
shows that the settings of the director could be read/sensed from the
"control registers" (pg31-32). multiprocess posts
http://www.garlic.com/~lynn/subtopic.html#smp

There was a three processor 360/67 for Air Force Manned Orital
Laboratory (MOL) project being done by Lockheed in Sunnyvale that had
special modifications that allowed the software to change/update the
2167 hardware configuration by storing/setting values in those control
registers.

--
virtualization experience starting Jan1968, online at home since Mar1970

Anne & Lynn Wheeler

unread,
Jan 27, 2017, 6:53:11 PM1/27/17
to
Anne & Lynn Wheeler <ly...@garlic.com> writes:
> it was never announced/shipped ... in part because the 138/148 people
> complained it overlapped their throughput at better
> price/performance. At the time, I had also been sucked into doing
> 370/148 stuff ... so in some escalation meetings ... I was required to
> represent both sides of the table and argue with myself. part of the
> 138/148 effort was the ECPS microcode ... dropping operating system
> stuff directly into native microcode, getting 10:1 speedup:
> http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist
>
> I was working on superset of ECPS for the 125 ... but also something
> that was superset of what would become SSCH for 370-xa ... because I had
> all the system microcode in the same box.
> http://www.garlic.com/~lynn/94.html#27 370 ECPS VM microcode assist

re:

following the demise of the 125 multiprocessor effort, I got sucked into
working on a generalized 370 16-way multiprocessor. At first we got good
reception from around the company and even got the 3033 processor
engineers to work on it in their spare time (more interesting than
remapping 168 logic to faster chips). Then somebody leaked to the head
of POK (high-end mainframe) that it could be decades before the POK
favorite son operating system (MVS) had effective 16-way support. In
response, the head of POK invited some of us to never visit POK again
and instructed the 3033 processor engineers to stop being distracted.

this was 1976-1977 time-frame ... 16-way mainframe doesn't ship until
2000 with z900 (over 20yrs later).

es/9000 1990 w/6processors
z900 2000 16 processors
z990 2003 32 processors
z9 2005 54 processors
z10 2008 64 processors
z196 2010 80 processors
ec12 2012 101 processors
z13 2015 140 processors

this is sort of funny:
https://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_FS9000.html

The IBM Enterprise System/9000 (ES/9000) family of 18 processors
announced today for System/390 range from intermediate computers for
office environments to the most powerful mainframe systems the company
has ever offered.

... snip ...

since it doesn't refer to 18-way SMP ... it refers to 18 different
models (largest is 6-way SMP). It also refers to ESCON being announced
with ES/9000 ... which is already obsolete ... various posts
http:///www.garlic.com/~lynn/submisc.html#channel.extender

about having worked on supporting channel extender in 1980 and
then asked in 1988 to help LLNL standardized some serial stuff
they have which quickly becomes fibre channel standard. some
related posts
http://www.garlic.com/~lynn/submisc.html#ficon

SMP posts
http://www.garlic.com/~lynn/subtopic.html#smp

specifically mentioning 16-way effort
http://www.garlic.com/~lynn/2005r.html#46 Numa-Q Information
http://www.garlic.com/~lynn/2007g.html#17 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007l.html#26 Is Parallel Programming Just Too Hard?
http://www.garlic.com/~lynn/2007t.html#77 T3 Sues IBM To Break its Mainframe Monopoly
http://www.garlic.com/~lynn/2009o.html#14 Microprocessors with Definable MIcrocode
http://www.garlic.com/~lynn/2009o.html#17 Broken hardware was Re: Broken Brancher
http://www.garlic.com/~lynn/2009s.html#32 Larrabee delayed: anyone know what's happening?
http://www.garlic.com/~lynn/2010i.html#61 IBM to announce new MF's this year
http://www.garlic.com/~lynn/2011.html#23 zLinux OR Linux on zEnterprise Blade Extension???
http://www.garlic.com/~lynn/2011.html#28 Personal histories and IBM computing
http://www.garlic.com/~lynn/2011b.html#68 vm/370 3081
http://www.garlic.com/~lynn/2011j.html#10 program coding pads
http://www.garlic.com/~lynn/2011p.html#52 Has anyone successfully migrated off mainframes?
http://www.garlic.com/~lynn/2012c.html#29 5 Byte Device Addresses?
http://www.garlic.com/~lynn/2012e.html#38 A bit of IBM System 360 nostalgia
http://www.garlic.com/~lynn/2012i.html#28 Top Ten Reasons Why Large Companies Fail To Keep Their Best Talent
http://www.garlic.com/~lynn/2012k.html#14 International Business Marionette
http://www.garlic.com/~lynn/2012n.html#36 390 vector instruction set reuse, was 8-bit bytes
http://www.garlic.com/~lynn/2012o.html#4 Unintended consequence of RISC simplicity?
http://www.garlic.com/~lynn/2013h.html#14 The cloud is killing traditional hardware and software
http://www.garlic.com/~lynn/2013m.html#70 architectures, was Open source software
http://www.garlic.com/~lynn/2013n.html#59 'Free Unix!': The world-changing proclamation made30yearsagotoday
http://www.garlic.com/~lynn/2014d.html#59 Difference between MVS and z / OS systems
http://www.garlic.com/~lynn/2014f.html#21 Complete 360 and 370 systems found
http://www.garlic.com/~lynn/2014h.html#6 Demonstrating Moore's law
http://www.garlic.com/~lynn/2014i.html#52 IBM Programmer Aptitude Test
http://www.garlic.com/~lynn/2014k.html#71 Bell Picturephone--early business application experiments
http://www.garlic.com/~lynn/2014m.html#105 IBM 360/85 vs. 370/165
http://www.garlic.com/~lynn/2014m.html#111 IBM 360/85 vs. 370/165
http://www.garlic.com/~lynn/2014m.html#140 IBM Continues To Crumble
http://www.garlic.com/~lynn/2015b.html#46 Connecting memory to 370/145 with only 36 bits
http://www.garlic.com/~lynn/2015d.html#39 Remember 3277?
http://www.garlic.com/~lynn/2015h.html#105 DOS descendant still lives was Re: slight reprieve on the z
http://www.garlic.com/~lynn/2016b.html#23 IBM's 3033; "The Big One": IBM's 3033
http://www.garlic.com/~lynn/2016b.html#78 Microcode
http://www.garlic.com/~lynn/2016c.html#70 Microprocessor Optimization Primer
http://www.garlic.com/~lynn/2016d.html#59 PL/I advertising
http://www.garlic.com/~lynn/2016e.html#114 IBM History
http://www.garlic.com/~lynn/2016f.html#85 3033
http://www.garlic.com/~lynn/2016f.html#86 3033
http://www.garlic.com/~lynn/2016h.html#98 A Christmassy PL/I tale

David Wade

unread,
Jan 27, 2017, 6:56:22 PM1/27/17
to
On 27/01/2017 21:21, Bob Eager wrote:
> On Fri, 27 Jan 2017 07:06:04 -0800, Neil Thompson wrote:
>
>> Yeah, I enjoyed the ICL OCP speakers as well. Didn't they make a
>> record using sounds from them? Or was that the 1900s?
>
> Never heard of either. But there were a lot more 1900s.
>
>
>
I remember visiting the MU5 at Manchester University and hearing that
play tunes. They were selected by some switchs. On changing the tune,
MU5 composed a short key change piece so there was no loss of musicality.

I gather the Music only played when MU5 was idle, which by this time it
was most of the time....

Dave Wade

Bill Findlay

unread,
Jan 28, 2017, 12:11:38 AM1/28/17
to
That sort of thing goes back a very long way, as far as Christopher
Strachey and the Manchester Mark 1.

I was often serenaded in my office by works composed and performed by
SOLIDAC:

<http://www.findlayw.plus.com/SOLIDAC/index.html>

--
Bill Findlay

jmfbahciv

unread,
Jan 28, 2017, 8:56:20 AM1/28/17
to
There's a subtle difference, IIUC. On Bob's system, the CPUs were
peripherals; memory was the central hardware. That makes a big difference
in designing. I'd have to really, really try hard to switch my thinking
bias. Although I did envision CPUs as peripherals, e.g., when
scheduling CPU-intensive jobs, they could be run on a processor designed
for that while the general CPUs continued to do regular timesharing.

/BAH

David Wade

unread,
Jan 28, 2017, 3:33:48 PM1/28/17
to
On 28/01/2017 05:11, Bill Findlay wrote:
> David Wade <dave....@gmail.com> wrote:
>> On 27/01/2017 21:21, Bob Eager wrote:
>>> On Fri, 27 Jan 2017 07:06:04 -0800, Neil Thompson wrote:
>>>
>>>> Yeah, I enjoyed the ICL OCP speakers as well. Didn't they make a
>>>> record using sounds from them? Or was that the 1900s?
>>>
>>> Never heard of either. But there were a lot more 1900s.
>>>
>> I remember visiting the MU5 at Manchester University and hearing that
>> play tunes. They were selected by some switchs. On changing the tune,
>> MU5 composed a short key change piece so there was no loss of musicality.
>>
>> I gather the Music only played when MU5 was idle, which by this time it
>> was most of the time....
>
> That sort of thing goes back a very long way, as far as Christopher
> Strachey and the Manchester Mark 1.
>

Didn't know about the MK1 but the Pegasus Emulator includes a program to
play tunes. I can imagine Christopher Strachey writing music programs...

> I was often serenaded in my office by works composed and performed by
> SOLIDAC:
>
> <http://www.findlayw.plus.com/SOLIDAC/index.html>
>

Davew

hanc...@bbs.cpcn.com

unread,
Jan 28, 2017, 3:42:24 PM1/28/17
to
On Friday, January 27, 2017 at 2:29:55 PM UTC-5, Jon Elson wrote:

> Well, that would actually be true on larger 360s, only. Anything including
> up to the 360/50 used the CPU to perform channel functions. I think you
> could add additional external channels to the 360/50, but not many
> installations needed to. On the 360/30, the CPU was so slow, and the memory
> was only one byte wide, so the CPU was locked out for the duration of at
> least selector channel operation. (Not so sure if that was true for the
> multiplexer channel.)

Yet I believe the S/360 model 30 was their most popular unit.

Anne & Lynn Wheeler

unread,
Jan 28, 2017, 5:20:12 PM1/28/17
to
hanc...@bbs.cpcn.com writes:
> Yet I believe the S/360 model 30 was their most popular unit.

http://www.garlic.com/~lynn/2017.html#74 The ICL 2900
http://www.garlic.com/~lynn/2017.html#75 The ICL 2900

models/profits from end of ACS
https://people.cs.clemson.edu/~mark/acs_end.html

Of the 26,000 IBM computer systems in use, 16,000 were S/360 models
(that is, over 60%). [Fig. 1.311.2]

Of the general-purpose systems having the largest fraction of total
installed value, the IBM S/360 Model 30 was ranked first with 12%
(rising to 17% in 1969). The S/360 Model 40 was ranked second with 11%
(rising to almost 15% in 1970). [Figs. 2.10.4 and 2.10.5]

Of the number of operations per second in use, the IBM S/360 Model 65
ranked first with 23%. The Univac 1108 ranked second with slightly over
14%, and the CDC 6600 ranked third with 10%. [Figs. 2.10.6 and 2.10.7]

... snip ...

Amdahl doing ACS/360 ... with supercomputer and 1/3rd supercomputer plus
1/9th supercomputer models for the rest of the market:

To achieve a profit for the ACS program, Amdahl asked IBM management to
approve three ACS/360 models: the high-performance design, a 1/3
performance version, and a 1/9 performance version. He felt that these
performance goals would be a good fit with the System 360 marketing
plans. He remembers that IBM Corporate Marketing evaluated the targets
and reported: "1) the supercomputer alone was a loss leader! 2) the
supercomputer plus the 1/3 performance computer was break-even! And 3)
the supercomputer plus both the 1/3 performance computer and the 1/9
performance computer was normal profit -- 30% pre-tax!"

... snip ...

executives then cancel ACS/360 because they were afraid that it would
advance the state of the art too fast and they would loose control of
the market. At the bottom of the page, it shows ACS/360 features showing
up in ES/9000 more than 20yrs later.

other recent posts mentioning end of ACS
http://www.garlic.com/~lynn/2016.html#33 IBM STRETCH repricing decision?
http://www.garlic.com/~lynn/2016b.html#23 IBM's 3033; "The Big One": IBM's 3033
http://www.garlic.com/~lynn/2016c.html#3 You count as an old-timer if (was Re: Origin of the phrase "XYZZY")
http://www.garlic.com/~lynn/2016c.html#10 You count as an old-timer if (was Re: Origin of the phrase "XYZZY")
http://www.garlic.com/~lynn/2016d.html#89 China builds world's most powerful computer
http://www.garlic.com/~lynn/2016e.html#37 How the internet was invented
http://www.garlic.com/~lynn/2016e.html#60 Honeywell 200
http://www.garlic.com/~lynn/2016e.html#65 Dinosaurisation of we oldies?
http://www.garlic.com/~lynn/2016h.html#7 "I used a real computer at home...and so will you" (Popular Science May 1967)
http://www.garlic.com/~lynn/2016h.html#30 IBM project discussions
http://www.garlic.com/~lynn/2016h.html#44 Resurrected! Paul Allen's tech team brings 50-year-old supercomputer back from the dead
http://www.garlic.com/~lynn/2016h.html#45 Resurrected! Paul Allen's tech team brings 50-year-old supercomputer back from the dead
http://www.garlic.com/~lynn/2016h.html#48 Why Can't You Buy z Mainframe Services from Amazon Cloud Services?
http://www.garlic.com/~lynn/2016h.html#75 "I used a real computer at home...and so will you" (Popular Science May 1967)
http://www.garlic.com/~lynn/2017.html#3 Is multiprocessing better then multithreading?

John Levine

unread,
Jan 28, 2017, 5:29:39 PM1/28/17
to
>> On the 360/30, the CPU was so slow, and the memory
>> was only one byte wide, so the CPU was locked out for the duration of at
>> least selector channel operation. (Not so sure if that was true for the
>> multiplexer channel.)

>Yet I believe the S/360 model 30 was their most popular unit.

Well, sure, because it was the cheapest and it did work. For small
I/O bound applications the /30 got the job done.

Bill Findlay

unread,
Jan 28, 2017, 5:43:03 PM1/28/17
to
How does that make sense?
You lose control by completely dominating It??




--
Bill Findlay

Quadibloc

unread,
Jan 28, 2017, 5:51:50 PM1/28/17
to
Well, perhaps IBM innovations could eventually be copied by
competitors... and then, IBM having ventured out to its ultimate
reach, would not necessarily be quickly able to come up with
something even better.

John Savard

Bill Findlay

unread,
Jan 28, 2017, 6:13:25 PM1/28/17
to
Surely a comparative lack of innovation could be copied even more easily.
As indeed it was.

--
Bill Findlay

Anne & Lynn Wheeler

unread,
Jan 28, 2017, 6:32:14 PM1/28/17
to
Bill Findlay <no_e...@invalid.invalid> writes:
> How does that make sense?
> You lose control by completely dominating It??

re:
http://www.garlic.com/~lynn/2017.html#81 The ICL 2900

big disruptive innovation could provide unexpected opportunities for
competition ... especially with huge changes in price/performance (it
could easily mess up bottom line and profit margins) ... case in point
was growth of ibm/pc market.

I've frequently referred to talk by senior disk engineer at internal
communication group world-wide annual conference ... supposedly on 3174
performance but opened with statement that the communication group was
going to be responsible for the demise of the disk division. Issue was
the communication group had stangle hold on datacenters with their
strategic responsibility for everything that crossed the datacenter wall
and were fiercely fighting off distributed computing and client/server,
trying to preserve their (emulated) dumb terminal install base. The disk
division was seeing the drop in disk sales with data fleeing to move
distributed computing friendly platforms. The disk division had come
up with several solutions, but they were constantly being vetoed by
the communication group. past posts
http://www.garlic.com/~lynn/subnetwork.html#terminal

in the mid-80s, top ibm executives had predicted the business would
double ... mostly based on mainframe sales ... and had big internal
building program to double manufacturing capacity of mainframe related
products ... however business was already starting to go in the opposite
direction. By the early 90s with loss of significant mainframe business,
the company had gone into the red and was being reorganized into the 13
"baby blues" in preparation for breaking up the company (when a new CEO
was brought in to reverse the breakup and resurrect the company)
... some past posts
http://www.garlic.com/~lynn/submisc.html#gerstner

Mid-90s, the remaining mainstay of the mainframe business was the
financial community with huge, critical business applications dating
back to early 360 days. The financial community spent billions of
dollars on reimplementing for straight-through parallel processing on
large numbers of killer micros ... to alleviated the overnight cobol
batch settlement bottleneck of these ancient applications. However, they
were using some standard library parallelization software that had
hundred times the overhead of cobol batch ... when they were warned
about the problem ... it was just ignored. They finally had to face it
when some large scale pilot rollouts went down in flames ... and they
had to retrench to doing large scale Y2K remediation on these ancient
legacy applications.

Middle of last decade, I was involved in taking some technology to
financial association groups, that easily handled straight-through
financial processing ... allowing specification of high-level rules that
then generated fine-grain SQL statements. It relied on the significant
performance work that all the major RDBMS vendors had invested in
cluster (parallel) scaleup (it didn't try to do the parallelization
effort, it just decomposed work into units that then were efficiently
parallelized by cluster scaleup). Initially it got really good
acceptance ... but then ran into brickwall. Finally we were told that
there were still too many executives that bore scars from the failed
attempts in the 90s ... and it would have to wait for a whole new
generation.

past posts mentioning straight-through processing:
http://www.garlic.com/~lynn/2007e.html#31 Quote from comp.object
http://www.garlic.com/~lynn/2007l.html#15 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007m.html#36 Future of System/360 architecture?
http://www.garlic.com/~lynn/2007t.html#3 Translation of IBM Basic Assembler to C?
http://www.garlic.com/~lynn/2007t.html#5 Translation of IBM Basic Assembler to C?
http://www.garlic.com/~lynn/2007u.html#19 Distributed Computing
http://www.garlic.com/~lynn/2007u.html#21 Distributed Computing
http://www.garlic.com/~lynn/2007u.html#37 folklore indeed
http://www.garlic.com/~lynn/2007u.html#44 Distributed Computing
http://www.garlic.com/~lynn/2007u.html#61 folklore indeed
http://www.garlic.com/~lynn/2007v.html#19 Education ranking
http://www.garlic.com/~lynn/2007v.html#27 folklore indeed
http://www.garlic.com/~lynn/2007v.html#64 folklore indeed
http://www.garlic.com/~lynn/2007v.html#69 Controlling COBOL DDs named SYSOUT
http://www.garlic.com/~lynn/2007v.html#72 whats the world going to do when all the baby boomers retire
http://www.garlic.com/~lynn/2007v.html#81 Tap and faucet and spellcheckers
http://www.garlic.com/~lynn/2008b.html#3 on-demand computing
http://www.garlic.com/~lynn/2008b.html#74 Too much change opens up financial fault lines
http://www.garlic.com/~lynn/2008d.html#30 Toyota Sales for 2007 May Surpass GM
http://www.garlic.com/~lynn/2008d.html#31 Toyota Sales for 2007 May Surpass GM
http://www.garlic.com/~lynn/2008d.html#73 Price of CPU seconds
http://www.garlic.com/~lynn/2008d.html#87 Berkeley researcher describes parallel path
http://www.garlic.com/~lynn/2008d.html#89 Berkeley researcher describes parallel path
http://www.garlic.com/~lynn/2008g.html#55 performance of hardware dynamic scheduling
http://www.garlic.com/~lynn/2008h.html#50 Microsoft versus Digital Equipment Corporation
http://www.garlic.com/~lynn/2008h.html#56 Long running Batch programs keep IMS databases offline
http://www.garlic.com/~lynn/2008p.html#26 What is the biggest IT myth of all time?
http://www.garlic.com/~lynn/2008p.html#30 Automation is still not accepted to streamline the business processes... why organizations are not accepting newer technolgies?
http://www.garlic.com/~lynn/2008p.html#35 Automation is still not accepted to streamline the business processes... why organizations are not accepting newer technolgies?
http://www.garlic.com/~lynn/2008r.html#7 If you had a massively parallel computing architecture, what unsolved problem would you set out to solve?
http://www.garlic.com/~lynn/2009.html#87 Cleaning Up Spaghetti Code vs. Getting Rid of It
http://www.garlic.com/~lynn/2009c.html#43 Business process re-engineering
http://www.garlic.com/~lynn/2009d.html#14 Legacy clearing threat to OTC derivatives warns State Street
http://www.garlic.com/~lynn/2009f.html#55 Cobol hits 50 and keeps counting
http://www.garlic.com/~lynn/2009h.html#1 z/Journal Does it Again
http://www.garlic.com/~lynn/2009h.html#2 z/Journal Does it Again
http://www.garlic.com/~lynn/2009i.html#21 Why are z/OS people reluctant to use z/OS UNIX?
http://www.garlic.com/~lynn/2009i.html#23 Why are z/OS people reluctant to use z/OS UNIX? (Are settlements a good argument for overnight batch COBOL ?)
http://www.garlic.com/~lynn/2009i.html#43 Why are z/OS people reluctant to use z/OS UNIX? (Are settlements a good argument for overnight batch COBOL ?)
http://www.garlic.com/~lynn/2009l.html#57 IBM halves mainframe Linux engine prices
http://www.garlic.com/~lynn/2009m.html#22 PCI SSC Seeks standard for End to End Encryption?
http://www.garlic.com/~lynn/2009m.html#81 A Faster Way to the Cloud
http://www.garlic.com/~lynn/2009o.html#81 big iron mainframe vs. x86 servers
http://www.garlic.com/~lynn/2009q.html#67 Now is time for banks to replace core system according to Accenture
http://www.garlic.com/~lynn/2009q.html#68 Now is time for banks to replace core system according to Accenture
http://www.garlic.com/~lynn/2010.html#77 Korean bank Moves back to Mainframes (...no, not back)
http://www.garlic.com/~lynn/2010b.html#16 How long for IBM System/360 architecture and its descendants?
http://www.garlic.com/~lynn/2010b.html#19 STEM crisis
http://www.garlic.com/~lynn/2010c.html#8 search engine history, was Happy DEC-10 Day
http://www.garlic.com/~lynn/2010c.html#78 SLIGHTLY OT - Home Computer of the Future (not IBM)
http://www.garlic.com/~lynn/2010g.html#37 16:32 far pointers in OpenWatcom C/C++
http://www.garlic.com/~lynn/2010h.html#47 COBOL - no longer being taught - is a problem
http://www.garlic.com/~lynn/2010h.html#78 Software that breaks computer hardware( was:IBM 029 service manual )
http://www.garlic.com/~lynn/2010i.html#41 Idiotic programming style edicts
http://www.garlic.com/~lynn/2010k.html#3 Assembler programs was Re: Delete all members of a PDS that is allocated
http://www.garlic.com/~lynn/2010l.html#14 Age
http://www.garlic.com/~lynn/2010m.html#13 Is the ATM still the banking industry's single greatest innovation?
http://www.garlic.com/~lynn/2010m.html#37 A Bright Future for Big Iron?
http://www.garlic.com/~lynn/2011.html#19 zLinux OR Linux on zEnterprise Blade Extension???
http://www.garlic.com/~lynn/2011.html#42 Looking for a real Fortran-66 compatible PC compiler (CP/M or DOSor Windows
http://www.garlic.com/~lynn/2011c.html#35 If IBM Hadn't Bet the Company
http://www.garlic.com/~lynn/2011c.html#45 If IBM Hadn't Bet the Company
http://www.garlic.com/~lynn/2011e.html#15 At least two decades back, some gurus predicted that mainframes would disappear in future and it still has not happened
http://www.garlic.com/~lynn/2011e.html#19 At least two decades back, some gurus predicted that mainframes would disappear in future and it still has not happened
http://www.garlic.com/~lynn/2011e.html#91 Mainframe Fresher
http://www.garlic.com/~lynn/2011e.html#93 Itanium at ISSCC
http://www.garlic.com/~lynn/2011f.html#1 Itanium at ISSCC
http://www.garlic.com/~lynn/2011f.html#32 At least two decades back, some gurus predicted that mainframes would disappear
http://www.garlic.com/~lynn/2011h.html#8 At least two decades back, some gurus predicted that mainframes would disappear in future and it still has not happened
http://www.garlic.com/~lynn/2011i.html#52 At least two decades back, some gurus predicted that mainframes would disappear in future and it still has not happened
http://www.garlic.com/~lynn/2011k.html#70 New IBM Redbooks residency experience in Poughkeepsie, NY
http://www.garlic.com/~lynn/2011n.html#10 Has anyone successfully migrated off mainframes?
http://www.garlic.com/~lynn/2011n.html#23 Why are organizations sticking with mainframes?
http://www.garlic.com/~lynn/2011o.html#9 John R. Opel, RIP
http://www.garlic.com/~lynn/2011o.html#79 Why are organizations sticking with mainframes?
http://www.garlic.com/~lynn/2011p.html#8 Why are organizations sticking with mainframes?
http://www.garlic.com/~lynn/2011p.html#12 Why are organizations sticking with mainframes?
http://www.garlic.com/~lynn/2012e.html#49 US payments system failing to meet the needs of the digital economy
http://www.garlic.com/~lynn/2012f.html#0 Burroughs B5000, B5500, B6500 videos
http://www.garlic.com/~lynn/2012f.html#24 Time to competency for new software language?
http://www.garlic.com/~lynn/2012f.html#36 Time to competency for new software language?
http://www.garlic.com/~lynn/2012j.html#69 Monopoly/ Cartons of Punch Cards
http://www.garlic.com/~lynn/2012j.html#77 Monopoly/ Cartons of Punch Cards
http://www.garlic.com/~lynn/2012l.html#31 X86 server
http://www.garlic.com/~lynn/2012l.html#47 I.B.M. Mainframe Evolves to Serve the Digital World
http://www.garlic.com/~lynn/2012n.html#18 System/360--50 years--the future?
http://www.garlic.com/~lynn/2012n.html#24 System/360--50 years--the future?
http://www.garlic.com/~lynn/2012n.html#56 Under what circumstances would it be a mistake to migrate applications/workload off the mainframe?
http://www.garlic.com/~lynn/2013b.html#42 COBOL will outlive us all
http://www.garlic.com/~lynn/2013c.html#84 What Makes an Architecture Bizarre?
http://www.garlic.com/~lynn/2013f.html#57 The cloud is killing traditional hardware and software
http://www.garlic.com/~lynn/2013g.html#6 The cloud is killing traditional hardware and software
http://www.garlic.com/~lynn/2013g.html#50 The cloud is killing traditional hardware and software
http://www.garlic.com/~lynn/2013h.html#42 The Mainframe is "Alive and Kicking"
http://www.garlic.com/~lynn/2013i.html#49 Internet Mainframe Forums Considered Harmful
http://www.garlic.com/~lynn/2013m.html#35 Why is the mainframe so expensive?
http://www.garlic.com/~lynn/2013o.html#80 "Death of the mainframe"
http://www.garlic.com/~lynn/2014.html#3 We need to talk about TED
http://www.garlic.com/~lynn/2014b.html#81 CPU time
http://www.garlic.com/~lynn/2014b.html#83 CPU time
http://www.garlic.com/~lynn/2014c.html#22 US Federal Reserve pushes ahead with Faster Payments planning
http://www.garlic.com/~lynn/2014c.html#90 Why do bank IT systems keep failing ?
http://www.garlic.com/~lynn/2014e.html#10 Can the mainframe remain relevant in the cloud and mobile era?
http://www.garlic.com/~lynn/2014f.html#69 Is end of mainframe near ?
http://www.garlic.com/~lynn/2014f.html#74 Is end of mainframe near ?
http://www.garlic.com/~lynn/2014f.html#78 Over in the Mainframe Experts Network LinkedIn group
http://www.garlic.com/~lynn/2014g.html#14 Is end of mainframe near ?
http://www.garlic.com/~lynn/2014j.html#38 Meet Cobol's hard core fans
http://www.garlic.com/~lynn/2014m.html#71 Decimation of the valuation of IBM
http://www.garlic.com/~lynn/2014m.html#119 Holy Grail for parallel programming language
http://www.garlic.com/~lynn/2014m.html#170 IBM Continues To Crumble
http://www.garlic.com/~lynn/2015.html#78 Is there an Inventory of the Inalled Mainframe Systems Worldwide
http://www.garlic.com/~lynn/2015c.html#65 A New Performance Model ?
http://www.garlic.com/~lynn/2015h.html#2 More "ageing mainframe" (bad) press
http://www.garlic.com/~lynn/2015h.html#112 Is there a source for detailed, instruction-level performance info?
http://www.garlic.com/~lynn/2016.html#25 1976 vs. 2016?
http://www.garlic.com/~lynn/2016b.html#48 Windows 10 forceful update?
http://www.garlic.com/~lynn/2016d.html#84 The mainframe is dead. Long live the mainframe!
http://www.garlic.com/~lynn/2016g.html#23 How to Fix IBM
http://www.garlic.com/~lynn/2016h.html#72 Why Can't You Buy z Mainframe Services from Amazon Cloud Services?

Bill Findlay

unread,
Jan 28, 2017, 6:39:35 PM1/28/17
to
Anne & Lynn Wheeler <ly...@garlic.com> wrote:
> Bill Findlay <no_e...@invalid.invalid> writes:
>> How does that make sense?
>> You lose control by completely dominating It??
>
> re:
> http://www.garlic.com/~lynn/2017.html#81 The ICL 2900
>
> big disruptive innovation could provide unexpected opportunities for
> competition ... especially with huge changes in price/performance (it
> could easily mess up bottom line and profit margins) ... case in point
... blah blah blah ...

Nope, still doesn't make sense .

Jon Elson

unread,
Jan 28, 2017, 7:07:20 PM1/28/17
to
Yes, that one has had me scratching my head ever since I read it! I think
there has to be a bunch of other concerns that were really behind this.

First, the goal of the ACS was really not achievable with the technology of
the time. The plan was to have a 10 ns clock time with 7 levels of logic
between registers. The MST logic they were working on was almost as good as
MECL 10K, so about 1.5 ns propagation through the simplest gates, plus a bit
of wiring delay, and there's no way that goal could be met. They did
prototype a 12-bit counter (IIRC) that could clock at 80 MHz, but that would
be more like 4 levels of logic.

Second, IBM had no experience with mass-producing ICs. They were going to
build a machine that was basically a 3083, in 1968 or so! So, they were
pushing their ability to create the technology WAY beyond their abilities.

Also, I suspect by that time IBM had figured out that very limited
production of supercomputers was a way to lose money very fast. Clearly,
they worked very hard to make less ambitious machines in much higher
numbers, and did quite well at that.

Jon

Anne & Lynn Wheeler

unread,
Jan 28, 2017, 7:23:38 PM1/28/17
to
Jon Elson <el...@pico-systems.com> writes:
> Second, IBM had no experience with mass-producing ICs. They were going to
> build a machine that was basically a 3083, in 1968 or so! So, they were
> pushing their ability to create the technology WAY beyond their abilities.

http://www.garlic.com/~lynn/2017.html#82 The ICL 2900

this has description of 3081 ... basically FS simulator that was
extremely inefficient and manufacturing costs were much higher
... especially compared to clone competition
http://www.jfsowa.com/computer/memo125.htm

The 370 emulator minus the FS microcode was eventually sold in 1980 as
as the IBM 3081. The ratio of the amount of circuitry in the 3081 to its
performance was significantly worse than other IBM systems of the time;
its price/performance ratio wasn't quite so bad because IBM had to cut
the price to be competitive. The major competition at the time was from
Amdahl Systems -- a company founded by Gene Amdahl, who left IBM shortly
before the FS project began, when his plans for the Advanced Computer
System (ACS) were killed. The Amdahl machine was indeed superior to the
3081 in price/performance and spectaculary superior in terms of
performance compared to the amount of circuitry.]

... snip ..

FS posts
http://www.garlic.com/~lynn/submain.html#futuresys

the 308x originally was only to ship multiprocessors and never ship
single processor product. the problem was that ACP/TPF (airline control
program & being used for some financial networks) didn't have
multiprocessor support ... and they were afraid the whole ACP/TPF market
would move to clone makers (that continued to offer single processor
machine). There was quick&dirty effort to come out with 3083 by removing
one of the processors from 3081 (one of the 1st issues was processor0
was at the top of the machine ... just removing processor1 in the middle
would have made the machine dangerously top-heavy)

and
https://people.cs.clemson.edu/~mark/acs_end.html

Adding the third even smaller computer came out with normal profit! IBM
management decided not to do it, for it would advance the computing
capability too fast for the company to control the growth of the
computer marketplace, thus reducing their profit potential. I then
recommended that the ACS lab be closed, and it was.

... snip ...

Dan Espen

unread,
Jan 28, 2017, 9:43:08 PM1/28/17
to
Agree.

There was never any way that existing S3x0 customers were going to move to
any "future system" that wasn't compatible with what they were
using.

--
Dan Espen

Bill Findlay

unread,
Jan 28, 2017, 10:13:01 PM1/28/17
to
But Amdahl's (?) ACS/360 was meant to be compatible, wasn't it?

--
Bill Findlay

hanc...@bbs.cpcn.com

unread,
Jan 29, 2017, 1:58:19 AM1/29/17
to
On Saturday, January 28, 2017 at 6:13:25 PM UTC-5, Bill Findlay wrote:

> >>> executives then cancel ACS/360 because they were afraid that it would
> >>> advance the state of the art too fast and they would loose control of
> >>> the market.
> >> How does that make sense?
> >> You lose control by completely dominating It??
> > Well, perhaps IBM innovations could eventually be copied by
> > competitors... and then, IBM having ventured out to its ultimate
> > reach, would not necessarily be quickly able to come up with
> > something even better.

> Surely a comparative lack of innovation could be copied even more easily.
> As indeed it was.

I think that during the S/360-S/370 era, IBM generally was the
undisputed market-leader. It managed to stay ahead of the mainframe
competition by its marketing/suppport prowness. While it wasn't
known for technial leadership, it usually kept up.

Although it sounds counter-intuitive, I think IBM was correct in
holding back high-tech improvements until the market demanded them.

For an example, look at IBM S/360 tape and disk. IBM faced
competition, but it met it by coming out with improvements.

I knew a kid who played high school football. He would purposely
sit out lesser games to save his energy and avoid risk of injury
so he could play in the big games.


Morten Reistad

unread,
Jan 29, 2017, 7:44:55 AM1/29/17
to
In article <4a3133ce-8e9d-4811...@googlegroups.com>,
<hanc...@bbs.cpcn.com> wrote:
>On Saturday, January 28, 2017 at 6:13:25 PM UTC-5, Bill Findlay wrote:
>
>> >>> executives then cancel ACS/360 because they were afraid that it would
>> >>> advance the state of the art too fast and they would loose control of
>> >>> the market.
>> >> How does that make sense?
>> >> You lose control by completely dominating It??
>> > Well, perhaps IBM innovations could eventually be copied by
>> > competitors... and then, IBM having ventured out to its ultimate
>> > reach, would not necessarily be quickly able to come up with
>> > something even better.
>
>> Surely a comparative lack of innovation could be copied even more easily.
>> As indeed it was.
>
>I think that during the S/360-S/370 era, IBM generally was the
>undisputed market-leader. It managed to stay ahead of the mainframe
>competition by its marketing/suppport prowness. While it wasn't
>known for technial leadership, it usually kept up.
>
>Although it sounds counter-intuitive, I think IBM was correct in
>holding back high-tech improvements until the market demanded them.

IBM was an order of magnitude bigger than any of the competition.
The closet one was DEC at around 1/6th the size; and they didn't
make IBM compatible gear. And they arose a bit later.

IBM was the definition of the mainstream. They supported their
gear to great lengths. There were lots of organisations that used
some BUNCH gear, but they kept enough IBM gear that they could
depend on IBM support.

>For an example, look at IBM S/360 tape and disk. IBM faced
>competition, but it met it by coming out with improvements.
>
>I knew a kid who played high school football. He would purposely
>sit out lesser games to save his energy and avoid risk of injury
>so he could play in the big games.

If you ARE the mainstream then you must be on the appropriate
part of the technologican edge. Not quite up front, but not
lagging either. IBM did this quite masterly.

They also were fighting monopoly accusations in a lot of
markets, and had to let the BUNCH some leeway. They did quite
well here too.

-- mrr



Dan Espen

unread,
Jan 29, 2017, 9:32:35 AM1/29/17
to
Apparently a last minute change:

A decision by IBM in May 1968 to modify the project to support S/360
compatibility resulted in the name change from ACS-1 to ACS-360 for the
computer being designed.
...
The ACS-360 project was canceled in May 1969;

So, 1 year trying to include compatibility then they threw in the towel.
But those same "disruptive" changes did go to market:

however, many of the innovations resulting from the project would
eventually find direct realization in the IBM RS/6000...

Lynn has characterized the FS project as one that put a halt to
S/360 software/hardware enhancement.

--
Dan Espen

jmfbahciv

unread,
Jan 29, 2017, 9:52:52 AM1/29/17
to
<snip ref-list>

The guy who wrote DEC's software project notebook later said that the
goal of the notebook was to cause all development to slow down. This
guy stated this at a talk JMF attended at DEC in the late 80s.
I furious at JMF for not asking the guy why it had to be slowed down.

The sotware project notebook outlined all the requirements for starting,
conducting and shipping any software project. I typed the first edition.
By 1984, the notebook had grown 10,000%.

So, it was something done at more than one computer manufacturer.

/BAH

Jon Elson

unread,
Jan 29, 2017, 1:50:05 PM1/29/17
to
jmfbahciv wrote:


>
> The guy who wrote DEC's software project notebook later said that the
> goal of the notebook was to cause all development to slow down. This
> guy stated this at a talk JMF attended at DEC in the late 80s.
> I furious at JMF for not asking the guy why it had to be slowed down.
>
Well, we were talking mostly hardware, not software. But, slowing down ACS
until the technology was not a HUGE leap would have been good. They would
have had to come out with the 370 or continued extending the 360 line at the
same time. But, the premise of the ACS was that is was to REALLY stretch
the technology, going from discrete transistors on air-cooled SLT modules
all the way to ICs packed on thermal conduction modules with direct water
cooling, with some hundred+ ICs all on one ceramic interconnect.
That's a HUGE leap in technology. And, if it went badly, it would cause
HUGE harm to IBM. Also, the field support system would have to move from
carrying a bunch of small boards that were common to most 360 machines to
having gigantic, multi-thousand $ complete CPU modules which had to be
replaced as a single field replaceable unit.

I think that slowing down and making a much more modest jump in the
technology was a very wise decision. Going to the 360/85 (ICs and indirect
water cooling) and the model 195 was a big enough jump. Someone on here a
month or two ago mentioned they used 360/85s internally to IBM, and theat
they were not reliable. I believe most (maybe all) of the /85s were used at
NSA, and don't think they would have tolerated poor reliability. So, maybe
those units used internally were first production models and never got some
important upgrades. The 360/85 was the prototype for the 370/165, and was
pretty close to the actual 370/165 hardware. I think a major difference was
the /85 was built with 16-bit SRAM chips, and by the time the /165 was made,
they had progressed to 64-bit SRAMs. The SRAM was used in the storage
buffer (cache) as well as the writable control store. The /85 had fixed
control store derived from 360/50 and /65 capacitive ROS technology plus 500
words of writable control store. I think the /165 was all writeable.
Anyway, the 370/165 and /168 were VERY successful models, and my experience
with a /168 was it was one of the most reliable IBM mainframe systems in at
that time. (Of course, the DAT environment on the /168 allowed them to
close a whole bunch of holes in the OS that had been responsible for lots of
unreliability, too.)

Jon

Anne & Lynn Wheeler

unread,
Jan 29, 2017, 2:23:21 PM1/29/17
to
Dan Espen <des...@verizon.net> writes:
> Apparently a last minute change:
>
> A decision by IBM in May 1968 to modify the project to support S/360
> compatibility resulted in the name change from ACS-1 to ACS-360 for the
> computer being designed.
> ...
> The ACS-360 project was canceled in May 1969;
>
> So, 1 year trying to include compatibility then they threw in the towel.
> But those same "disruptive" changes did go to market:
>
> however, many of the innovations resulting from the project would
> eventually find direct realization in the IBM RS/6000...
>
> Lynn has characterized the FS project as one that put a halt to
> S/360 software/hardware enhancement.

http://www.garlic.com/~lynn/2017.html#84 The ICL 2900

Amdahl was working on 360 compatibility from the start ... but was
"disregarded" ... it wasn't until 1968 that he won the "shootout" with
the ACS-1 faction.

the description has the ACS-1 group designing a non-compatible machine,
it was Amdhal that was responsible for a 360 compatible ... and various
folklore talks about shoot-out between ACS-1 and ACS-360 ... with Amdahl
winning. Amdahl extended ACS-360 design to also include 1/3rd speed and
1/9th speed to address the whole 360 makret (rather than just high end
supercomputer). reference to "shootout"
https://people.cs.clemson.edu/~mark/acs_end.html

Amdahl: We ended up having a shoot-out. The two of us who did the
360-compatible version won. We established that in fact we could achieve
more performance at lower cost.

...

Bob Evans came out to ACS with about five technical people and they held
a shoot-out. We won and I was made the lab manager. The first thing I
did was have the two smaller computers costed. I then submitted the
three system plan to corporate pricing. The single highest speed
computer was a loss leader. The second smaller computer added made a
break-even program. Adding the third even smaller computer came out with
normal profit! IBM management decided not to do it, for it would advance
the computing capability too fast for the company to control the growth
of the computer marketplace, thus reducing their profit potential. I
then recommended that the ACS lab be closed, and it was.

... snip ...

and
https://people.cs.clemson.edu/~mark/acs.html

Amdahl's opinions about the advantages of compatibility were disregarded
in 1965, and by 1967 he was quarantined by the ACS leadership because of
his continued advocacy for compatibility. In early 1968, he began
discussing a compatible design with John Earle, who sketched out a
five-gate-level pipelined implementation. In May 1968, IBM east-coast
management approved a "shoot-out" between ACS-1 and AEC/360 (the
"Amdahl-Earle Computer" proposal).

Amdahl and Earle won the shoot-out, and a decision was made to convert
the project to S/360 compatibility. Gone were the extended floating
point formats and the unique ACS-1 instruction set design. Several
members of the hardware and software architecture team left at this
point, but the project continued under Amdahl's leadership. The
compatible design was called the ACS/360, and several of the ACS
innovations undergirded the design. For example, like the ACS-1, the
ACS/360 was planned as the first computer with multiple instruction
decoding and issue, and it would also have been the first to use a
branch target buffer (called at that time "prefetch sequence control
registers").

In May 1969, IBM east-coast management rejected Amdahl's plan for three
ACS/360 models, and the project was cancelled. However, the legacy of
the ACS project extended beyond the cancellation, although sometimes
without recognition that the ideas were developed as part of ACS or
descended from ACS work. Some of these ideas include multiple condition
code registers, dynamic instruction scheduling techniques, numerous
compiler optimization techniques, branch target buffer design, I/O to
cache techniques, MECL-III high-speed ECL circuits, scan-out and FRU
(Field Replaceable Unit) techniques.

... snip ...

Ferguson/Morris 1993 "Computer Wars: The Post-IBM World"
http://www.amazon.com/Computer-Wars-The-Post-IBM-World/dp/1587981394

Describes Future System was completely different and was going to
completely replace 370 ... and 370 efforts were being shutdown ... and
the lack of 370 products during the period allowed clone processors to
gain market foothold.

The rise and fall of IBM (by senior IBM executive)
http://www.ecole.org/en/seances/CM07

Talks about the major motivation for Future System was competition from
clone controllers, the objective was to so change the architecture and
make the interface between processor and I/O controllers so complex that
there would be no (easy) entry for clone controllers.

past FS posts
http://www.garlic.com/~lynn/submain.html#futuresys

I've posted before about doing clone controller as undergraduate
at the Univ. starting with Interdata/3 ... and four of us getting
written up for (some part of) clone controller business. It
evolved into Interdata/4 (handling channel interface) and cluster
of Interdata/3s handling port/line scanner function. past
clone controller posts
http://www.garlic.com/~lynn/subtopic.html#360pcm

I also periodically tell the story about Amdahl having seminar in large
MIT auditorium in the early 70s talking about his new clone mainframe
company. At one point somebody in the audience asked how he convinced
the money people to back his company. He replied that even if IBM walked
completely away from 360, there was enough customer 360 software it
would keep him in business through the end of the century. This sort of
implies that he knew that Future System was in the works, but he claims
that he didn't know anything about it. He was also given bad time with
questions about becoming almost totally foreign company (with major
ownership and all manufacturing from outside the country).

and ... I periodically contend that John Cocke
https://en.wikipedia.org/wiki/John_Cocke

He is considered by many to be "the father of RISC"

... snip ..

started designing 801/risc during Future System period that would
be the exact opposite of the Future System complexity. I joined
the RS/6000 group in the 80s ... and my HSDT project
http://www.garlic.com/~lynn/subnetwork.html#hsdt

is credited with helping bring the RIOS chip design in a year
early. HSDT had 7M satellite dish next to the engineering bldg in Austin
and 4.5M dish in Los Gatos running high-speed satellite links. Austin
group used the link to constantly ship design to the logic simulators
(for validation) in Los Gatos and San Jose.

I then had the HA/CMP doing RS/6000 high availability and cluster
scaleup for both commercial and scientific/technical
http://www.garlic.com/~lynn/subtopic.html#hacmp

also
https://people.cs.clemson.edu/~mark/acs_end.html

Sidebar: Multithreading

In summer 1968, Ed Sussenguth investigated making the ACS/360 into a
multithreaded design by adding a second instruction counter and a second
set of registers to the simulator. Instructions were tagged with an
additional "red/blue" bit to designate the instruction stream and
register set; and, as was expected, the utilization of the functional
units increased since more independent instructions were available.

... snip ...

I've periodically mentioned that I got sucked into effort to do
multithreaded 370/195 (that was never announced or shipped).

and

Sidebar: ES/9000 high-end processors

The ACS/360 structure appears to have influenced the design of the IBM
ES/9000 high-end ("520-based") processors some twenty-odd years
later. The ES/9000 high-end processors were structured as:

I-decoding

128 KB I-cache
4 K entry BHT; presence of branch in BHT indicates predict-taken
five 64-bit instruction buffers
ability to decode up to two instructions per cycle (e.g., a branch can
be decoded in parallel with preceding instruction but not with following
instruction)
instructions tagged with two predicted-branch-path bits

ACE, with three effective address adders

I-ACE with two-entry queue; can execute LA instructions on its own
D-ACE with four-entry queue
SXE-ACE

BXE, for controlling branch prediction and resolution

can execute BC instuctions on its own

GXE, for executing fixed-point instructions

six-deep instruction queue, which can start up to two instructions per
cycle in certain cases (e.g., one instruction has a general register
result and the other has a storage result)

FXE, for executing floating-point instructions

six-deep instruction queue, which can start up to one instruction per
cycle

SXE, for executing the storage-to-storage, decimal, and system control
instructions register renaming

32 32-bit physical fixed-point registers (for 16 architected registers)
16 64-bit physical floating-point registers (for 4 architected registers)
two backup register assignment lists kept, one per predicted branch path
(i.e., provides branch misprediction recovery)
ability to complete (i.e., retire) up to two instructions per cycle
synchronous interrupts recognized when instruction completes

... snip ...

Anne & Lynn Wheeler

unread,
Jan 29, 2017, 2:33:18 PM1/29/17
to
Anne & Lynn Wheeler <ly...@garlic.com> writes:
> The rise and fall of IBM (by senior IBM executive)
> http://www.ecole.org/en/seances/CM07

oops ... gone 404 ... don't know where it moved, but
at wayback machine
https://web.archive.org/web/20160410090830/http://www.ecole.org/en/seances/CM07
It is loading more messages.
0 new messages