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
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" :-/
open-cobol/bionic 1.1-2 amd64
COBOL compiler
When I worked at IBM not TOO long ago there were times when I had to fix a bug in WebSphere that only manifested on z/OS or zLinux and those were hands down the hardest bugs to fix. And that was a relatively modern codebase, by mainframe standards.
However, not all - I've personally been dealing peripherally with COBOL on UNIX/Linux via IBM or MicroFocus compilers for decades - and it even works on Windows :-O
e.g.
https://www.microfocus.com/en-us/products/net-express-server...
There's also tiny-cobol[0], but the project is dead and it only targets x86-32.
>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.
Mind blown.
Just FYI, my laptop has "Enter" clearly printed on both keys.
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.
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
They are just manual tests written up on literal, actual TPS reports (TPS = Test Procedure Specification) to be executed by humans.
And were widely used, at one point.
Where I worked, original test data was sparse and incomplete, and it avoided edge conditions. I, on the other hand, loved breaking stuff.
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.
Despite this story and others, still think I made the right call for me!
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.
https://www.amazon.com/System-370-Job-Control-Language/dp/04...
the language in itself is archaic but there's nothing difficult in it