Join Early Retirement Today
Reply
 
Thread Tools Search this Thread Display Modes
Know COBOL? There could be a j*b for you!
Old 04-09-2020, 01:45 PM   #41
Recycles dryer sheets
 
Join Date: Nov 2015
Posts: 145
Know COBOL? There could be a j*b for you!

Apparently a LOT of legacy unemployment systems are still coded or partially coded in COBOL. Remarkably, not many young-uns know it. States are apparently hiring: https://www.dailymail.co.uk/news/art...ent-chaos.html

Next up: will I need to brush up on those JCL skills from long ago?
Potstickers is offline   Reply With Quote
Join the #1 Early Retirement and Financial Independence Forum Today - It's Totally Free!

Are you planning to be financially independent as early as possible so you can live life on your own terms? Discuss successful investing strategies, asset allocation models, tax strategies and other related topics in our online forum community. Our members range from young folks just starting their journey to financial independence, military retirees and even multimillionaires. No matter where you fit in you'll find that Early-Retirement.org is a great community to join. Best of all it's totally FREE!

You are currently viewing our boards as a guest so you have limited access to our community. Please take the time to register and you will gain a lot of great new features including; the ability to participate in discussions, network with our members, see fewer ads, upload photographs, create a retirement blog, send private messages and so much, much more!

Old 04-09-2020, 02:30 PM   #42
Give me a museum and I'll fill it. (Picasso)
Give me a forum ...
MRG's Avatar
 
Join Date: Apr 2013
Posts: 10,007
Quote:
Originally Posted by Potstickers View Post
Apparently a LOT of legacy unemployment systems are still coded or partially coded in COBOL. Remarkably, not many young-uns know it. States are apparently hiring: https://www.dailymail.co.uk/news/art...ent-chaos.html

Next up: will I need to brush up on those JCL skills from long ago?
Indeed there are. COBOL became popular in the late 60s-70s and into the 90s. Y2K didn't see many legacy systems replaced; only upgraded in COBOL because of risk. By then COBOL wasn't taught in many universities and definitely wasn't a cool language on your resume. Developers like writing in newer OO languages with all their cool tools. Who wants to maintain decades old code that nobody's wants to pay great money for?

Look for the lack of COBOL skillsets and 2038 date issues to be ignored.
MRG is offline   Reply With Quote
Old 04-10-2020, 05:39 AM   #43
Recycles dryer sheets
 
Join Date: Jan 2014
Location: Voorheesville, NY
Posts: 132
Quote:
Originally Posted by MRG View Post

Look for the lack of COBOL skillsets and 2038 date issues to be ignored.
What are the 2038 date issues?
jpeter1093 is offline   Reply With Quote
Old 04-10-2020, 05:51 AM   #44
Moderator Emeritus
aja8888's Avatar
 
Join Date: Apr 2011
Location: The Woodlands, TX
Posts: 12,642
When I was in college in the 1970's, I took about 4 courses in FORTRAN. Then I took one course in COBOL. That one COBOL course made me realize that no way was I going into IT, so I continued on and got my Mechanical Engineering degree. And the rest is history.....
__________________
Everyone has a plan until they get punched in the mouth...philosopher Mike Tyson
aja8888 is offline   Reply With Quote
Old 04-10-2020, 05:52 AM   #45
Recycles dryer sheets
 
Join Date: Nov 2008
Location: Louisville
Posts: 370
Quote:
Originally Posted by jpeter1093 View Post
What are the 2038 date issues?
I had to look it up, but here's the problem;

The Year 2038 problem (also called Y2038 or Y2k38 or Unix Y2K) relates to representing time in many digital systems as the number of seconds passed since 00:00:00 UTC on 1 January 1970 and storing it as a signed 32-bit integer. Such implementations cannot encode times after 03:14:07 UTC on 19 January 2038. Similar to the Y2K problem, the Year 2038 problem is caused by insufficient capacity used to represent time.
Masquernom is offline   Reply With Quote
Old 04-10-2020, 06:13 AM   #46
Give me a museum and I'll fill it. (Picasso)
Give me a forum ...
JoeWras's Avatar
 
