> The recent Delta Airlines system outage and the prior Southwest outage are pointing people to blame their antiquated technology and infrastructure. In particular, a lot of these so-called technology experts point their fingers at airlines’ IBM mainframes running z/TPF as part of the cause of their troubles. The problem is that none of these “experts” seem to have ever done any work on a mainframe and only have a passing understanding of z/TPF if they have any understanding of it at all.

https://www.linkedin.com/pulse/mainframes-problem-solution-j...

This link is a gem. It is very revealing of the dynamics of arguments over software in the airline industry.

> A number of financial institutions have discovered and acknowledged this fact and are now taking the first steps to address this situation by making the decision to go back to z/TPF, z/OS and UNIX because of their bulletproof reliability and transaction processing capabilities. This to the chagrin of the bulk of their application development staffs who are bolting out of these organizations for the more sexy technology environments. Yes, IBM Assembler, COBOL and other antique languages are making a resurgence at these brave organizations as they supplant and even replace Java, .NET, Python and other development environments.

Back to the good old days of IBM Assembler?!

Are they ditching source control and unit testing too?

> Back to the good old days of IBM Assembler?!

High Level Assembler to be correct. But kidding aside, the slide 40-41 is interesting http://www.ibm.com/software/htp/tpf/tpfug/tgf18/TPFUG_2018_M...

I used to work at a healthcare company where about 1/3 of the development staff worked in RPG and COBOL day-to-day. A consultant came in to pitch them on a COBOL source control system, and from what I heard they had to spend most of the time explaining to these 60+ year olds what source control was before pitching the management on a 7-figure implementation for what was basically timestamped folders with copied of code inside.

When I left that company a few years after that, there was still no source control for the RPG or COBOL code.

I have to chime in and display my ignorance: what makes RPG or COBOL so special that git or mercurial could not simply be used for source control?

Technically, nothing.

"Using Visual COBOL in Modern Application Development" https://www.microfocus.com/documentation/visual-cobol/visual...

I know a large organization which has a lot of code in an Oracle cluster. No version control, no tests, no development environment.

OK not being z/TPF expert the "the world's largest TPF-based systems are easily capable of processing tens of thousands of transactions per second, three billion per day. TPF is also designed for highly reliable, 24-7 operation." This totally reasonable workload for RDBMS system does not look like you specifically need z/TPF to handle the transaction volume.

It depends on transactions obviously (among many other factors). MySQL would handle simple one-insert web-style ones pretty well. At the same time very simple (but slightly more realistic) read-write transactions barely got 2500 tps on PostgreSQL with Xeons and SSDs with as low as 32 clients and almost no contention at all (https://blog.pgaddict.com/posts/performance-since-postgresql...). And all transactions were the same, and there were no long-lived ones, no distributed ones, and no rollbacks, and so on.

http://www.tpc.org/tpcc/results/tpcc_results.asp?print=false....

How exactly TPC-C v5 synthetic benchmark transactions related to the Delta Airlines backend transactions? Yes, that's somwewhat toyish 'business application' sketch benchmark. The goal of any benchmark is to be the same for all participants to compare them - staying aside the question what exactly the results tell about one or another particular system.

No company outside of exceptional circumstances will give you their actual data and workloads so some generic data points are useful. It's also pretty obvious that number of transaction Delta is handling is few orders of magnitude less than say Walmart. To me the point that conventional RDBMS can not handle transactional workload of Delta sounds like total BS.

You do realise that it is a tiny box with really crappy SSD BTW? You can get an x86 box with 12TB RAM 200+ cores and RAID over a bunch of Enterprise NVMe SDDs for 350K.

That's nice, and you can get a 1,000,000 tps on the shelf POWER8 server if you wish (on simple select-only requests, after tuning and patching the PostgreSQL core by a couple of the best PostgreSQL hackers in the world - yes, using carefully crafted assembler, no less https://akorotkov.github.io/blog/2016/05/09/scalability-towa...).

That wouldn't make that server competitor neither for IBM Parallel Sysplex, nor even for Oracle Exadata.

Oracle Exadata is not a mainframe which once more underscores the point of not having to use a mainframe.

That post is a horrible mess of subjective misinformation by someone almost certainly involved in the mainfraim business.