Earlier quoted context omitted.
> If they haven't actually done it by now, it's a management problem, and no AI tech is going to fix that. This. Further, it’s a failure to continue to disincentivize roles that will support or port this business critical logic to something else. I worked at a large insurer where they slowly laid off mainframe talent over the last decade. Those mainframe salaries were counter to the narrative they were promoting arou…
> it's a management problem, and no AI tech is going to fix that. There are no absolute "management problems". Something that is a management problem when the effort required is 1000 man-years, may stop being so when it's only 100 man-days.
So you've got a situation at a lot of places where you'd need to replace 50%+ of your staff if you wanted to convert to modern tooling, while at the same time it is harder and harder to replace the staff that leave and know the old set of tools. That cannot continue indefinitely. And until you cross some invisible threshold in the number of people that are comfortable in a modern software development environment, things can continue like they are for a long time.
Ultimately this is driven by the strange (for the tech industry) demographics of mainframe teams, in that they are often still dominated by people that entered the industry before microcomputers were ubiquitous. They may only know "the mainframe way" to do things, because they entered the industry the old-school way by stacking tapes in a data center or moving up from accounting, back before CS degrees and LeetCode and all that. It's only like that in mainframe shops because everywhere else has had massive growth (as in from 0 -> however many programmers they have now) and skews much younger as a result of computing not even having been adopted in any significant way until (for example) the late 80s/early 90s.
It's this cultural aspect of Mainframes (due to the history of being the oldest computing platform still running in production) that remains mostly unexamined and is not well understood by those on the outside. These are unique challenges that mostly don't have to do with the well known and arguably solved problem of "how can I convert some COBOL code into logically equivalent code".
One final point is that COBOL is ruthlessly efficient (equivalent in speed to C, sometimes with more efficient use of memory for particular kinds of programs it is specialized for) in a way Java is not. Java is only popular on mainframes due to the licensing advantages IBM was forced to give out due to the much higher resource usage, and because their JVM is actually a very good implementation and well-liked by people on non-mainframe teams. If everything starts moving to Java though, I bet those licensing advantages probably go away. So I think more needs to be invested in C/C++ and possibly Go, rather than Java, at least initially. It is possible to write both of those portably and not suffer the huge performance penalty implicit in moving to a Java stack. I suppose this in particular may just be due to me being several years removed from web development, and some of the mainframe attitudes towards code have started to rub off on me.