6 ms·

How hard is cobol to pick up and learn at the level needed to contribute? I'm sure there are many no longer employed programmers in the tri state area that migh

How hard is cobol to pick up and learn at the level needed to contribute? I'm sure there are many no longer employed programmers in the tri state area that might be able to help

non-entity 7y ago
I imagine it's pretty difficult. I'm not a mainframe programmer, but from my understanding you not only have to understand the COBOL languages, but various mainframe environment parts like the OS, APIs, databases, etc.
- commandlinefan 7y ago
  I did mainframe COBOL for a few years in the 90’s (Y2K fixes). It’s actually not that difficult - I could probably bring a Java developer up to speed on it in less than a month. COBOL is actually extremely easy to program in, but it’s also limited in its expressiveness, so you end up repeating yourself a lot, which leads to complex debugging sessions.
- OGWhales 7y ago
  If you are already a decent programmer then switching to cobol can be easy. Cobol still uses the same logic, just with less fancy tools available. That other stuff really isn’t that hard. Most of it is copy and paste-able once someone explains it to you. It’s really easy. It could also likely be handled by someone else for a situation like this with new-comers simply writing cobol.
Analemma_ 7y ago
The thing about old COBOL systems is, the language isn't the problem. Snark aside, it isn't that bad. The major issue is the code written in it. Remember, a lot of COBOL code comes from a time before a lot of programming best practices were discovered. Structured programming-- as in, actually having function calls instead of just GOTO statements everywhere-- was a novel hoity-toity concept when COBOL first existed. Relational databases? Forget about it, they won't exist for another decade and a half. You get flat files; if you're lucky there might be field separators, if you're unlucky you'll have to find the column widths in the code somewhere. And don't even think that any of it is documented. That's the sort of thing you're taking on when you jump into a legacy COBOL system.
- ravenstine 7y ago
  That, and I don't imagine there's any tests written for a lot of these systems. :(
  - bitwize 7y ago
    There are plenty of tests written for them. They are just manual tests written up on literal, actual TPS reports (TPS = Test Procedure Specification) to be executed by humans.
    - spitfire 7y ago
      My god. Are you serious? TPS reports are real?
      - jedieaston 7y ago
        https://en.wikipedia.org/wiki/TPS_report https://en.wikipedia.org/wiki/TPS_report And were widely used, at one point.
  - DrScump 7y ago
    One advantage of a legacy system is that you can create your own great test data just by making appropriate extracts of your existing legacy data. Where I worked, original test data was sparse and incomplete, and it avoided edge conditions. I, on the other hand, loved breaking stuff.
- dwaltrip 7y ago
  That's absolutely terrifying.
- justmyopinion42 7y ago
  Come on now. That kind of go to programming was primarily pre- 1980 (remember the Alter verb - pretty powerful and used a lot in the late ‘60‘s/early ‘70’s). Ha! Alter was used to Change a goto statement to go somewhere else. I only saw it where the key driver paragraphs only had one instruction, the goto. That was before goto depending on existed in the ANSI instruction set. But that stuff was wasshed out when new compilers no longer get supported the verb. Point is, languages aren’t static, they grow and change as do programming practices. I saw another post claim that COBOL programs primarily used flat files and had no concept of ISAM/VSAM/DB2 or relational constructs. Nothing could be further from the truth! In the late ‘70’s COBOL became the primary langauge for processing in CICS or IMS real time transactions. Flat fileS, eh. Ha Youdon structured design was introduced about 1976 and 1977 - by 1980 only the very smallest IT shops weren’t coding in compliance with structured programming standard that did not allow goto’s. A programmer was unlikely to find a job in a good shop without structured coding experience. Given New Jersey only began constructing applications in the 1980’s, then evolved for 30+ years - it is very likely most of the code containing go to’s and like code that were difficult to maintain were updated and rewritten in conjunction with other enhancements. Major enhancement projects were often used to fund rewrites in this manner. I am not saying New Jersey did this, I am saying any competently managed IT organization would have done this because that was considered best practices. Let someone who has actually examined the code tell us how bad it actually is. Heck, if they are really an SDLC shop, there may actually be documentation! Lol
agumonkey 7y ago
depends on the codebase, some people showed me long lasting, semi patched, semi generated code and it was not pretty the language in itself is archaic but there's nothing difficult in it
Aloha 7y ago
I didnt find it too hard, I played with it a little in the IBM master the mainframe challenge. The hardest part for me, is IO was not handled by the application, so all your file IO was setup by the JCL job that called the cobol program, which just feels weird. It's actually quite easy to read, and much closer to plain english than say, C.
- insomniacity 7y ago
  They came to my computer science course to pitch that challenge. I got as far as logging in to the mainframe and doing the first task before I stopped and thought “wtf am I doing? Why am I wasting time on this!” Despite this story and others, still think I made the right call for me!
NikolaNovak 7y ago
Programming a net new isolated Cobol may not be difficult for experienced programmer. Difficulty (and/or downright hate, for many;) lies in 1. Ecosystem - obscure libraries rules and os that don't jive with posix-like mindset 2. Legacy code - having to dig into a ginormous monolithic program and figure out what some obscure pieces of code do, untouched and undocumented by anybody in your team, with ridiculous interdependencies and complexities. So it tends to be more of "how hard is Cobol in this particular application for this specific client" :-/
- gecko 7y ago
  Is there any way to learn the ecosystem? Last time I looked, you couldn’t just spin up z/OS in VMware and start hacking, which made it hard for me to figure out how I’d actually learn.
  - thaumaturgy 7y ago
    Intern or junior-level in a COBOL environment, unfortunately. Like others are saying, the problem with COBOL isn't (just) the language itself, it's all of the decades of very delicate cruft that has grown up around it. COBOL-the-language is absurdly simple to the point of being a little brain-damaged; but you have to be able to work in an environment where there's really close coupling between COBOL and its host operating system, and where minor code changes can have unintended consequences in seemingly unrelated applications, and the database isn't transactional, and there's no version control, and...
  - sigjuice 7y ago
    apt search cobol found this. open-cobol/bionic 1.1-2 amd64 COBOL compiler Also, I was hoping to find COBOL on learnxinyminutes.com, but didn't :/
    - dpedu 7y ago
      Open-cobol works, but be aware that it translates your source to C and then compiles that. If that doesn't matter to you, great! There's also tiny-cobol[0], but the project is dead and it only targets x86-32. [0] http://tiny-cobol.sourceforge.net/ http://tiny-cobol.sourceforge.net/
wolco 7y ago
Not too hard but a little unforgiving. JCL was harder to deal with.
- passer_byer 7y ago
  This is the only book you need for JCL. Called, either the Brown-Blue book or Blue-Brown book. https://www.amazon.com/System-370-Job-Control-Language/dp/0471031550 https://www.amazon.com/System-370-Job-Control-Language/dp/04...
  - wolco 7y ago
    When I had to learn it it was on a s/390. Would the 370 translate well?
tyingq 7y ago
The ecosystem would be the harder part. It's either a 360 mainframe, AS/400, HP MPE, etc. The editors, compilers, runtime, batch schedulers, etc, are all different.
sbierwagen 7y ago
Here's a taste: https://qntm.org/zomg https://qntm.org/zomg >System z is a living fossil; it is computing archaeology; computing palaeontology. System z is an example of the principle "If it ain't broke, don't fix it" carried to its logical extreme. System z and its predecessors haven't broken for forty-five years: the "z" stands for "zero downtime" and some of these machines have been running continuously for decades without a reboot. Nor, therefore, have any of them ever been "fixed". >It uses EBCDIC, a character encoding wholly incompatible with ASCII featuring such delights as non-contiguous letter sequences. It was, from 1983 to 2000, a 31-bit operating system. (Yes, thirty-one.) It does things with virtualisation of system resources and operating systems themselves that were thirty years ahead of their time, but all the interaction with z machines is still performed through an archaic green screen system from the 1970s, running in an emulator, with a 24x80 character screen. The screen is 80 characters wide because that is how many characters you could fit on a punch card. >The output from the Job Entry System, however, is 132 characters wide, because that was how many characters you could fit on the line printer where the output came out. Nowadays, of course, the output comes to the green screen. So you always have to scroll left and right to see all of it. The keys for scrolling left and right are F7 and F8. For scrolling up and down? F10 and F11. No, Page Up and Page Down will do nothing. >To enter a command? You hit the right Ctrl key. "Return" will do nothing. "Enter" will work, of course, but, AS YOU KNOW, "Return" and "Enter" are separate keys on your keyboard. "Return" is just above the right Shift key. "Enter" is way over next to the numeric keypad.
- perl4ever 7y ago
  "AS YOU KNOW, "Return" and "Enter" are separate keys on your keyboard" Just FYI, my laptop has "Enter" clearly printed on both keys.
  - exhilaration 7y ago
    Things were different in the old days, young padawan: https://commons.wikimedia.org/wiki/File:4800-52-mainframe-dumb-terminal-keyboard.jpg https://commons.wikimedia.org/wiki/File:4800-52-mainframe-du...

How hard is cobol to pick up and learn at the level needed to contribute? I'm sure there are many no longer employed programmers in the tri state area that might be able to help

non-entity 7y ago

I imagine it's pretty difficult. I'm not a mainframe programmer, but from my understanding you not only have to understand the COBOL languages, but various mainframe environment parts like the OS, APIs, databases, etc.

commandlinefan 7y ago
I did mainframe COBOL for a few years in the 90’s (Y2K fixes). It’s actually not that difficult - I could probably bring a Java developer up to speed on it in less than a month. COBOL is actually extremely easy to program in, but it’s also limited in its expressiveness, so you end up repeating yourself a lot, which leads to complex debugging sessions.
OGWhales 7y ago
If you are already a decent programmer then switching to cobol can be easy. Cobol still uses the same logic, just with less fancy tools available. That other stuff really isn’t that hard. Most of it is copy and paste-able once someone explains it to you. It’s really easy. It could also likely be handled by someone else for a situation like this with new-comers simply writing cobol.

Analemma_ 7y ago

The thing about old COBOL systems is, the language isn't the problem. Snark aside, it isn't that bad. The major issue is the code written in it. Remember, a lot of COBOL code comes from a time before a lot of programming best practices were discovered. Structured programming-- as in, actually having function calls instead of just GOTO statements everywhere-- was a novel hoity-toity concept when COBOL first existed. Relational databases? Forget about it, they won't exist for another decade and a half. You get flat files; if you're lucky there might be field separators, if you're unlucky you'll have to find the column widths in the code somewhere. And don't even think that any of it is documented. That's the sort of thing you're taking on when you jump into a legacy COBOL system.

ravenstine 7y ago
That, and I don't imagine there's any tests written for a lot of these systems. :(
- bitwize 7y ago
  There are plenty of tests written for them. They are just manual tests written up on literal, actual TPS reports (TPS = Test Procedure Specification) to be executed by humans.
  - spitfire 7y ago
    My god. Are you serious? TPS reports are real?
    - jedieaston 7y ago
      https://en.wikipedia.org/wiki/TPS_report https://en.wikipedia.org/wiki/TPS_report And were widely used, at one point.
- DrScump 7y ago
  One advantage of a legacy system is that you can create your own great test data just by making appropriate extracts of your existing legacy data. Where I worked, original test data was sparse and incomplete, and it avoided edge conditions. I, on the other hand, loved breaking stuff.
dwaltrip 7y ago
That's absolutely terrifying.
justmyopinion42 7y ago
Come on now. That kind of go to programming was primarily pre- 1980 (remember the Alter verb - pretty powerful and used a lot in the late ‘60‘s/early ‘70’s). Ha! Alter was used to Change a goto statement to go somewhere else. I only saw it where the key driver paragraphs only had one instruction, the goto. That was before goto depending on existed in the ANSI instruction set. But that stuff was wasshed out when new compilers no longer get supported the verb. Point is, languages aren’t static, they grow and change as do programming practices. I saw another post claim that COBOL programs primarily used flat files and had no concept of ISAM/VSAM/DB2 or relational constructs. Nothing could be further from the truth! In the late ‘70’s COBOL became the primary langauge for processing in CICS or IMS real time transactions. Flat fileS, eh. Ha Youdon structured design was introduced about 1976 and 1977 - by 1980 only the very smallest IT shops weren’t coding in compliance with structured programming standard that did not allow goto’s. A programmer was unlikely to find a job in a good shop without structured coding experience. Given New Jersey only began constructing applications in the 1980’s, then evolved for 30+ years - it is very likely most of the code containing go to’s and like code that were difficult to maintain were updated and rewritten in conjunction with other enhancements. Major enhancement projects were often used to fund rewrites in this manner. I am not saying New Jersey did this, I am saying any competently managed IT organization would have done this because that was considered best practices. Let someone who has actually examined the code tell us how bad it actually is. Heck, if they are really an SDLC shop, there may actually be documentation! Lol

agumonkey 7y ago

depends on the codebase, some people showed me long lasting, semi patched, semi generated code and it was not pretty the language in itself is archaic but there's nothing difficult in it

Aloha 7y ago

I didnt find it too hard, I played with it a little in the IBM master the mainframe challenge. The hardest part for me, is IO was not handled by the application, so all your file IO was setup by the JCL job that called the cobol program, which just feels weird. It's actually quite easy to read, and much closer to plain english than say, C.

insomniacity 7y ago
They came to my computer science course to pitch that challenge. I got as far as logging in to the mainframe and doing the first task before I stopped and thought “wtf am I doing? Why am I wasting time on this!” Despite this story and others, still think I made the right call for me!

NikolaNovak 7y ago

Programming a net new isolated Cobol may not be difficult for experienced programmer. Difficulty (and/or downright hate, for many;) lies in 1. Ecosystem - obscure libraries rules and os that don't jive with posix-like mindset 2. Legacy code - having to dig into a ginormous monolithic program and figure out what some obscure pieces of code do, untouched and undocumented by anybody in your team, with ridiculous interdependencies and complexities. So it tends to be more of "how hard is Cobol in this particular application for this specific client" :-/

gecko 7y ago
Is there any way to learn the ecosystem? Last time I looked, you couldn’t just spin up z/OS in VMware and start hacking, which made it hard for me to figure out how I’d actually learn.
- thaumaturgy 7y ago
  Intern or junior-level in a COBOL environment, unfortunately. Like others are saying, the problem with COBOL isn't (just) the language itself, it's all of the decades of very delicate cruft that has grown up around it. COBOL-the-language is absurdly simple to the point of being a little brain-damaged; but you have to be able to work in an environment where there's really close coupling between COBOL and its host operating system, and where minor code changes can have unintended consequences in seemingly unrelated applications, and the database isn't transactional, and there's no version control, and...
- sigjuice 7y ago
  apt search cobol found this. open-cobol/bionic 1.1-2 amd64 COBOL compiler Also, I was hoping to find COBOL on learnxinyminutes.com, but didn't :/
  - dpedu 7y ago
    Open-cobol works, but be aware that it translates your source to C and then compiles that. If that doesn't matter to you, great! There's also tiny-cobol[0], but the project is dead and it only targets x86-32. [0] http://tiny-cobol.sourceforge.net/ http://tiny-cobol.sourceforge.net/

wolco 7y ago

Not too hard but a little unforgiving. JCL was harder to deal with.

passer_byer 7y ago
This is the only book you need for JCL. Called, either the Brown-Blue book or Blue-Brown book. https://www.amazon.com/System-370-Job-Control-Language/dp/0471031550 https://www.amazon.com/System-370-Job-Control-Language/dp/04...
- wolco 7y ago
  When I had to learn it it was on a s/390. Would the 370 translate well?

tyingq 7y ago

The ecosystem would be the harder part. It's either a 360 mainframe, AS/400, HP MPE, etc. The editors, compilers, runtime, batch schedulers, etc, are all different.

sbierwagen 7y ago

Here's a taste: https://qntm.org/zomg https://qntm.org/zomg >System z is a living fossil; it is computing archaeology; computing palaeontology. System z is an example of the principle "If it ain't broke, don't fix it" carried to its logical extreme. System z and its predecessors haven't broken for forty-five years: the "z" stands for "zero downtime" and some of these machines have been running continuously for decades without a reboot. Nor, therefore, have any of them ever been "fixed". >It uses EBCDIC, a character encoding wholly incompatible with ASCII featuring such delights as non-contiguous letter sequences. It was, from 1983 to 2000, a 31-bit operating system. (Yes, thirty-one.) It does things with virtualisation of system resources and operating systems themselves that were thirty years ahead of their time, but all the interaction with z machines is still performed through an archaic green screen system from the 1970s, running in an emulator, with a 24x80 character screen. The screen is 80 characters wide because that is how many characters you could fit on a punch card. >The output from the Job Entry System, however, is 132 characters wide, because that was how many characters you could fit on the line printer where the output came out. Nowadays, of course, the output comes to the green screen. So you always have to scroll left and right to see all of it. The keys for scrolling left and right are F7 and F8. For scrolling up and down? F10 and F11. No, Page Up and Page Down will do nothing. >To enter a command? You hit the right Ctrl key. "Return" will do nothing. "Enter" will work, of course, but, AS YOU KNOW, "Return" and "Enter" are separate keys on your keyboard. "Return" is just above the right Shift key. "Enter" is way over next to the numeric keypad.

perl4ever 7y ago
"AS YOU KNOW, "Return" and "Enter" are separate keys on your keyboard" Just FYI, my laptop has "Enter" clearly printed on both keys.
- exhilaration 7y ago
  Things were different in the old days, young padawan: https://commons.wikimedia.org/wiki/File:4800-52-mainframe-dumb-terminal-keyboard.jpg https://commons.wikimedia.org/wiki/File:4800-52-mainframe-du...