Re: The Design of Design

Thomas Koenig wrote:

Stephen Fuld <SFuld@alumni.cmu.edu.invalid> schrieb:

Thomas Koenig wrote:
 

John Levine <johnl@taugh.com> schrieb:
 

They had the insight to see that the 16 fixed sizs registers

could >> > be in fast storage on high end machines, main memory on
low end >> > machines, so the high end machines were fast and the low
end no >> > slower than a memory-memory architecture which is what it
in >> > practice was. It was really an amazing design, no wonder it's
the >> > only architecture of its era that still has hardware

implementations.

 
 
Yes, although it isn't clear how much of its success is due to
technical superiority versus marketing superiority.

 
"Put a bullet through a CPU without missing a single transation"
is also a technical achievement :-)

True.  But that is a relativly recent achievement.  Long after IBM's
mainframe dominance.

 
I recently heard (but did not find a source that IBM did RAID on some
of their caches.
 

Prompted by a remark in another newsgroup, I looked at IBM's 2023
annual report, where zSystems is put under "Hybrid Infrastructure"
(lumped together with POWER).  The revenue for both lumped together
is around 9,215 billion Dollars, with a pre-tax margin of more
than 50%.
 
At those margins, they can certainly pay for a development team
for future hardware generations.

 

Yes, but remember that includes softwre revenue, which has higher
margins than hardware revenue.  I believe I saw somewhere that IBM
made more from MVS, DB2, CICS, etc.

 
SAP S4/HANA is going to hurt their bottom line, then.  Earlier
versions of SAP could, I understand, run on zOS and DB2, S4/HANA
requires SAP's in-house database and requires Linux.
 

than they do on the hardware itself.  So
one could argue that they have to develop mew hardware in order to
protect their software revenue!

 
Sounds reasonable, and the reverse of what they did in the
(far-away) past.

Yup.  I remember when the woftware was free!  Amdahl and the other
PCM's forced that to change.





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