Join Date: Sep 2012
Posts: 7,320
Quote:
Originally Posted by badatmath View Post
There are many places that still use mainframes besides the government - some of whom you probably do business with. It is not simple to "just rewrite it".
DW just retired from such a place. They will have mainframes for the foreseeable future.

It is not a sin.

Open source and Linux are not panaceas.

As for the 2038 problem: at my last megacorp, we started working on that in 2001 and had it fixed in a few years with all our new hardware roll out. They didn't want to go through that again. Of course, they've since been drifting to linux and may have accidentally inherited the problem in the switch over.
__________________
Retired Class of 2018


JoeWras is offline   Reply With Quote
Old 04-10-2020, 06:18 AM   #47
Give me a museum and I'll fill it. (Picasso)
Give me a forum ...
 
Join Date: Nov 2009
Posts: 5,961
Quote:
Originally Posted by aja8888 View Post
When I was in college in the 1970's, I took about 4 courses in FORTRAN. Then I took one course in COBOL. That one COBOL course made me realize that no way was I going into IT, so I continued on and got my Mechanical Engineering degree. And the rest is history.....
It was the one course in COBOL which began my move away from majoring in CS. I had a problem with the professor and the grade I received in the course, a grade which barely kept me off Dean's List. Then, the next course for CS majors I didn't like at all. I dropped it and changed my major to Economics, a much better major for me anyway. While I still liked programming, having CS as an equivalent minor still looked great on my resume and set me up to be a "big fish in a small pond" when I began my actuarial career a few years later.

Part of being an end-user included having to deal with actual systems analysts in the IT area. I liked dealing with them because I could speak their language, so to speak (and I knew enough COBOL), and they liked dealing with me compared to other end-users who usually knew very little about programming.
__________________
Retired in late 2008 at age 45. Cashed in company stock, bought a lot of shares in a big bond fund and am living nicely off its dividends. IRA, SS, and a pension await me at age 60 and later. No kids, no debts.

"I want my money working for me instead of me working for my money!"
scrabbler1 is offline   Reply With Quote
Old 04-10-2020, 07:39 AM   #48
Thinks s/he gets paid by the post
 
Join Date: Jun 2016
Posts: 1,263
When I took my first COBOL class as an electrical engineer I really didn't care for it.
After working as a student programmer for campus admin for a couple of years doing nothing but COBOL, I was assigned a LRU memory cache task in an systems programming class.

The instructor had stored records of numbers representing memory blocks on tape.
We were to read the data and and at the end spit out which blocks were still in memory.
All the students on the sysadmin side of the shop thought "this is a systems programming class, we have to use assembler". It took them 2 weeks of fiddling to learn how to access and read the tape drive in assembler. I think it took 5 minutes using COBOL.

When your only tool is a hammer, every problem becomes a nail.
Spock is offline   Reply With Quote
Old 04-10-2020, 08:03 AM   #49
Give me a museum and I'll fill it. (Picasso)
Give me a forum ...
MRG's Avatar
 
Join Date: Apr 2013
Posts: 10,007
Quote:
Originally Posted by Masquernom View Post
I had to look it up, but here's the problem;

The Year 2038 problem (also called Y2038 or Y2k38 or Unix Y2K) relates to representing time in many digital systems as the number of seconds passed since 00:00:00 UTC on 1 January 1970 and storing it as a signed 32-bit integer. Such implementations cannot encode times after 03:14:07 UTC on 19 January 2038. Similar to the Y2K problem, the Year 2038 problem is caused by insufficient capacity used to represent time.
Not just unix. Every IBM system, (mainframe, midrange, and UNIX) has the issue in one form or another. Mainframe and midrange systems are relative to midnight 1900, Unix per your comment is relative to 1970. There's some applications that use that date/time for sequencing data. It was used as a unique identity before some languages supported it.

