See the train for no cost or fee links at the bottom. I know ISVs and BPs can get 5-day lab courses for free but IDK about the general public.
IBM absolutely hates that software.
Those of us who actually worked with COBOL aren't fooled though. It bears repeating: COBOL is a horrible language and it's often used in legacy banking systems. Learn it at your own peril, especially when there are way more interesting languages and jobs out there.
I was intrigued by this. Can you say what city and why there are so many Cobol developers there?
It's a dead ecosystem.
On a different language, but same mindset.
System is many years outdated and no one understands it.
Get a ticket. “Fix all the problems”
Me “Umm okay. Hire 20 people and give us 3 years.”
Them: you have a week by yourself.
14 months later their standpoint is it’s always one more week left.
I can’t tell if they even see the absurdity anymore.
That's all that I need to know about COBOL.
Just this one yesterday:
Many of the postings I see are $250k+. That's like 3x what I make.
That's a name I haven't read in a long time.
I wrote a bunch of this when I was in the USAF, 81st Medical Group, back in the early/mid 1990s.
It had some neat features, including a robust, platform independent GUI, and platform independent bytecode.
Specifically, you could write a GUI program in AcuCOBOL and compile it, which resulted in a compact file that could then be put on any other kind of computer that had the AcuCOBOL runtime installed and then executed.
The GUI your program produced depended on the platform it was running on. If, like us, running on https://en.wikipedia.org/wiki/Aviion UNIX with nice big x-terms, you'd get an X11 GUI, unless you set a specific environment variable, in which case you'd get a nice curses-like GUI. The DOS runtime produced...if memory serves...a kind of curses-like, somewhat text based GUI.
Pretty neat stuff for the time.
Do you recall what those were specifically?
PERFORM N TIMES
ADD 1 TO I
DIVIDE X2 INTO 1500 GIVING Y
SUBTRACT Y FROM 815 GIVING Y
DIVIDE X1 INTO Y
MOVE X1 TO X2
SUBTRACT Y FROM 108 GIVING X1
Yes. But worse. And used in the real world.
Whilst I cannot give all the details for obvious reasons, when I was assisting a particular bank with translating some of their stack from COBOL to modern Fortran, part of the problem was that a large amount of their COBOL code was actually generated.
It wasn't a Pythonish-to-COBOL, though. It was a mix of the C-preprocessor and Bash that generated the COBOL code.
(Problem for me was that all source code was printed, and not stored anywhere digitally, so I had to restore that evil Bash/CPP script just to be able to restore the code I had to retype by hand).
COBOL is simply horrible. Avoid it if you can.
Interestingly, there is a AI startup that focuses on dev tools for COBOL: https://www.phasechange.ai/
I would research this by myself, but not really sure where to start - and googling “COBOL Developer Salary” leads to results in the 80-120k range (which is no small number, but not significantly different from a modern language developer)
It's a falsehood that often gets repeated. No, COBOL jobs don't pay particularly well. Plus they have the downside of, you know, having to work with COBOL, a horrible programming language. And mostly at banks and financial institutions, the main users of legacy COBOL systems.
Apparently not sufficiently "well" to prevent a "shortage" of COBOL programmers.
I guess I am saying programming history classes is where COBOL belongs.
I took COBOL in school and enjoyed it. The JCL is the harder part. I thought about doing COBOL as a career, but there weren't any entry level positions.
Even its creators say JCL is the worst language ever invented.
BASIC is also from the punch card era; it is only 5 years newer than COBOL (1964 vs 1959).
Its this. If someone is doing greenfield z/OS development, I would assume they are probably using a more modern language (IBM highlights Java and C/C++ support on z/OS), not COBOL. But there is tons of legacy code in COBOL – much of it that was never well-documented. Sure, there’s fewer available COBOL programmers, but in many cases the orgs with these systems have also lost most of the people that were serving as living documentation, which is not great when the system is operating in near-steady-state, but becomes a critical problem when it needs new changes. So, the COBOL programmers they tend to need are for code archeology, temporally-displaced mind-reading to understand the original intent of code and diff it with emergent requirements, and maintenance on legacy systems.
COBOL development is nearly never greenfield, and many of the (mainframe) systems you'll have to work with behave differently than you'd expect if you're someone that learned about software after the 80's.
Almost every time I see an expression builder in a UI, I think it would be better off with SQL syntax and autocomplete because the dropdowns get old fast, and SQL expressions aren't that hard.