Sun and Solaris weren't around back in COBOL's heydey (well maybe they were at the tail end of it) so that makes sense. COBOL is only really still popular on mainframes because a lot of core early buisness data processing code was written there in COBOL. So much in fact that it's basically impossible to manually rewrite (not to mention the performance hit if you rewrite it in something like Java which seems to be the "new COBOL" in terms of being super vanilla and business-y, or you use an automated rewriting tool which you might imagine is going to come out pretty nasty looking).
There is a big niche of hooking all of that stuff up with modern frontends and running it remotely via browser interface and maybe a Node server on a mainframe and that sort of thing. That is how you end up with projects like this. The author jokes about it being ready for production, but I'm not joking I have really seen some stuff not dissimilar from this running in production, but with it calling the IBM Enterprise COBOL compiler instead. Doesn't look like it's supported here but it could be modified trivially to run on a real mainframe, just change the name of the executable it's calling and handle the case of a different path format when given a path outside of the Unix file system (there is a Node library already that can handle this, or you can compile C code since weird path support is provided by C libraries as well and can be made into a native node extension).
A more interesting discussion might be had about dynamic linkage and how that works in mainframe COBOL environments and how it's different from C environments. And in particular how that all fits together with transaction monitor systems, which are like very primitive containers. The closest comparison would be AWS Lambda functions and other serverless abstractions. A lot of COBOL actually looks like serverless, with lots of small very modular programs that link and load each other dynamically, which is part of why there was a tendency to reject some aspects of structured programming. I've seen apps that use too much serverless that feel a lot like classic COBOL spaghetti code.
Anyways, that's my big bunch of stuff I know about COBOL, which is quite a lot but unfortunately have never had much opportunity to write it.
There is a big niche of hooking all of that stuff up with modern frontends and running it remotely via browser interface and maybe a Node server on a mainframe and that sort of thing. That is how you end up with projects like this. The author jokes about it being ready for production, but I'm not joking I have really seen some stuff not dissimilar from this running in production, but with it calling the IBM Enterprise COBOL compiler instead. Doesn't look like it's supported here but it could be modified trivially to run on a real mainframe, just change the name of the executable it's calling and handle the case of a different path format when given a path outside of the Unix file system (there is a Node library already that can handle this, or you can compile C code since weird path support is provided by C libraries as well and can be made into a native node extension).
A more interesting discussion might be had about dynamic linkage and how that works in mainframe COBOL environments and how it's different from C environments. And in particular how that all fits together with transaction monitor systems, which are like very primitive containers. The closest comparison would be AWS Lambda functions and other serverless abstractions. A lot of COBOL actually looks like serverless, with lots of small very modular programs that link and load each other dynamically, which is part of why there was a tendency to reject some aspects of structured programming. I've seen apps that use too much serverless that feel a lot like classic COBOL spaghetti code.
Anyways, that's my big bunch of stuff I know about COBOL, which is quite a lot but unfortunately have never had much opportunity to write it.