8 ms·

You think that those people are getting paid the big bucks because they know COBOL, but the reality is that they are getting paid the big bucks because they hav

by jhugo 4y ago

You think that those people are getting paid the big bucks because they know COBOL, but the reality is that they are getting paid the big bucks because they have decades of experience with all the legacy systems that surround that COBOL. Learning COBOL, even in a "real" environment, isn't going to be the jumpstart that you're hoping for by itself.

ejb999 4y ago
this is the best answer.
hugg 4y ago
Yeah, this is what I learned too from working at a big government pension office
agumonkey 4y ago
the few I've seen, COBOL legacy is its own kind. It meshes decades of users, practices, tools and paradigms. We've been shown code that blend old original code with 3GL crude code generator with 4GL custom COBOL transpiled DSLs with monkey patching. It was really not pretty (to stay polite).
- hermitdev 4y ago
  My last project as an intern was to rewrite an old batch processed COBOL app into a simple webform in C#/ASP.Net. The COBOL app was nothing special, really. From what I recall, it was around 65 pages printed. Took me a while to comprehend what was going on, but the first 80% or so was basically just hard-coded rules to take action on based upon user input. Things like when "B", generate "X" & "Y". When "A", generate "X", "Y" & "Z" sort of thing. Nothing fancy, at all. Once I figured out what was going on, I basically just ran the COBOL through some regexs, transformed into an XML doc (don't judge me - it was early 2000s) and wrote the rules engine in maybe one or two screenfuls of C#. I did learn one thing, and that was COBOL has one up on 'goto'. Check out the control flow statement: MOVE NEXT SENTENCE. It's basically a goto, but it doesn't jump to a label, per se. Instead, it jumps to the next period in the source. Yes, in a big, blocky, verbose language like COBOL, where everything is in UPPER CASE, you're now looking for a teeny tiny period that is easily lost in the verbiage. Hands down, my least favorite programming language construct ever.
  - agumonkey 4y ago
    You never ran into an ALTER ?
  - JD1967 4y ago
    NEXT SENTENCE (not "MOVE NEXT SENTENCE") is sort of equivalent to "continue" in modern languages. In more "modern" COBOL's like COBOL-85, there is actually a "CONTINUE" which is essentially a no-op. Some COBOL shops instituted a "one-period-per-paragraph" rule (on the last statement in a paragraph) to avoid some of this. And COBOL-85 (thankfully) added scope delimiters (i.e. END-IF) to help avoid the issues with periods.
- ElectricalUnion 4y ago
  > COBOL transpiled DSLs That problem happens with any transpiled language really, now you have all the problems of the new language and all the problems of the target language, and you need to fix "supposedly compiled" output by hand sometimes.
  - agumonkey 4y ago
    I've nothing against cobol, but I think it's worth there, because of the gap with a python like lang (IBM made one) and cobol. Coffeescript to es5 wasn't too hard to guess.
Zenst 4y ago
aye decades of COBOl here though I did it upon the wrong non-IBM platform, RIP ICL and Honeywell
- klelatti 4y ago
  Presumably these platforms have also lived on though. I think I remember reading about a Fujitsu contract to maintain a big U.K. government ICL derived system?
  - Zenst 4y ago
    There isn't the work on the market for any of those and from my experience of working with on their contracts, they will all be tuped existing staff. As an aside I still have a zero-day for ICL mainframes running Gerorge that's decades old now and taking to my grave.
    - klelatti 4y ago
      Interesting - thanks. Won’t get fixed now. I’m guessing all emulated and running on x64 by now.
- chasil 4y ago
  Long live EXEC 8.
- JD1967 4y ago
  Yeah, I programmed in COBOL for 15 years on Unix systems... so I don't have any mainframe experience... I'm pretty good with the actual COBOL code, but as people have said, that's only a piece of it. Working with the environment, such as IBM mainframes, is a big piece. Which is sort of odd, because COBOL was supposed to be "common"...
kazinator 4y ago
"I'm gonna learn C and start an embedded firmware job!"
- yodsanklai 4y ago
  You got to start somewhere
peter303 4y ago
Like the nightmare language IBM OS DDL? (data definition language) I recall you have specify the physical layout of data files on disk. In UNIX this info is embedded in the file system and generally not needed to run a program.
- ElectricalUnion 4y ago
  > In UNIX this info is embedded in the file system and generally not needed to run a program. UNIX just considers that a file/stdin/stdout/stderr is a sequence of binary octets of arbitrary size, any information on how to deal with it is left entirely to the program. In a way, IBM VSAM and other record access methods are more like tables with types that a UNIX-like file sytem.
