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.
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
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.