4 ms·

OK, cool science project and all, but . . . why? The problem in COBOL land isn't being able to execute snippets embedded in another language. It's a) migratin

OK, cool science project and all, but . . . why? The problem in COBOL land isn't being able to execute snippets embedded in another language. It's a) migrating the COBOL to something else before all the devs who know it retire/die and b) getting stuff on to commodity hardware or other solutions as things like Solaris aren't supported anymore.

system16 3y ago
Strange comment for Hacker News. Maybe the author wanted to learn more about COBOL and this was a fun way to explore that and share their findings. Not every personal project needs a business case to justify its existence.
- refulgentis 3y ago
  It was a good question to ask, and they have a strong nose for when there's a missing factor in an explanation: GP, it's a joke about Next.js abusing a language keyword to make it easy to in-line server side code in client code via require ("server"), there's been an explosion in memes about it over the last day Sorry people got personal and berated, I really do mean it when I say you have a good nose for a missing factor
kome 3y ago
"but . . . why?" because he can.
zabzonk 3y ago
as someone who used solaris on big servers quite a lot, i never saw any cobol there. not to say it doesn't exist, but it would be somewhat unusual.
- johnbellone 3y ago
  There's a lot of COBOL on the zSeries/pSeries/iSeries platforms. I haven't seen too much on SPARC, but that doesn't mean it doesn't exist.
- auajjrjhappy 3y ago
  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.

system16 3y ago

Strange comment for Hacker News. Maybe the author wanted to learn more about COBOL and this was a fun way to explore that and share their findings. Not every personal project needs a business case to justify its existence.

refulgentis 3y ago
It was a good question to ask, and they have a strong nose for when there's a missing factor in an explanation: GP, it's a joke about Next.js abusing a language keyword to make it easy to in-line server side code in client code via require ("server"), there's been an explosion in memes about it over the last day Sorry people got personal and berated, I really do mean it when I say you have a good nose for a missing factor

kome 3y ago

"but . . . why?" because he can.

zabzonk 3y ago

as someone who used solaris on big servers quite a lot, i never saw any cobol there. not to say it doesn't exist, but it would be somewhat unusual.

johnbellone 3y ago
There's a lot of COBOL on the zSeries/pSeries/iSeries platforms. I haven't seen too much on SPARC, but that doesn't mean it doesn't exist.
auajjrjhappy 3y ago
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.