No revisit is necessary after 8 years. The structural issues with linux on the mainframe are exactly that- structural. How aboout this- go into real mainframe shops in mainframe-committed businesses like insurance, transit reservations, banking, and so on, and find out what the core business transaction systems run on. It won't be linux, and for manifold good reasons, mostly related to RAS. Linux has nothing even remotely resembling the abilities in Parallel Sysplex(zOS), but there's no need to escalate to that- even the most basic device error recovery management in a mainframe operating system is better handled than in Linux.

And by the way, the assumption that with the progression of years comes inherent improvement in technology is by no means a certainty, especially in computing. Ask someone who knows anything about Keykos whether today's operating systems have incorporated even half the concepts they got right. Oh wait- let me not forget- Keykos and many other earlier operating systems aren't covered in a typical CS operating systems course, but that must be because the 'experts' have deemed them irrelevant. The same 'experts' ignore TPF/zTPF as well, which have been happily doing transit reservation systems for over 40 years. So much for progress inherent in the march of years.

There are a number of factors which go into this consideration of Linux on the mainframe. I must admit it was really cool when I first learned of it, having had an MP3000 to myself at an IBM training facilty to learn how to bring up VM/ESA and Linux/390(2001). Then I realized a few things like:

1. Linux cannot take advantage of the advantages of channel-based disk i/o, because it uses Unix i/o approaches which can never be as efficient as the traditional mainframe-based approaches. No one has shown me any evidence that Linux does anything particularly intelligent in its channel program construction and management. Linux assures that IBM can happily sell lots of IFL or general purpose CPUs which are necessary to compensate for this inefficient use of
mainframe resources.

2. Managing workloads under zVM can be great and is extremely well refined, but this requires zVM-specific skills which supposedly no one wants to pay for.

3. For transaction-based work, it's hard to beat TPF/zTPF, but unfortunately that requires some real mainframe skill to implement. And regrettably, zTPF requires Linux and zOS because IBM refuses to convert the programs running on zOS to run on Linux instead. Since TPF/zTPF and zOS both involve onerous monthly licensing charges based on capacity, it's no wonder that TPF/zTPF languish in relative obscurity.

SAP closed-sourced SAPDB/MaxDB.

They never provided anything resembling a decent explanation as to why.

I can't understand why anyone is surprised that people trained in computer science are ill equipped to develop
business software.

How many computer science graduates typically have the slightest clue what accounting is, or how it works?

How many computer science undergraduate programs deal with the customary and legal environment of
business?

How many computer science programs deal with the realities of designing and maintaining a datacenter,
in theory and/or practice?

Computer science is a theoretical self-serving discipline designed to produce more computer science
graduate students. Anyone who learns practical, appropriate, and customary reality does so more
often despite rather than because of their education.

Time for a radical reassessment.