One of the wisdoms I got from my education at HP Germany was "quality is tested into hardware". And with any real software, it is exactly the same. Or maybe should I say "even worse" ? The biggest investment is always testing, bug fixing, validation programs, test vectors, test vector generators, code reviews and so on. Initially the HP MPE operating system was very unreliable, but decades of bug fixing and refining made it into one of the most reliable operating systems.

Muharg. In Java you can't have arrays of structs. You can have an array of references which points to your 25 million individually allocated heap objects. Which is both a runtime and a massive storage overhead. Plus, it destroys your cache efficiency.
So, get off my lawn and stop saying stupid things in the presence of grown-ups !

I think you meant "Cobol programmers are on average 72 year old, bearded virgins" ?

Typo: must read "RDBMS"

Tell that to the armies of OLAP developers/analysts. They believe their RBBMS nail will answer all analytics questions. Just recently they have rediscovered batch-mode analytics and call it MapReduce. See TeraData Aster. How do you need ACID for a read-only database ???

Oh, yeah, score a point by making a different argument. Seymour Cray literally owned the supercomputer business (NSA, LLNL and that type of thing) until he died. Just recently IBM does some sort of supercomputing business again, but these are NOT mainframes. IBM supercomputing are massive clusters of Power CPUs. If Seymour Cray still lived, I am sure IBM would NOT be in supercomputing.

Well, I do think we have to differentiate between implementation quality, conceptual quality and manufacturing quality. The first one is definitely not very good on IBM mainframes. They are shipping products with much more bugs than Intel, HP or their own Power Unix people do. But the mainframe concept of a large centralized machine with lots of failure detection, failover, management, virtualization, massive I/O, clustering and so on is solid.
Just looking at the hardware and software cost is very short-sighted. Factor in operating, management, custom software development cost and the picture looks different. For example, if you don't have proper job control facilities, a single user can monopolize the system by accident and affect lots of different user groups/applications on the same system. Raw horsepower is only one of many important aspects.

As a qualifier, maybe the mainframe IBMers are especially shoddy. We never had these problems with their Power machines. These were actually excellent Unix machines - fast, reliable, very high quality. But DB/2 and mainframe, not so much. Thinking about it, maybe it indeed is a deliberate tactic to force customers into expensive support contracts.

Maybe you just read what I write: IBM delivers shoddy quality which must be fixed by their field engineers. MS does have their fair share of bugs, but they are definitely not as bad as IBM. So does Intel - their processors at least don't crap out on the integer operations.
IBM is a company dominated by the sales and finance guys. Technology is very much a nuisance to them, which they only need to make $$. At MS and Intel, there seem to be some technologists at the critical posts, even though the MBA-In-Chief of MS appears to "change" that, recently.

The difference is that I can get the typical MS product running in a reasonable manner without the aid of an MS field engineer. For example, when DB/2 competes against SQL Server, developers will disregard DB/2 quite early when they can't get proper connect times without the help of the IBM field engineer. Maybe DB/2 is actually better than SQL Server on the long run, but there won't be a long run because initially it looks like a very bad product.

If they ever let me close to a Cobol system, I am sure it will be infested with macro-based generic data structures pretty soon. There is a need for a Cobol Standard Library (of my own invention), I am quite positive !

Not entirely correct. Thomas Watson once decided to take out CDC and build a supercomputer. IBM would badmouth CDC "in support of our future machine". It turned out the single guy Seymour Cray beat the crap out of the army of IBM engineers.
Mr Watson was pissed but from then on focused on mainframes, not supercomputers.
Always good to see that a single capable and determined man can stand up to the sleazy multi-billion corporations and win !

Uhhm, Google and Facebook prove your arguments. It's all about business, forget these stupid CS and math courses.

At this point, Google CAN afford ccNuma. Facebook, too. Apparently, it still is not cost-efficient. Or there simply is no competitive pressure to go ccNUMA.
Actually, MapReduce is all the rage with companies like TeraData, who had an affiliation with BigIron in the past.

Actually, my impression of IBM is that they deliver quite crappy technology on a regular basis, because "we can fix that later on". Cynical colleagues suggested this being a business strategy with the objective of selling support. At a former employer we discovered a broken integer division instruction. When demonstrated to the IBM field engineer, they finally agreed to fix it by means of a microcode update.
Just recently I fought with DB/2 and only the field engineer could help this time, again.
IBM was always very much sales/service oriented and they still cannot compete with the "shrink-wrapped" companies like MS and Oracle. IBM is a relic of the past and will soon be history because it is simply much more efficient to perfect a product once instead of sending a field engineer to each and every customer to clean up the problems they haven't fixed during R&D time.