I work on mainframe, specifically on a tool for tracing large applications running on z/OS systems. I don't completely agree with the conclusion. It's true tha

I work on mainframe, specifically on a tool for tracing large applications running on z/OS systems. I don't completely agree with the conclusion. It's true that MF tech stack (z/OS, COBOL, CICS, DB2, ..) has many warts and is not fashionable. But I think you can write applications for it in the modern way if you want to; I think the backward-compatibility allowed IBM to focus on continually improving the stack rather than chasing latest fashion. As someone quipped, these little COBOL programs communicating in CICS MRO do resemble microservices or lambdas, and JCL/RDO is just infrastructure as code. So many of the "modern" concepts have been there for decades now, and they let you do transactions very reliably. But I want to point out, interestingly, what gives us real headache are the modern applications that are NOT COBOL. They tend to call databases with dynamic SQL (basically the plan is created during execution), and this makes the undesired application changes quite difficult to trace. In old-fashioned COBOL applications, you compile your query plans with your application, and that makes the performance more predictable. So I wouldn't be surprised if traceability is a big thing that COBOL and MFs have still going for it. There seems to be more middleware tooling for that, and things have been standard for many years. Unix tools seem to be more fragmented, although I have no doubts there is lot of good commercial tools. In cloud, everything seems to be even more tied to a single vendor than mainframes - I am not even sure if it's possible to run 3rd party utility on your deployment. It looks like if you really want traceability you have to do it yourself. Overall, I think MF stack is very decent (although not so shiny on the outside) and I wish IBM would promote it more.