Stampo00 4y ago
The old pros are continuing to age out and retire or die. Places with COBOL systems want to keep their applications limping along instead of replacing them. The shortage of devs is only going to get worse. Remember when lock down started and some government systems built on COBOL started straining under the load? Rather than being dismissive, I'd encourage those with any interest at all to try to pick it up. We need folks to maintain it.
- thr0wawayf00 4y ago
  > We need folks to maintain it. Beware, maintaining those systems is absolute hell and the companies experiencing exodus are working their people into the ground because the workload is crushing them and they can't find replacements. A good friend of mine is an engineering director at a company that runs a massive COBOL mainframe platform and he always half jokes with me about picking it up. The money isn't that great at his company and the problems they have maintaining the system just blow my mind. The entire company sounds fundamentally unsustainable long term but they're running critical payments infrastructure.
  - masukomi 4y ago
    as an outsider (and thus potentially ignorant of pitfalls): I'm a big fan of the strategy to add transpilers to modern languages so that we can start writing new code in them, have them output COBOL, and then eventually have enough of the codebase written in the new lang to swap over to it instead. I'm thinking of the Elixir->COBOL like this: https://github.com/TheFirstAvenger/cobol_to_elixir https://github.com/TheFirstAvenger/cobol_to_elixir Was speaking with the author about a year ago and he was having really good success with it.
    - jhugo 4y ago
      This again focuses on the language rather than the environment. The real issue is all the legacy integrations, and the runtime environment, not the language. A transpiler is solving the easiest part while leaving all the difficult problems unaddressed.
    - 4y ago
mikece 4y ago
Exactly! You will never learn anything about JCL from a COBOL textbook. Heck, I'm not sure a JCL textbook (if they exist?) would be of much help either. When I went to college I was in the last group of students whose client/server classes were all mainframe based. We had a class where JCL was taught and a valid answer for "Why is JCL syntax so irregular?" on the exams was: "Because it was invented in Berkeley in the 1960s and everyone was on drugs."
- schlauerfox 4y ago
  I took an IBM mainframe intro course on Coursera and it was pretty good. I learned how to use the editor and menu thing. It was very out of my windows/linux/PC experience.
  - ElectricalUnion 4y ago
    > the editor ed /s Well, you can invoke AIX and run ed, it works, but yes, ISPF, running in a 3270 terminal, is pretty weird. That being said, it's pretty much very interactive even under horrible latency because it sends the entire screen every repaint. 3270 is, in a retro way, what the web 1.0 would look like if we were limited to monospaced characters.
- ElectricalUnion 4y ago
  There was a ancient saying that new JCL is never written, just copied and modified until it works, because no one understands the entirely of it.
- p_l 4y ago
  The truth about JCL is actually worse than "they were on drugs". In fact, they gave themselves a goal of avoiding making it into a programming language, except unfortunately real life requirements meant it had to gather such features quickly. Other infamous components came because of need to specify in line all sorts of metadata for I/O, because the OS might not have a place to store it - this caused the infamous DD statement that /bin/dd is a joking refence to. In retrospective, one of the leads on JCL mentioned that they should have instead gone straight for a full programming language, that this way it would have better design.
shireboy 4y ago
This is true, but the niche should be a dev who knows COBOL IRL enough to translate to something newer. Much of the COBOL I've seen would be trivial to rewrite, just nobody wants to tackle it. A person who 1) Can read cobol 2) can communicate well with stakeholders and 3) can translate to NodeJS/Python/.NET should be able to fit this niche pretty well. I've done this before - translate green screen apps to ASP.NET. In my case, the company had (retiring) IT staff read the cobol and give us good "plain english". The actual ASP.NET code was trivial. That said, my one caveat is I don't feel like any language today has the longevity of these systems. That code was ASP.NET 3 MVC - new at the time, but outdated now. What stack do I pick today that will still be running in 30 years? HTML+JS+NodeJS seems the most likely candidate IMO, but then you get into the various frameworks-du-jur and it sort of falls apart. Would love HN opinions.
- goodpoint 4y ago
  Some banks tried to jump on the Java bandwagon when it was the hyped up thing of the moment and now many are going back to COBOL. > HTML+JS+NodeJS seems the most likely candidate IMO So that my bank can run npm install leftpad on their payment processors. Please tell me this is parody.
  - shireboy 4y ago
    Hah, well, right. I just meant from a longevity standpoint. What stack can I use today that is and will continue to be well supported for 30+ years?
    - canon123456 4y ago
    - jhugo 4y ago
      C, C++, probably Rust, various other relatively boring languages. If Node.js is even still used in 30 years it won't look anything like today's Node.js.
    - 4y ago
