Live data from Hacker News

COBOL: Thinking about it wrong

gcn.com

21–30 of 116 posts

Re: COBOL: Thinking about it wrong

#21
post #10
post #7

I'm pretty sure I'm thinking about it right. How much COBOL code can run on a regular Ubuntu machine? What's the package manager for OSS packages? What test frameworks are in common use? You know you're in trouble when "There's a syntax file for VSCode." is the height of your modernity.

> How much COBOL code can run on a regular Ubuntu machine? All of it. GNU Cobol exists, as do proprietary solutions from companies like Micro Focus that target the JVM and .NET (which is what you're looking for for a real COBOL solution). But why is it so important to run COBOL on Ubuntu? If you need Linux, create a Linux LPAR on your mainframe. > What's the package manager for OSS packages? COBOL code runs Western c…

There are several programming languages with package managers that work better than NPM. Not having one is not a positive no matter how you try to spin it.

Re: COBOL: Thinking about it wrong

#22
post #16

I have never written cobol, but I wonder if there is a market for a COBOL transpiler to something like C#/Java/typescript, or even python would be a viable business?

I suspect it's not the language itself but the systems already in place. Transpiling to something else wouldn't help.

It's a mix of both, I know that some companies do make a good living writing transpilers to languages like Java or C#. But it also require lots of business knowledge to keep track of the changes so you're definitely right in that aspect.

Re: COBOL: Thinking about it wrong

#23

COBOL was actually in the CS curriculum for my university, a fact that several of my friends brought up when the 'COVID is prompting a real need for COBOL programmers in light of the need to change benefits rules and unemployment!' stories were a regular feature on the nightly news. 'You should do it, man!' Yeah, sure. I'd already suffered through the liquidation of my entire department in 2018, the prospect of the h…

You don't really want to work with those people anyway. Some hiring managers will see it as a cool thing. As long as you do a project in whatever you want to target next to stay fresh you shouldn't have any problems except from those who hire superficially.

Re: COBOL: Thinking about it wrong

#24

Even after a 44% bump, the salaries for COBOL positions aren't impressive compared to other specialties. And that's before the quality-of-life question.

The quality of life may not be bad at all. I have a relative who maintains old code for a public utility (I think most of it is PL/1). While the salary is not FAANG-like it is OK and the job security and the sane 9-5 schedule with the opportunity to work remotely are pretty big benefits for someone on the wrong side of 60. My 2c.

Re: COBOL: Thinking about it wrong

#25

COBOL was actually in the CS curriculum for my university, a fact that several of my friends brought up when the 'COVID is prompting a real need for COBOL programmers in light of the need to change benefits rules and unemployment!' stories were a regular feature on the nightly news. 'You should do it, man!' Yeah, sure. I'd already suffered through the liquidation of my entire department in 2018, the prospect of the h…

> the additional stain of 'oh, what've you been doing? Cool, popular JS frameworks? No, COBOL? Pass.' on my CV

That's pretty much the last thing that I'd worry about. A company that evaluates potential hires that way is not a company that's worth working for, in my opinion. And most companies I've encountered wouldn't think that way.

Re: COBOL: Thinking about it wrong

#26

COBOL was actually in the CS curriculum for my university, a fact that several of my friends brought up when the 'COVID is prompting a real need for COBOL programmers in light of the need to change benefits rules and unemployment!' stories were a regular feature on the nightly news. 'You should do it, man!' Yeah, sure. I'd already suffered through the liquidation of my entire department in 2018, the prospect of the h…

It's the same reason why I opted to spend only minimum time with the dying tech in my old role and find something more broadly applicable. You're super important until you're not, so general tech that is useful in many areas is a lot safer.

Cobol ain't going away anytime soon, but it certainly might limit what jobs you can get other places depending on the hiring algorithm.

Re: COBOL: Thinking about it wrong

#27
post #10

Earlier quoted context omitted.

> How much COBOL code can run on a regular Ubuntu machine? All of it. GNU Cobol exists, as do proprietary solutions from companies like Micro Focus that target the JVM and .NET (which is what you're looking for for a real COBOL solution). But why is it so important to run COBOL on Ubuntu? If you need Linux, create a Linux LPAR on your mainframe. > What's the package manager for OSS packages? COBOL code runs Western c…

There are several programming languages with package managers that work better than NPM. Not having one is not a positive no matter how you try to spin it.

I think this is a point that reasonable people can disagree about.

Re: COBOL: Thinking about it wrong

#28
post #10
post #7

I'm pretty sure I'm thinking about it right. How much COBOL code can run on a regular Ubuntu machine? What's the package manager for OSS packages? What test frameworks are in common use? You know you're in trouble when "There's a syntax file for VSCode." is the height of your modernity.

> How much COBOL code can run on a regular Ubuntu machine? All of it. GNU Cobol exists, as do proprietary solutions from companies like Micro Focus that target the JVM and .NET (which is what you're looking for for a real COBOL solution). But why is it so important to run COBOL on Ubuntu? If you need Linux, create a Linux LPAR on your mainframe. > What's the package manager for OSS packages? COBOL code runs Western c…

>> If you need Linux, create a Linux LPAR on your mainframe.

Or use the super secret hidden unix mode.

(and get stuck in an ed prompt. Fun times ?).

Re: COBOL: Thinking about it wrong

#29

COBOL was actually in the CS curriculum for my university, a fact that several of my friends brought up when the 'COVID is prompting a real need for COBOL programmers in light of the need to change benefits rules and unemployment!' stories were a regular feature on the nightly news. 'You should do it, man!' Yeah, sure. I'd already suffered through the liquidation of my entire department in 2018, the prospect of the h…

If you know COBOL and know other languages and are fluent in "current" tech, then I see nothing wrong with consulting for $300 an hour doing some COBOL.

Company I work for still uses AS400, which has been released in 1988 just after I was born. We have a dev who supports it. This isn't a small company either.

COSTCO is still using and a lot of huge organizations.

I'm focused on newer tech C#, .NET, Blazor but I do interact with DB2 database which is the backbone of that old system.

At one of my interviews somewhere I mentioned that a lot of apps I'm writing are just extending AS400 and the dude interviewing me was really hyped up. He has spent a lot of time with the green screen in his younger years. The job had nothing to do with AS400, but that conversation got me an easy offer.

Re: COBOL: Thinking about it wrong

#30

Earlier quoted context omitted.

One of the slides by some IBM consultants presenting at the financial firm I used to work stated "Western Civilization runs on the mainframe." Considering how much banks still use mainframes, this is probably true.

I recently listened to a podcast episode which featured a gentleman who teaches mainframe related things at a university in the US and is deeply involved with the Open Mainframe Project. His statistic was 95% of financial transactions touch a mainframe somewhere along the way. From what I know, considering it's not "just" banks but pretty much any long running financial business (IE insurance companies), I believe it…

Can confirm. In a past life I had the pleasure of auditing the COBOL code of a major US insurer. They had a separate program for every line of service (Auto/GL/etc.) that would read every claim record and produce their actuarial tables.

It was pretty fascinating to see how it all came together. Also despite the languages age after analyzing it for a length of time it was clearly elegant for that type of financial processing.

Post reply on HN