I know it isn't cool, but I often wonder if anyone will come out with a language that isn't meant to be the next C but the next COBOL, RPG, etc. I wonder if anyone has a LLVM backend for z/Architecture and TIMI.
That’s a problem I’ve occasionally considered working on—modern alternatives with tractable, incremental migration paths away from COBOL/RPG/MUMPS—but I hardly know where to begin.
I’m sure for a lot of these companies, due to the sheer size and often mission-critical nature of these systems, the cost analysis still comes down on the side of keeping the COBOL/&c. systems and just using new tooling around them, like static analysers, integrations with frontend frameworks, ways to interoperate with relational databases, and software emulation of mainframes.
An alternative would be not only difficult to build but hard to sell. There’d probably be a lot of money in it if you had
a team with the financial runway, technical skills, and market connections to do it, though.
I've thought about it a bit, and I do wonder if defining a VM and compiling the COBOL/RPG/MUMPS to it first then building the language off that. The languages are pretty straight forward and defining a decent high level VM instruction set would probably help with the not only the conversion but provide some assurance that you didn't miss something important.
There is documentation for the MI instructions, but that generates an OPM program and not an ILE program on IBM i. Sadly the TIMI isn't really documented anywhere - as well as ILE.
I have written an RPG3 interpreter with all the Record Level Access operations working on a noDb/flatfile in C#, but lost the source after replacing a hard disk. I have also tried writing a RPG4+ (only free format) compiler for .NET, but it started getting tricky when starting to write the RLA operations because they relied on a database. I have the code still, but it's ugly so I never released it.
Would be a fun project, for sure. Not enough hours in the day.
And then weeks debugging the phantom problems caused by the overuse of global variables that COBOL more or less mandates... I feel your pain, brother.