Skip to main content

This probably won't help me in my current job search, but is it worth learning COBOL? I've heard that there are still a bunch of critical systems out there that use it, and that it's hard to find COBOL devs these days.

Is this still the case? The only downside I can see is that I'd have to program in COBOL.

in reply to Jonathan Lamothe

fedops πŸ’™πŸ’›
fedops πŸ’™πŸ’›
• •

Cobol devs are definitely in demand.

I did Cobol in my studies. It's quirky but a fairly straightforward language to learn. It's not sexy but solid, and at least you won't be dealing with all the boilerplate Java or csharp junk.

Cobol is only half the deal though. In all likelihood you'll be working in a mainframe environment so may come into contact with Rexx JCL, CICS, and all the other good stuff as well. πŸ˜„

in reply to Jonathan Lamothe

erin
erin
• •
I’m not an expert in COBOL but I am in the labour market. Look at 10 job postings for your profession. If 5 or more list COBOL as a requirement or an asset, I’d consider taking the time to learn it.
in reply to Jonathan Lamothe

silverwizard
silverwizard
•
@Jonathan Lamothe I have a friend locally doing COBOL for TD and she says it's good work. Very slow because most of the world is waiting on approvals.
@Jonathan Lamothe
in reply to Jonathan Lamothe

TinCoyote
TinCoyote
• •

I would suggest that putting the effort into learning COBOL isn't worth it.

There are high-paid jobs working in COBOL on legacy 'systems of record' devices that are still critical.

But every year, the number dwindles. AI translation of COBOL may also arise.

My suggestion is that there are also modern languages to learn that have a much better future for you and likely aren't as hard to learn.

in reply to TinCoyote

Jonathan Lamothe
Jonathan Lamothe
• •
@TinCoyote Yeah, I've got a bunch of other languages under my belt. It's just that the job market is flooded with other people who also know those languages. I do have some strength in a relatively niche language (Haskell); it's just that there doesn't seem to be a ton of demand for it (though there is some).
@TinCoyote
in reply to TinCoyote

Eric Lawton
Eric Lawton
• •

@gedvondur

A reading knowledge of COBOL would be useful for understanding of parts needing replacement, especially where requirements and test cases are missing, while putting the most effort into expertise in potential target languages.

Writing COBOL requires fast typing skills. It's very verbose.

"Subtract Expenses from Gross-Revenue giving Profit"

@me

@TinCoyote @Jonathan Lamothe
in reply to Jonathan Lamothe

Digital Mark Ξ» β˜•οΈ πŸ•Ή πŸ™„
Digital Mark Ξ» β˜•οΈ πŸ•Ή πŸ™„
• •

Watch @ellyxir learn COBOL:
youtube.com/watch?v=8skE5PTeOW…

And then rethink your choices!

(I only know how to do REXX on IBM mainframes. And it's not pretty.)

- YouTube

Bekijk je favoriete video's, luister naar de muziek die je leuk vindt, upload originele content en deel alles met vrienden, familie en anderen op YouTube.
www.youtube.com
@Ellyse
in reply to Digital Mark Ξ» β˜•οΈ πŸ•Ή πŸ™„

Jonathan Lamothe
Jonathan Lamothe
• •

@Digital Mark Ξ» β˜•οΈ πŸ•Ή πŸ™„ @Ellyse I watched the first video (on 2x speed) and while definitely looked painful, it didn't seem that bad.

It's certainly not something I'd be able to pick up right away, but I am twisted enough in the head just to try to do this for fun.

This also probably explains how I ended up in a cult for 12 years. πŸ™ƒ

@Digital Mark Ξ» β˜•οΈ πŸ•Ή πŸ™„ @Ellyse
in reply to Jonathan Lamothe

Bill Fellows
Bill Fellows
• •

Having worked adjacent to 4 different mainframes at this point in my career along with their "modernization" efforts. Reading COBOL, not terrible. Writing it, eh, probably not so bad but I've never done, only had to read and comprehend what it does. And there are non-MFs that provide implementation of COBOL so you can learn on your own time.

The devil is going to be understanding IBM systems "junk": CICS, DASD, DCLGEN, TSO, RACF etc

in reply to Bill Fellows

Judy Anderson
Judy Anderson
• •

@billinkc
What he said. Mainframe basics are more important than COBOL, I'd say.

I work for a company that's doing "Mainframe Modernization" and as a result we have to understand the old crappy non-modern stuff in order to implement new stuff! (Currently my group isn't reimplementing anything based in Cobol. We do Db2 monitoring stuff.)

rocketsoftware.com
rocket.wd5.myworkdayjobs.com/r…

(We have AI hype on the front page but really we're just programming. I guess some departments might be doing AI, but I think we're just scared we'll miss the bandwagon. So don't ignore us just for that.)


Rocket Software

Rocket Software provides IT modernization and IT automation solutions that help businesses solve their most complex IT challenges, across infrastructure, data, and applications.
Rocket Software
@Bill Fellows
in reply to Judy Anderson

Jonathan Lamothe
Jonathan Lamothe
• •
@Judy Anderson @Bill Fellows I was poking around with some TOPS-20 stuff on SDF. Is that perhaps a more viable route to persue?
@Judy Anderson @Bill Fellows
in reply to Jonathan Lamothe

Judy Anderson
Judy Anderson
• •
@billinkc TOPS 20 is dead. Only SDF hobbyists would still use it. IBM mainframe is not dead, much as people wish it were πŸ™‚
@Bill Fellows
in reply to Judy Anderson

Bill Fellows
Bill Fellows
• •

@nosrednayduj OMG super small world. One of the projects I was on dealt with model 204/m204. We ended up building a real time synchronization between m204 and SQL Server via messaging.
It was going to be a very cool way to modernize the client's data storage while they incrementally switched the front ends.

Pity literal debt caught up to them πŸ’₯

@Judy Anderson
in reply to Jonathan Lamothe

William B Peckham
William B Peckham
• •
If you have no mainframe experience, the first thing I would do is get some mainframe experience or study the mainframe environment. Include JES2. If you only have one or two other programming languages that you have mastered, then I would go for something else that is in current development use. If it's your fourth or fifth language, get COBOL. It's quicker and easier to pick up a language after you have a few under your belt and the concepts are clear in your mind. Oh, and a mainframe environment is not the only place it comes in handy. I did a little work for a steel company that had Critical applications in micro focus object-oriented COBOL, and they had a huge IT department, but I was the only one local with current cobol experience. You never know when that knowledge might become critical.
⇧