rst 4y ago
Here's a look at mainframe arcana from the perspective of someone with training only on POSIX/Windows era systems -- COBOL was the easy part. Figuring out how to format the program text and submit it to the compiler took... quite some time. https://medium.com/the-technical-archaeologist/hello-world-on-z-os-a0ef31c1e87f https://medium.com/the-technical-archaeologist/hello-world-o...

by jhugo 4y ago

ejb999 4y ago

this is the best answer.

hugg 4y ago

Yeah, this is what I learned too from working at a big government pension office

agumonkey 4y ago

the few I've seen, COBOL legacy is its own kind. It meshes decades of users, practices, tools and paradigms. We've been shown code that blend old original code with 3GL crude code generator with 4GL custom COBOL transpiled DSLs with monkey patching. It was really not pretty (to stay polite).

hermitdev 4y ago
My last project as an intern was to rewrite an old batch processed COBOL app into a simple webform in C#/ASP.Net. The COBOL app was nothing special, really. From what I recall, it was around 65 pages printed. Took me a while to comprehend what was going on, but the first 80% or so was basically just hard-coded rules to take action on based upon user input. Things like when "B", generate "X" & "Y". When "A", generate "X", "Y" & "Z" sort of thing. Nothing fancy, at all. Once I figured out what was going on, I basically just ran the COBOL through some regexs, transformed into an XML doc (don't judge me - it was early 2000s) and wrote the rules engine in maybe one or two screenfuls of C#. I did learn one thing, and that was COBOL has one up on 'goto'. Check out the control flow statement: MOVE NEXT SENTENCE. It's basically a goto, but it doesn't jump to a label, per se. Instead, it jumps to the next period in the source. Yes, in a big, blocky, verbose language like COBOL, where everything is in UPPER CASE, you're now looking for a teeny tiny period that is easily lost in the verbiage. Hands down, my least favorite programming language construct ever.
- agumonkey 4y ago
  You never ran into an ALTER ?
- JD1967 4y ago
  NEXT SENTENCE (not "MOVE NEXT SENTENCE") is sort of equivalent to "continue" in modern languages. In more "modern" COBOL's like COBOL-85, there is actually a "CONTINUE" which is essentially a no-op. Some COBOL shops instituted a "one-period-per-paragraph" rule (on the last statement in a paragraph) to avoid some of this. And COBOL-85 (thankfully) added scope delimiters (i.e. END-IF) to help avoid the issues with periods.
ElectricalUnion 4y ago
> COBOL transpiled DSLs That problem happens with any transpiled language really, now you have all the problems of the new language and all the problems of the target language, and you need to fix "supposedly compiled" output by hand sometimes.
- agumonkey 4y ago
  I've nothing against cobol, but I think it's worth there, because of the gap with a python like lang (IBM made one) and cobol. Coffeescript to es5 wasn't too hard to guess.

Zenst 4y ago

aye decades of COBOl here though I did it upon the wrong non-IBM platform, RIP ICL and Honeywell

klelatti 4y ago
Presumably these platforms have also lived on though. I think I remember reading about a Fujitsu contract to maintain a big U.K. government ICL derived system?
- Zenst 4y ago
  There isn't the work on the market for any of those and from my experience of working with on their contracts, they will all be tuped existing staff. As an aside I still have a zero-day for ICL mainframes running Gerorge that's decades old now and taking to my grave.
  - klelatti 4y ago
    Interesting - thanks. Won’t get fixed now. I’m guessing all emulated and running on x64 by now.
chasil 4y ago
Long live EXEC 8.
JD1967 4y ago
Yeah, I programmed in COBOL for 15 years on Unix systems... so I don't have any mainframe experience... I'm pretty good with the actual COBOL code, but as people have said, that's only a piece of it. Working with the environment, such as IBM mainframes, is a big piece. Which is sort of odd, because COBOL was supposed to be "common"...

kazinator 4y ago

"I'm gonna learn C and start an embedded firmware job!"

yodsanklai 4y ago
You got to start somewhere

peter303 4y ago

Like the nightmare language IBM OS DDL? (data definition language) I recall you have specify the physical layout of data files on disk. In UNIX this info is embedded in the file system and generally not needed to run a program.

ElectricalUnion 4y ago
> In UNIX this info is embedded in the file system and generally not needed to run a program. UNIX just considers that a file/stdin/stdout/stderr is a sequence of binary octets of arbitrary size, any information on how to deal with it is left entirely to the program. In a way, IBM VSAM and other record access methods are more like tables with types that a UNIX-like file sytem.

Stampo00 4y ago

The old pros are continuing to age out and retire or die. Places with COBOL systems want to keep their applications limping along instead of replacing them. The shortage of devs is only going to get worse. Remember when lock down started and some government systems built on COBOL started straining under the load? Rather than being dismissive, I'd encourage those with any interest at all to try to pick it up. We need folks to maintain it.

