Slashdot Mirror
Do You Know Cobol? If So, There Might Be a Job for You. (wsj.com)
Despite its advanced age, Cobol is still the most prevalent programming language in the financial-services industry world-wide. Software programmed in Cobol powers millions of banking transactions every day and underpins critical computer mainframes. WSJ: And Cobol isn't going away anytime soon. Banks and other companies have come to the uncomfortable realization that ripping out old mainframes is pricey and complicated. Transitioning to new systems is likely to take years, and besides, a lot of the older tech works just fine. The problem is that Cobol isn't popular with new programmers. So, with a generation of Cobol specialists retiring, there is a continuing hunt to find a new generation of programmers to service this technology. In Texas, Mr. Hinshaw's (an anecdote in the story) company, the Cobol Cowboys, a group of mostly older programmers, is training U.S. military veterans in the programming language. Accenture is coaching hundreds of Cobol programmers every year in India and the Philippines to work at banks. In Malaysia, one consultancy that provides engineers versed in Cobol for its clients, iTAc MSC Outsourcing, has adopted the slogan "Keeping the Dinosaurs Alive." A host of companies offer online courses in Cobol in places like South Africa, India and Bangladesh. Developing economies are key technology-outsourcing centers for banks. Further reading: Major Banks and Parts of Federal Gov't Still Rely On COBOL, Now Scrambling To Find IT 'Cowboys' To Keep Things Afloat.
Sure I'll go ahead and learn what I need to to keep your stack afloat.
What's that? You don't want to pay me a reasonable wage? Well then! I guess we have a problem indeed. Scramble on, fine HR folks at "Major Banks and Parts of Federal Gov't"!
I tend to rant.
So, if you are in the U.S. and you know Cobol already, you might get a few years of employment out of it. However, such jobs will go overseas, too.
Simply knowing COBOL isn't the deciding factor. Could I stomach being employed in the banking industry and facilitating the awful shit they pull? No. So whether I know COBOL or not is irrelevant.
The way COBOL programs are structured I think you had to have been programming in the 1970's to really understand the idioms and work flow. That means you may have been on the job for 40+ years already, putting you pretty close to retirement age if you were one of the younger folks to pick up COBOL in the late 1970's.
We're going to hit a brick wall in about 5 years on this, and some businesses will have to learn an expensive lesson about the sunk cost fallacy.
“Common sense is not so common.” — Voltaire
Stupid question here, but if big businesses are having all of their older, experienced programmers retiring and none of their younger programmers have the skills, why aren't they paying to train people that already work for them? Seems like that would be a lot easier and cheaper, plus they have the added bonus of already knowing what your business does/needs and how it works.
Why [ay to train when you can make vague promises to the under-employed programmers who then train themselves on their own dime. Hell, you won't even need to hire all of them, just the best 10%.
I'm a minority race. Save your vitriol for white people.
I remember in about 1991 people were talking about how Cobol was "dead" and it would soon go away. I checked and found that over 100 billion lines of Cobol code were used in vital business systems every day.
In about 1995 there was another wave of "Cobol is dead". I checked the same sources and now it was over 200 billion lines.
Reality is that which doesn't change just because we don't like it.
I am sure that there are many other solipsists out there.
But then again, so could almost any other decent general-purpose computer language.
Depends but honestly, not really. I've worked C++, Java, COBOL and RPGLE. Most modern languages are general purpose like you said, and as such have to have libraries and what not added to them to make them SQL/Database/sockets etc aware. COBOL and RPGLE are pretty much specifically written to work with files/tables/transformations. Of course, the trade off is that those two languages become horrible for things outside that task.
Good example. In RPGLE database tables are files (actually the file concept came way before the table concept but I digress). You treat then just like you would any other file. Want a struct that matches the layout of a file (database table) you just define it to be like that file.
dcl-ds SomeStruct likerec( SomeRec : *all ) inz;
That's it. When you update the layout of the table, a quick recompile of the program updates the program too with no code change. You don't have to add getters, you don't have to add setters, none of that stuff that would be needed in Java or C++. If you want to store something from the database in that struct its
read SomeStruct SomeRec;
Change some values and then to update that changes back to the database
SomeStruct.SomeField = 'New Value';
update SomeStruct SomeRec;
COBOL is pretty much the same way except the op-codes are a bit more verbose as you indicated. Again, I'm not saying RPGLE or COBOL are better than C++ or Java or what have you. What I am saying is that they are languages that were developed for a very specific purpose and as such they are incredibly honed into doing that purpose quickly.
COBOL can slice and dice data in ways C and SQL can't even dream of.
I think that's a bit overselling it. Even the best COBOL can be emulated in C++, the catch is that somethings in COBOL are made a lot more complicated in C++. One thing is that COBOL has built-in understanding of how to build reports that will be printed. That's because COBOL was made to specifically address that kind of stuff so it's no wonder that in COBOL you can instruct a report to be printed with a single line of code. You can do roughly the same in C++ or Java but you're pulling in a ton of libraries to get that done.
Again, the folks who have used RPGLE and COBOL all their life, they'll swear by it. And I get it. For things like taking in massive amounts of records and doing the exact same operation on upteen billion records, RPGLE and COBOL cannot be beat because they were written to do exactly that. However, want to do some cool website UI? Yeah, RPGLE and COBOL are horrible choices to do that in. Want to do some sort of RESTful API? .NET/Java/Shit probably an abacus are all going to be way better choices than RPGLE or COBOL. The two are very, very specific languages in what they will and won't do, and processing billions upon billions of records like Charlie Sheen processes lines of cocaine, is exactly what these languages have had the last four to five decades to refine. You'll be incredibly hard pressed to find compiled output that matches their speed, that used a HLL outside of them.