Live data from Hacker News

IBM will offer free COBOL training

inputmag.com

191–200 of 235 posts

Re: IBM will offer free COBOL training

#191
This month I wrote 2 Rexx stored procedures 1. Does a db2 bind 2. Executes any DML, DDL, DCL and selects in Db2

These stored procedures will be triggered by REST APIs & Endevor(version control). What makes me happy is, these will work for another 10+ years without any upgrades or me tinkering the code again for new version.

Well if it was any web technology or cloud application, I would be getting a mail from them saying they are going to decommission a version of language so either you need to rebuild your code only to know it fails in new version(every 2 years). Well that doesn't happen in mainframe.

Re: IBM will offer free COBOL training

#192
post #62

Earlier quoted context omitted.

Absolutely (and I say that as an erstwhile mainframe COBOL programmer). The language itself is dead easy.

The language isn't dead (and doesn't have to be). If anything, it must be taught as part of a programming language design course. In a way COBOL is similar to SQL which is far from dying. (IMHO it would have been useful if they had merged into one language; the available embedding of SQL into COBOL was kinda clunky.)

The person you're responding to didn't claim that COBOL is dead. He/she wrote that COBOL is "dead easy", meaning "very easy".

Re: IBM will offer free COBOL training

#193
post #150

From the article: * State unemployment agencies are notoriously underfunded* And there’s the problem summarized in less than a single sentence. Yes, they need help, but it’s the same kind of “help” as in “I want a BMW but I only have a dollar, please help” There would be a ton more COBOL coders if companies paid the equivalent of FANG companies - I say this as a former COBOL coder myself

Leaving aside what they're willing to pay or not pay for COBOL developers, does anyone seriously believe that a bunch of developers can waltz into an old code base and speed it up by a large amount in a relevant timeframe? Which seems to be what these articles are at least implying.

The government doesn't know that. That's why they're calling it COBALT.

I honestly can't wait until all the old non tech people retire.

Re: IBM will offer free COBOL training

#194

The IRS, treasury, and others locally are looking for COBOL programmers. I can explain why they're struggling to find any just by looking at the pay scale: $30,113 - $86,021 (GS-5 through GS-12, and most won't get the top end of the GS-12 scale). The $30K GS-5 starting is almost as low as working for their call center which is farcical. By contrast state, county, and even city government are paying $65K - $85K starti…

That mirrors my experience in mainframes. Out of college I was writing HLASM for zOS systems making roughly 65k in Houston. Definitely not bad for right out of college from a non-prestigious state school, and I was happy to have work. However, it seemed the upper bound on what I could earn there after climbing the entire ladder was 100k.

I decided to move to NYC and was making 100k immediately as a Jr RoR developer at a lean startup that was paying probably 10-15% below market.

It makes little to no sense for anyone with other options to take these incredibly low paying jobs relative to what they could be earning, doing what I would argue is far easier development work. It continues to baffle me that these major organizations claim a shortage of mainframe developers, especially as all the senior ones are retiring, yet their pay scale looks comparable to what department managers made when I worked at Circuit City.

Re: IBM will offer free COBOL training

#195
post #152

Earlier quoted context omitted.

Now imagine 30 years from now when you are going to have to track down the documentation for version X of the web framework for version Y of some language and version Z of frontend framework.

> Now imagine 30 years from For the javascript ecosystem this is already true for projects that are > 2 year old. Not kidding, try to build a 2 year old React web application, you'll see what I mean.

TBF, part of the problem is that dependency locking only caught on recently. (Yarn came out in 2016.) That makes it more possible.

Re: IBM will offer free COBOL training

#196

Earlier quoted context omitted.

This is exactly true. The pay is this low because there is a glut of cheap cobol developers in the US due to decades of off shoring. There have been 2000+ cobol developers laid off here over the past 5 years alone (medium midwest metro).

There cannot simultaneously be a surplus of COBOL developers and a shortage of COBOL developers. Well, supposedly there could be one in the Midwest and one in NJ, but theoretically those who do not have a job in the Midwest would be motivated to move, since their only options are: A) Remain jobless in Midwest. B) Switch careers in Midwest. C) Move to NJ for immediately available position. The bigger question is why d…

Low salaries on offer convincingly reveal the true narrative. The question is why is the false narrative being promoted? Rather effectively at that.

Re: IBM will offer free COBOL training

#197

Earlier quoted context omitted.

This is exactly true. The pay is this low because there is a glut of cheap cobol developers in the US due to decades of off shoring. There have been 2000+ cobol developers laid off here over the past 5 years alone (medium midwest metro).

