Learning COBOL, even in a "real" environment, isn't going to be the jumpstart that you're hoping for by itself.
Beware, maintaining those systems is absolute hell and the companies experiencing exodus are working their people into the ground because the workload is crushing them and they can't find replacements.
A good friend of mine is an engineering director at a company that runs a massive COBOL mainframe platform and he always half jokes with me about picking it up. The money isn't that great at his company and the problems they have maintaining the system just blow my mind. The entire company sounds fundamentally unsustainable long term but they're running critical payments infrastructure.
I'm thinking of the Elixir->COBOL like this: https://github.com/TheFirstAvenger/cobol_to_elixir
Was speaking with the author about a year ago and he was having really good success with it.
Where you're going to hit major issue is with COBOL running under the likes of CICS or IMS, where sure, you can use some more recent languages, but what you'll get in the end will be possibly even worse because now you'll have to find Java programmer who knows CICS.
And CICS or IMS aren't that easy to replace.
I like this idea of writing Elixir and outputting COBOL. That way it can interface with the operating environment (CICS, IMS) exactly as a natively written COBOL program does. Not that COBOL syntax is particularly hard to learn one by one, but as a whole isn't very memorable. Why learn a programming language with peculiarities like a natural language when I can use something concise that translates to it? There may not need to be a step to eliminate the COBOL output step any more than a language that uses C or js as a target.
I've only seen two kinds of CICS programs in the wild: 1. screen I/O using preformatted BMS maps, 2. transactional with input buffer and output buffer. A third kind was one I wrote for sending dynamically generated terminal stream data for a hypertext online documentation system.
Any of these could be written in Elixir with appropriate libraries and translators. The company I worked at generated the BMS maps and COBOL source from assembling program components with an inclusion/override macro processor and wysiwyg editors--think Visual Basic for mainframes targeting both CICS and IMS.
Please tell me its not a payroll company.
My first dev job was COBOL on a Unisys mainframe. When the volume of "omg we need COBOL devs" articles got loud, I looked into what was available. The compensation graph for COBOL positions approximately matches those of any other dev job. You can do as well (or better) as a Python dev or Node dev or whatever.
The key to making more money is in specialization. The highest-paying jobs are looking for experience with specific combinations of technologies.
But being a Python dev has the added advantage of not having to deal with COBOL. ...speaking as someone who used Unisys' STRING/UNSTRING OS functions to implement input variable interpolation in COBOL because it has no native string operators or data type.
ed /s
Well, you can invoke AIX and run ed, it works, but yes, ISPF, running in a 3270 terminal, is pretty weird. That being said, it's pretty much very interactive even under horrible latency because it sends the entire screen every repaint.
3270 is, in a retro way, what the web 1.0 would look like if we were limited to monospaced characters.
In fact, they gave themselves a goal of avoiding making it into a programming language, except unfortunately real life requirements meant it had to gather such features quickly. Other infamous components came because of need to specify in line all sorts of metadata for I/O, because the OS might not have a place to store it - this caused the infamous DD statement that /bin/dd is a joking refence to.
In retrospective, one of the leads on JCL mentioned that they should have instead gone straight for a full programming language, that this way it would have better design.
https://medium.com/the-technical-archaeologist/hello-world-o...
I've done this before - translate green screen apps to ASP.NET. In my case, the company had (retiring) IT staff read the cobol and give us good "plain english". The actual ASP.NET code was trivial. That said, my one caveat is I don't feel like any language today has the longevity of these systems. That code was ASP.NET 3 MVC - new at the time, but outdated now. What stack do I pick today that will still be running in 30 years? HTML+JS+NodeJS seems the most likely candidate IMO, but then you get into the various frameworks-du-jur and it sort of falls apart. Would love HN opinions.
> HTML+JS+NodeJS seems the most likely candidate IMO
So that my bank can run npm install leftpad on their payment processors.
Please tell me this is parody.
If Node.js is even still used in 30 years it won't look anything like today's Node.js.
It's just moving business data into and out of, in many cases still file based records (but maybe we can upscale to SQL). So, if you can read the COBOl and implement correctly in the next blessed language (with tests).
Harder part is to meet the folks that can get you those gigs than actually doing the gigs.
Of all languages, js is by far the most volatile.
What's wrong with Java that COBOL doesn't suffer from exactly?
same reason we are flying 737 aircraft and chinook helicopters, well after we tried concordes and space shuttles.
see "Web Design: the first 100 years" for more: https://idlewords.com/talks/web_design_first_100_years.htm
This is such a backward mindset, though. Software evolves. Ecosystems evolve. Perhaps most importantly, security risks and surface areas evolve (which in part necessitates the prior points).
There is no good reason for systems to stagnate over three decades. Software isn't construction, it's gardening, and it requires constant maintenance and attention.
Software is like construction, you don't demolish everything and start from scratch just because it's a little, or very old.
Discarding everything and rewriting in another language is a expensive and error prone process.
To cite the excellent Joel blog:
> the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch.
https://www.joelonsoftware.com/2000/04/06/things-you-should-...
The data model is fixed width flatfiles with very specific access and index methods. There are 50 years of workarounds applied in there. Whatever code you end up with will still need to communicate with all the other stuff, so the data model can't change untill you got everything touching it in the new language.
The edge cases are a second problem. The code runs well in a very practical sense, as every major bug relevant for the end user has been fixed or worked around ages ago. Or it became the correct behaviour by sheer overwhelming force. You replace something insane, then find out you broke another system that had counterbalancing insanity. Worst case, it will run for a few months, silently corrupting data. Next tax round or year end, some report says something strange, and subsequent troubleshooting uncovers major doodoo. No, the taxman wont wait on your bugfix.
Then there is the sheer volume of code. 10 million lines is small scale. You can spend your whole carreer rewriting everything in the most trivial way, and 40 year later find you're not even close to done. There will be multiple failed rewrites in there, causing massive lavaflow architecture problems.
I did learn one thing, and that was COBOL has one up on 'goto'. Check out the control flow statement: MOVE NEXT SENTENCE. It's basically a goto, but it doesn't jump to a label, per se. Instead, it jumps to the next period in the source. Yes, in a big, blocky, verbose language like COBOL, where everything is in UPPER CASE, you're now looking for a teeny tiny period that is easily lost in the verbiage. Hands down, my least favorite programming language construct ever.
In more "modern" COBOL's like COBOL-85, there is actually a "CONTINUE" which is essentially a no-op.
Some COBOL shops instituted a "one-period-per-paragraph" rule (on the last statement in a paragraph) to avoid some of this. And COBOL-85 (thankfully) added scope delimiters (i.e. END-IF) to help avoid the issues with periods.
That problem happens with any transpiled language really, now you have all the problems of the new language and all the problems of the target language, and you need to fix "supposedly compiled" output by hand sometimes.
UNIX just considers that a file/stdin/stdout/stderr is a sequence of binary octets of arbitrary size, any information on how to deal with it is left entirely to the program.
In a way, IBM VSAM and other record access methods are more like tables with types that a UNIX-like file sytem.
As an aside I still have a zero-day for ICL mainframes running Gerorge that's decades old now and taking to my grave.