COBOL for COVID?

Back when I was a mainframe programmer in the nineties, and all the new 'object oriented' nonsense was all the rage, I thought the new 'OO' stuff was harder to code in than mainframe stuff like COBOL. Why can't the millennials learn COBOL? Just too boomer and uncool, I would guess, ha ha.
 
Speaking of Date issues, I remember SAS making a change to its software around 2000 which cut my Y2K programming changes by about 1/3. They had a default feature which added 1900 to all year values within various 2-digit-year date formats. But the SAS change altered this default. Instead, to the year values it added 1900 if the year were greater than (or maybe >=) 50 and added 2000 if the year were less than (or maybe <=) 50. This provided some continuity for date formats which crossed into year 2000.


Anyone else here use SAS and remember this useful change?
 
Speaking of Date issues, I remember SAS making a change to its software around 2000 which cut my Y2K programming changes by about 1/3. They had a default feature which added 1900 to all year values within various 2-digit-year date formats. But the SAS change altered this default. Instead, to the year values it added 1900 if the year were greater than (or maybe >=) 50 and added 2000 if the year were less than (or maybe <=) 50. This provided some continuity for date formats which crossed into year 2000.


Anyone else here use SAS and remember this useful change?
Not as SAS programmer, used it a little but wasn't ever proficient in the language. The technique was "date windowing" and was used as a solution by some products.
 
This article is a few days old, but explains more about the ancient COBOL code, and lack of resources who can handle it. Someone quoted in the article suggests that a mainframe could handle the overload. Some states like MASS. are in better shape, as they bit the bullet and moved to more modern resources.

Why New Jersey’s Unemployment Insurance System Uses a 60-Year-Old Programming Language
https://slate.com/technology/2020/0...bol-coronavirus.html?utm_source=pocket-newtab
 
um... I'm intrigued! I got out of school in 1986, did a couple internships and my first job was as a COBOL instructor for CCAC (Community College Allegheny County) here in Pittsburgh. Wound up moving to the private sector, programmed almost exclusively in Mainframe COBOL until 1999 (when I suddenly got popular because of the Y2K drama), got an offer from BNY Mellon with a salary increase too good to be true.


Wound up moving from mainframe to Microfocus COBOL, loved it--no more of that godawful JCL to contend with. Anyway, when I was at Mellon I saw cobol programs that were still in use (with patches galore) from the early 1970s!



My last cobol program was in 2004, but it's funny how that code starts rolling back into your brain after umpteen years :)
 
As 2000 approached I had been in teaching for nearly a decade. Yet, I was offered a salary that would more than double my pay for a few years if I would work on fixing the Y2K problem. I did not take the bait because my teaching job came with one thing nobody was offering anymore - a pension. It was a smart decision. The old COBOL programmers were dropped like hot potatoes by the end of 2001. I was shocked. Shocked!!

That happened to a friend of DH's. Lured away from his old job for big bucks, thrown onto the tarmac after 1/1/2001.

I loved Fortran- learned it in college, did my own keypunching, went through the process of turning in my deck, waiting for output, finding it had crashed, turning in a corrected deck...

I was not impressed with COBOL- I once had to give a COBOL programmer a formula to approximate a square root (he was fitting points to a line) because COBOL didn't have a square root function.
 
Anyone who does not have access to a mainframe but wants to brush up on their COBOL skills (with all this free time they now have :)) can try using a COBOL compiler than runs on Linux or Windows, such as GnuCOBOL (https://sourceforge.net/projects/open-cobol/). Source code is provided to compile it using C (it uses the configure/make/make install process). The GnuCOBOL compiler actually translates COBOL source to C and then executes it using the C compiler. You do not even have to deal with JCL.
 

This article brings up a lot of good points. While COBOL is an older language and uncool by today's standards, it is really not the cause of failing systems. In the mainframe world IBM continues to support and invest in COBOL and other higher level languages by enhancing the z/OS Language Environment (LE) that is the common library the compilers utilize.

Unfortunately there is very little new development being done with COBOL, if anything it is to add required features to existing applications. This all comes down to maintenance work which as pointed out in an earlier post requires a lot of analysis to begin especially if you are unfamiliar with the code. Combine that with pressure situations, abends, lack of resources, unrealistic deadlines the simple answer is No Thanks ..... I'll Pass.

I have been in IT for over 35 years, stuck in an OMY loop at the moment. Have done decades of COBOL, not so much in the past 10 years.
The original article about New Jersey looking for COBOL volunteers makes me chuckle. I hope that the people filing for unemployment are able to do so, but letting volunteers into secure mainframe systems that contain a lot of personal information just seems like a bad idea. My take on this is that NJ is replaying the old strategy of "throwing more people at the problem" until it is fixed.
For those interested, here is the link to sign up:
https://forms.business.nj.gov/tech/
 
Back
Top Bottom