There cannot simultaneously be a surplus of COBOL developers and a shortage of COBOL developers. Well, supposedly there could be one in the Midwest and one in NJ, but theoretically those who do not have a job in the Midwest would be motivated to move, since their only options are: A) Remain jobless in Midwest. B) Switch careers in Midwest. C) Move to NJ for immediately available position. The bigger question is why d…

> The bigger question is why does a COBOL dev accept work for 60k when they could make 120k in Javascript?

Structural unemployment due to ageism?

Re: IBM will offer free COBOL training

#198
post #64

Earlier quoted context omitted.

>> They do give you ssh access to the Unix-compatibility environment though so maybe it's possible to edit files using Tramp in Emacs locally. It's a UNIX shell. You can always use ed :)

You can actually ssh into it and use vi. That's probably the easiest way to do it. However, the edit-compile-test cycle is somewhat complicated. You need to first edit the file, fine, you can use vi. Then you need to go into ISPF (or TSO) on a 3270 terminal to submit the batch job that compiles the code (and possible runs it). Then you need to go into SDSF to view the results of the compilation. Back in the 70's this…

>> You need to first edit the file, fine, you can use vi. Then you need to go into ISPF (or TSO) on a 3270 terminal to submit the batch job that compiles the code (and possible runs it). Then you need to go into SDSF to view the results of the compilation.

Well, I don't know how you can avoid that part, i.e. submitting a batch job and looking at the results separately. SuperPaintMan describes an alternative but I'm not sure how this works. When I was working on a mainframe, it was like you say, except I couldn't edit files remotely with vi - because big financial corporation security :)

To be fair, I didn't try. There probably was a way. I didn't mind the editor I had on ISDF, EZY editor. The only annoying thing was that, if I understand this correctly, EBCDIC doesn't have an end-of-line character so I couldn't just control-End to go to the end of a line, I had to use the arrow keys or touch the mouse (yuck!).

Re: IBM will offer free COBOL training

#199

Earlier quoted context omitted.

>> I don't want to sound condescending but why can't these systems be rewritten in a modern language? Cobol was a modern language 50 years ago. Python will be an ancient language 50 years from now. What do we do? Keep rewriting everything every 50 years? And those ancient Cobol codebases actually have a big advantage: they've been maintained for so long that all the major bugs have been virtually eliminated. Creating…

> What do we do? Keep rewriting everything every 50 years? Uh… sure? What would you consider an acceptable minimum amount of time to be after which rewriting a large but fairly critical codebase to modern standards becomes acceptable? > And those ancient Cobol codebases actually have a big advantage: they've been maintained for so long that all the major bugs have been virtually eliminated. Creating a new system from…

Unfortunately, nothing works that effortlessly in software.

Re-writing an existing algorithm is one thing, but even that is likely to be a big source of new bugs, given that Cobol is actually a quite low-level language and much code will rely on its specific view of a mainframe's architecture.

The bigger problem is that any implementation of complex business logic is going to depend very heavily on the facilities provided by whatever language it's originally implemented in (Cobol, in this case, obviously). A direct translation to a new language is likely to be completely impossible. And the bugs will grow in all the semantic gaps between the old language, and the new.

And that's before considering that, for Cobol in particular, the Cobol code itself is only half the story. Cobol programs run as batch jobs controlled by JCL ("Job Control Language") which often means that crucial aspects of businees logic are spread over multiple files in _two_ languages. And the JCL part is a mess. I didn't mind Cobol when I was working with it, I even came to like it a bit actually. JCL is really, really awful.

But, aesthetics aside, where does all the JCL-encoded logic go? Is that translated to the new language, also? That's going to be really hard given that JCL is operating-system specific. Is it going to be translated in scripts in a new shell language? The difference between concepts on JCL and, say, bash, or powershel, is going to be impossible to bridge without making drastic changes- and cultivating new bugs.

In general, translation of a large codebase between two very different languages is going to cause lots and lots of new bugs. So, if you rewrite everything every 50 years, in 200 years you'll spend a total of 40-80 years fixing bugs. If you write it once and let it be, you'll spend at most 20. I don't see a good reason to do it.

And what's wrong with an "antiquated language" anyway? I mean is it just aesthetics we're talking about here? Is it the lack of programmers that's the problem? The latter is sure to make translation even harder and more bug-prone. What is the real reason to change a working codebase every n years?

Re: IBM will offer free COBOL training

#200

The IRS, treasury, and others locally are looking for COBOL programmers. I can explain why they're struggling to find any just by looking at the pay scale: $30,113 - $86,021 (GS-5 through GS-12, and most won't get the top end of the GS-12 scale). The $30K GS-5 starting is almost as low as working for their call center which is farcical. By contrast state, county, and even city government are paying $65K - $85K starti…

Does IRS work with consultant firms? I can see how someone sets up a consulting shop, finds COBOL brogrammers and charges IRS $5k/hour.
Post reply on HN