thr0wawayf00 4y ago
> We need folks to maintain it. Beware, maintaining those systems is absolute hell and the companies experiencing exodus are working their people into the ground because the workload is crushing them and they can't find replacements. A good friend of mine is an engineering director at a company that runs a massive COBOL mainframe platform and he always half jokes with me about picking it up. The money isn't that great at his company and the problems they have maintaining the system just blow my mind. The entire company sounds fundamentally unsustainable long term but they're running critical payments infrastructure.
- masukomi 4y ago
  as an outsider (and thus potentially ignorant of pitfalls): I'm a big fan of the strategy to add transpilers to modern languages so that we can start writing new code in them, have them output COBOL, and then eventually have enough of the codebase written in the new lang to swap over to it instead. I'm thinking of the Elixir->COBOL like this: https://github.com/TheFirstAvenger/cobol_to_elixir https://github.com/TheFirstAvenger/cobol_to_elixir Was speaking with the author about a year ago and he was having really good success with it.
  - jhugo 4y ago
    This again focuses on the language rather than the environment. The real issue is all the legacy integrations, and the runtime environment, not the language. A transpiler is solving the easiest part while leaving all the difficult problems unaddressed.
  - 4y ago

mikece 4y ago

Exactly! You will never learn anything about JCL from a COBOL textbook. Heck, I'm not sure a JCL textbook (if they exist?) would be of much help either. When I went to college I was in the last group of students whose client/server classes were all mainframe based. We had a class where JCL was taught and a valid answer for "Why is JCL syntax so irregular?" on the exams was: "Because it was invented in Berkeley in the 1960s and everyone was on drugs."

schlauerfox 4y ago
I took an IBM mainframe intro course on Coursera and it was pretty good. I learned how to use the editor and menu thing. It was very out of my windows/linux/PC experience.
- ElectricalUnion 4y ago
  > the editor ed /s Well, you can invoke AIX and run ed, it works, but yes, ISPF, running in a 3270 terminal, is pretty weird. That being said, it's pretty much very interactive even under horrible latency because it sends the entire screen every repaint. 3270 is, in a retro way, what the web 1.0 would look like if we were limited to monospaced characters.
ElectricalUnion 4y ago
There was a ancient saying that new JCL is never written, just copied and modified until it works, because no one understands the entirely of it.
p_l 4y ago
The truth about JCL is actually worse than "they were on drugs". In fact, they gave themselves a goal of avoiding making it into a programming language, except unfortunately real life requirements meant it had to gather such features quickly. Other infamous components came because of need to specify in line all sorts of metadata for I/O, because the OS might not have a place to store it - this caused the infamous DD statement that /bin/dd is a joking refence to. In retrospective, one of the leads on JCL mentioned that they should have instead gone straight for a full programming language, that this way it would have better design.

shireboy 4y ago

This is true, but the niche should be a dev who knows COBOL IRL enough to translate to something newer. Much of the COBOL I've seen would be trivial to rewrite, just nobody wants to tackle it. A person who 1) Can read cobol 2) can communicate well with stakeholders and 3) can translate to NodeJS/Python/.NET should be able to fit this niche pretty well. I've done this before - translate green screen apps to ASP.NET. In my case, the company had (retiring) IT staff read the cobol and give us good "plain english". The actual ASP.NET code was trivial. That said, my one caveat is I don't feel like any language today has the longevity of these systems. That code was ASP.NET 3 MVC - new at the time, but outdated now. What stack do I pick today that will still be running in 30 years? HTML+JS+NodeJS seems the most likely candidate IMO, but then you get into the various frameworks-du-jur and it sort of falls apart. Would love HN opinions.

goodpoint 4y ago
Some banks tried to jump on the Java bandwagon when it was the hyped up thing of the moment and now many are going back to COBOL. > HTML+JS+NodeJS seems the most likely candidate IMO So that my bank can run npm install leftpad on their payment processors. Please tell me this is parody.
- shireboy 4y ago
  Hah, well, right. I just meant from a longevity standpoint. What stack can I use today that is and will continue to be well supported for 30+ years?
  - canon123456 4y ago
  - jhugo 4y ago
    C, C++, probably Rust, various other relatively boring languages. If Node.js is even still used in 30 years it won't look anything like today's Node.js.
  - 4y ago

rst 4y ago

Here's a look at mainframe arcana from the perspective of someone with training only on POSIX/Windows era systems -- COBOL was the easy part. Figuring out how to format the program text and submit it to the compiler took... quite some time. https://medium.com/the-technical-archaeologist/hello-world-on-z-os-a0ef31c1e87f https://medium.com/the-technical-archaeologist/hello-world-o...