I think there are two parts to this I should address: Yes, there are frames that go on top of COBOL. But a lot of the reasons to actually use COBOL come down

I think there are two parts to this I should address: Yes, there are frames that go on top of COBOL. But a lot of the reasons to actually use COBOL come down to: - there are 300+ applications on your mainframe, and each has an interface, associated queues, code table, and calling conventions which are specified in COBOL - correctness of solution, and proving it correct - the field twiddling decisions based on data are low level, "inspect field A, do X, else do Y, afterwards save A2 and send message B", that doesn't appear to leverage well into a higher language - tooling on the mainframe supports COBOL quite well, there is a lot of infrastructure which very very smart people have put in place over the last several decades So there's a lot reasons why COBOL "fits" in the current space. It's not cool though. And that inertia is worth multiples of billions of dollars in invested time, and replacement costs for like-with-somewhat-better can easily hit trillions of dollars. I don't really want to do the envelope math, because some applications are ~1 million, and some are 100-250 million to replace. The HR issue is clearly something that organizations know about, and have been trying to address for literally decades. COBOL was passe in 1995, and 2000, and still is, but as an industry we're still addressing this issue in 2020. The other aspect of your question that I'd like to address is: why not program in COBOL? What does a code generator give you? what are you gaining? I'm trying to ask a question about mentality towards COBOL. COBOL can be compiled just like any other language down to efficient byte code. If we had a supposed "10x DevOps program engineer", what makes COBOL something that they couldn't master and leverage in a month? The experiences gained wouldn't simple be "COBOL programming", it would be an entire development and run environment, release and CI approaches, etc. All that said, I had the opportunity to work in COBOL, and I passed on it, so I can understand as an average programmer why not to work in it.