Learning COBOL: A Journey for the Modern Programmer(monadical.com)
monadical.com
Learning COBOL: A Journey for the Modern Programmer
https://monadical.com/posts/cobol.html
62 comments
Does anyone know of any good resources for learning basics of JCL, datasets, jobs, the z/OS Host and so on? I find that when I look at the screens of my mainframe colleagues, the COBOL code is actually the only thing I can wrap my head around, as opposed to all the weird mainframe tools built around it.
https://www.ibm.com/it-infrastructure/z/education
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.
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.
Theres almost certainly a more direct route, but I learned most of these things (not really JCL) by learning HLASM from this resource:
http://csc.columbusstate.edu/woolbright/WOOLBRIG.htm
http://csc.columbusstate.edu/woolbright/WOOLBRIG.htm
I don't know anything about IBM operating systems, but I understand that older versions of System/370 are free and can be run on PCs via this famous emulator:
http://www.hercules-390.eu/
IBM absolutely hates that software.
http://www.hercules-390.eu/
IBM absolutely hates that software.
the videos on the resources cover JCL and other tools.
I suppose it's again that time of the year when there's a flood of articles trying to convince people that COBOL is worth learning, that it's been updated or that it pays really well, and that there are lots of hidden opportunities for you to make big money working with COBOL!
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.
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.
So much this, I work in a city with literally thousands of former cobol developers who's jobs were offshored over the past two decades. Check online jobs boards, there is very very little demand for this skill, shortage is myth.
>"... I work in a city with literally thousands of former cobol developers who's jobs were offshored over the past two decades."
I was intrigued by this. Can you say what city and why there are so many Cobol developers there?
I was intrigued by this. Can you say what city and why there are so many Cobol developers there?
Any city with telecom, airline headquarters, and financial services. This one has all three. Could be Chicago, and others.
Interesting I always associate COBOL with banking I didn't know it was as equally entrenched in airlines and telecom as well.
Keep in mind that everyone working in COBOL trying to squeeze costs.
It's a dead ecosystem.
It's a dead ecosystem.
This.
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.
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.
Do they have a critical dependency on it?
If it doesn’t work they go out of business.
It also doesn't seem to pay that well. I would expect too earn 2-4 times as much as a Java dev but that doesn't seem to be the case.
I've noticed that people only speak highly of COBOL, as a technology, when Grace Murray Hopper's name occurs nearby.
That's all that I need to know about COBOL.
That's all that I need to know about COBOL.
I remember the government's plea for COBOL programmers last year and was surprised we haven't seen that many more posts about it since then.
https://nymag.com/intelligencer/2020/04/what-is-cobol-what-d...
https://onezero.medium.com/our-government-runs-on-a-60-year-...
Just this one yesterday:
https://www.govtech.com/opinion/An-Apology-to-COBOL-Maybe-Ol...
https://nymag.com/intelligencer/2020/04/what-is-cobol-what-d...
https://onezero.medium.com/our-government-runs-on-a-60-year-...
Just this one yesterday:
https://www.govtech.com/opinion/An-Apology-to-COBOL-Maybe-Ol...
Maybe if they took the time to train people and create a sustainable talent pipeline then they wouldn't be in this position. They only want experts and nobody want to train.
They are also somewhat underpaid. I’d totally like to be paid to work on mainframes, even if writing COBOL code, but not by taking a pay cut.
How much do you make?
Many of the postings I see are $250k+. That's like 3x what I make.
Many of the postings I see are $250k+. That's like 3x what I make.
> Many of the postings I see are $250k+. That's like 3x what I make.
Proof please.
Proof please.
Ah, I see. I was looking at consultant jobs. Regular jobs seem to be less.
I never saw one of those, but I don’t think I could be a senior COBOL developer. I’d need training on both language and zOS.
I think it depends on the skill. I see young programmers from big companies like IBM or Accenture making peanuts and working constant overtime while the older guys (I'm talking 30 years experience) who are independent consultants quote 1000€+/day.
Wasn’t the plea a please for “volunteers” as well?
But which COBOL? Microfocus now own RM/COBOL and AccuCOBOl, as well as their own MicrFocus Cobol. These are for the IBM PC and run on Windows, Unix, and Linux. Old code usually uses compiler dependent extensions, and without a good amount of work, I can not just recompile using a diffrent vendor's cobol. And if it does happrn to compile it may not work because the expected behaviour of implrmented language key words might be slightly diffrent. I ran inro this trying to port code to GNUCobol
> AccuCOBOl
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.
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.
> key words might be slightly diffrent. I ran inro this trying to port code to GNUCobol
Do you recall what those were specifically?
Do you recall what those were specifically?
Looking at COBOL code such as
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
DISPLAY I'|'X1
END-PERFORM.
> I wonder if someone has written a Python-to-Cobol translator so that you can program using regular math notation and then translate that into wordy Cobol.
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).
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).
This is more common than you might think. Back when I worked on a COBOL compiler at IBM one of our test cases was an "expert system" that turned ~20 lines of business-specific DSL into ~100k lines of COBOL. It was extremely un-fun to deal with.
Looks like the COBOL I saw when working at a bank, years ago. And it wasn't the output of any automated translation.
COBOL is simply horrible. Avoid it if you can.
COBOL is simply horrible. Avoid it if you can.
Maybe it's because I'm not a native English speaker but what does "divide into" mean?
I'm a native English speaker, and I've never heard that phrase either. I assume it's the same as "divide by", but I could be wrong.
Divide into is the opposite of Divide by. X2 into 1500 is 1500/X2
DIVIDE X2 INTO 1500 GIVING Y => Y=1500/X2
Guess I'll switch to teaching COBOL in my undergrad courses!
Interestingly, there is a AI startup that focuses on dev tools for COBOL: https://www.phasechange.ai/
Interestingly, there is a AI startup that focuses on dev tools for COBOL: https://www.phasechange.ai/
Out of curiosity, does knowing COBOL pay well in 2021? It seems COBOL programmers are in critical demand and free market economics should mean that COBOL programmers get paid premiums.
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)
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)
No, it doesn't, at least not in my country (not the US).
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.
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.
I would also assume companies/banks hiring COBOL programmers are more interested in candidates with years of experience with the language, since opportunities to build and grow with COBOL seem pretty slim outside of legacy maintenance. Granted, the old COBOL heavy hitters are becoming less common, but I would still think it would be difficult for someone that picked it up for a year or two to compete. Seems like it's just not worth the time and effort to break into this space.
>Out of curiosity, does knowing COBOL pay well in 2021?
Apparently not sufficiently "well" to prevent a "shortage" of COBOL programmers.
Apparently not sufficiently "well" to prevent a "shortage" of COBOL programmers.
Senior mainframe programmers seem to get paid less than entry level java/SQL programmers where I work at.
I took a survey of historical programming languages course in college that covered FORTRAN, COBOL, SNOBOL, Prolog, SmallTalk, and several others of importance or uniqueness. Each section required a small practical program be written in that language, and we discussed each in its context of usage, 'family tree', syntax etc
I guess I am saying programming history classes is where COBOL belongs.
I guess I am saying programming history classes is where COBOL belongs.
This course sounds really interesting. Do you remember if there was a text book or if there is any online syllabus for it?
This was 20 odd years ago, so I do not remember clearly if there was a text. I think there was not. Almost certainly no to the online syllabus as that professor is long retired and when I took the class he was still using overhead projector transparencies.
Younger programmers aren't taking up the language because most schools don't teach it and companies aren't interested in training people. Most of the postings want experienced people like senior devs, whether it's for COBOL or some other language.
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.
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.
> The JCL is the harder part.
Even its creators say JCL is the worst language ever invented.
Even its creators say JCL is the worst language ever invented.
I found it interesting that the author found COBOL's use of line numbers strange and chalked it up to its origin in the punch card era. While that may have been part of it, those of us who learned programming via BASIC in the 1980s were very used to line numbers even though we never saw a punch card.
> I found it interesting that the author found COBOL's use of line numbers strange and chalked it up to its origin in the punch card era. While that may have been part of it, those of us who learned programming via BASIC in the 1980s were very used to line numbers even though we never saw a punch card.
BASIC is also from the punch card era; it is only 5 years newer than COBOL (1964 vs 1959).
BASIC is also from the punch card era; it is only 5 years newer than COBOL (1964 vs 1959).
BASIC was designed as an interactive language on the Dartmouth Timesharing System rather than batch, though. It was assumed that the user was at a terminal (probably a teletype given the era) and could interact in real time with the computer rather than punching cards to be handed to an operator and receiving output later. The line numbers were there to aid editing code as a replacement line could be entered using the same line number as an existing line. This tradition carried into the home computers of the 1980s as they generally didn't use text editors as we know them for editing BASIC code.
Anyone attempted to write a COBOL code generator in a more comfortable language? Or isn‘t code generation the problem, rather the reading/modifying legacy code?
> Or isn‘t code generation the problem, rather the reading/modifying legacy code?
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.
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.
It's the latter.
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.
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.
Really interesting, lots of good resources. Thanks!
Isn't it a good case for visual programming? If you can't afford programmers, then you go for something less demanding and throw more cheap bodies at the problem.
My take on visual programming is it's easier to start out with, but you're quickly better off using a conventional language once you reach a certain scale or you need to manipulate your program in certain ways.
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.
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.
The problem with COBOL is that you can't afford "better", you can only afford "good". Excel should be a sufficient demonstration that visual programming is doable beyond the start.
Wow, great article! Super interesting :)