Megacorp had used it for sequencing data . I remember a meeting pre-Y2K where the subject was brought up. As peer and I left the meeting we had a little sidebar. I asked how he thought we should fix this issue. His comment " if that code and database are still around in 2038 we have bigger issues". In 2020 that code is still running well.
MRG is offline   Reply With Quote
Old 04-10-2020, 08:44 AM   #50
Give me a museum and I'll fill it. (Picasso)
Give me a forum ...
Chuckanut's Avatar
 
Join Date: Aug 2011
Location: West of the Mississippi
Posts: 12,452
Quote:
Originally Posted by Masquernom View Post
I had to look it up, but here's the problem;

The Year 2038 problem (also called Y2038 or Y2k38 or Unix Y2K) relates to representing time in many digital systems as the number of seconds passed since 00:00:00 UTC on 1 January 1970 and storing it as a signed 32-bit integer. Such implementations cannot encode times after 03:14:07 UTC on 19 January 2038. Similar to the Y2K problem, the Year 2038 problem is caused by insufficient capacity used to represent time.
YIKES! I can see it now, space planes falling from the skies, banks losing all their records and keeping our money, self driving cars driving over cliffs, and my VCR will start blinking 12:00 all over again.
__________________
The worst decisions are usually made in times of anger and impatience.
Chuckanut is offline   Reply With Quote
Old 04-10-2020, 08:52 AM   #51
Thinks s/he gets paid by the post
John Galt III's Avatar
 
Join Date: Oct 2008
Posts: 2,135
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.
John Galt III is offline   Reply With Quote
Old 04-10-2020, 09:26 AM   #52
Give me a museum and I'll fill it. (Picasso)
Give me a forum ...
 
Join Date: Nov 2009
Posts: 5,961
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?
__________________
Retired in late 2008 at age 45. Cashed in company stock, bought a lot of shares in a big bond fund and am living nicely off its dividends. IRA, SS, and a pension await me at age 60 and later. No kids, no debts.

"I want my money working for me instead of me working for my money!"
scrabbler1 is offline   Reply With Quote
Old 04-10-2020, 10:08 AM   #53
Give me a museum and I'll fill it. (Picasso)
Give me a forum ...
MRG's Avatar
 
Join Date: Apr 2013
Posts: 10,007
Quote:
Originally Posted by scrabbler1 View Post
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.
MRG is offline   Reply With Quote
Old 04-13-2020, 05:12 AM   #54
Give me a museum and I'll fill it. (Picasso)
Give me a forum ...
target2019's Avatar
 
Join Date: Dec 2008
Location: Stuck in the mud somewhere in the NJ swamp
Posts: 7,266
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/04...=pocket-newtab
target2019 is offline   Reply With Quote
Old 04-13-2020, 06:23 AM   #55
Dryer sheet aficionado
 
Join Date: Apr 2013
Location: Pittsburgh
Posts: 31
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
CountryBoy is offline   Reply With Quote
Old 04-13-2020, 06:25 AM   #56
Thinks s/he gets paid by the post
 
Join Date: May 2014
Posts: 4,978
Quote:
Originally Posted by Chuckanut View Post
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.
athena53 is offline   Reply With Quote
Old 04-13-2020, 07:03 AM   #57
Thinks s/he gets paid by the post
jollystomper's Avatar
 
Join Date: Apr 2012
Posts: 3,731
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.
__________________
FIREd date: June 26, 2018 - wwwwwwhat a rush!
jollystomper is offline   Reply With Quote
Old 04-13-2020, 09:17 AM   #58
Confused about dryer sheets
 
Join Date: Jan 2018
Posts: 8
Quote:
Originally Posted by target2019 View Post
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/
snappytom is offline   Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Covid-19 and healthcare workers (over 50) monte1022 FIRE and Money 14 03-02-2020 12:00 PM
COVID-19 -based going to cash jitters? stephenson FIRE and Money 164 02-27-2020 11:08 AM

» Quick Links

 
All times are GMT -6. The time now is 12:25 AM.
 
Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2021, vBulletin Solutions, Inc.