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.

Comments

Seriously?

[SCVonSteroids]

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"!

Re:Seriously?

[quarrel]

Exactly this.

COBOL isn't hard. Whatever, it's a language.

But if you want to take smart people away from their shiny modern languages and dev stacks, and ask them to put up with bureaucracy, then you need to pay them at least commensurate salaries to what they'd get elsewhere (if not MORE).

These are really stories about banks not wanting to pay talented devs to put up with their BS.

Re:Seriously?

[Tablizer]

COBOL isn't hard. Whatever, it's a language.

The hard part is reading and following piles of legacy code, some of which may have been written in the "go to" days.

Re:Seriously?

[DarkOx]

No even that is not 'hard' tedious often but not hard. People thought it was going to be hard, until they actually tried around y2k and it turned out to be not hard just a lot of work.

The hard part if there is a hard part is supporting the stack around it. What people, especially people on Slashdot who wrote some Microfocus COBOL in Windows for a college course some time, about COBOL is it does not run in vacuum. Its not the COBOL program that is hard. Its the fact that COPYBOOK is referenced in 65 different programs. Its the 500 JCL job steps before and after with their sync sorts and COND statements. Its the FTP and character conversion steps; and stuff that is scarping CICS and CICS web interfaces around the COBOL you need to worry over.

All this stuff amounts to Rube Goldburg devices that happened to be constructed from very very reliable and consistently operating components. So it all works and humms along for decades but try and replace any part of it with something new and feel the pain of running a square peg into a round hole.

Re:Seriously?

[CaptainDork]

I programmed in COBOL. I liked it.

It was easy for me to understand.

What was damned near impossible was straightening out the spaghetti code already in place.

The way to understand an existing system is to fuck around with it and get inside the programmer's head.

Once done, I can anticipate what's coming.

When a system is a hybrid of decades of code by quacks and pros alike, it's a goddam maze.

Management doesn't take that as an excuse and I excused myself from the management.

While the wage was competitive, the stress wasn't worth it.

I'll do startup with COBOL, but there's no market for that.

Maybe not a good career move in the U.S.

[ItsJustAPseudonym]

Accenture is coaching hundreds of Cobol programmers every year in India and the Philippines to work at banks.

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.

It's the context of the job that matters

[macraig]

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.

not again! they don't want COBOL they want CICS

[Anonymous Coward]

oh, not again ... they do not want COBOL programmers, they want programmers who know CICS transactions and DB2, VSAM, etc, who have enough experience to come in and fix production business logic ... I see this article every year or two and it's ... let's all say it together ... NOT COBOL PROGRAMMERS ANYONE WANTS ... if you know COBOL but don't know CICS, you will not get a job... and, hey, there is a huge glut of out of work CICS experts to pick from.

Re:Do You Know Cobol? If So, There Might Be a Job

[DeBaas]

I'll learn a language that has an IF MIGHT loop, looks awesome!

Re:Stupid question

[goose-incarnated]

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

Re:Repost

[Archtech]

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.

Re:Most prevalent? No.

[shadowknot]

It really isn't a stupid anecdote. Go to SHARE or GSE in Europe, you'll see representatives from the largest financial, retail and governmental industries who represent the bulk of transactional computing in the world. Practically every debit/credit/charge card swipe goes through a COBOL program, and these aren't "legacy" systems that are simply being maintained but systems in active development. I know personally of programs that have been written to facilitate new features like various NFC payment technologies recently. I will grant you that it's a largely invisible sector of the IT industry, if I wasn't in it I would probably still be ignorant to it too.

Re:First?

[slickwillie]

He would have been first if he didn't have to type all that stuff:

IDENTIFICATION DIVISION.
PROGRAM-ID. FIRST.
PROCEDURE DIVISION.
DISPLAY 'First'.
STOP RUN.

COBOL Has Advantages

[sycodon]

You can be a snobby all you want about your C and SQL databases, but one thing two combinations will never do is what COBOL does every night, weekly, etc.

That is process millions...I mean MILLIONS of records in a single night, producing bills, checks, statements, etc.

COBOL is optimized for record processing, not pretty pictures, drop down menus, HTML, etc.

COBOL has once focus:

1. Get the data in
2. Transform it
3. Get the data back out.

COBOL can slice and dice data in ways C and SQL can't even dream of.

You don't write Websites in COBOL. You do the serious work that involves billions of dollars of transactions. Reliably, repeatedly.

Re:COBOL Has Advantages

[slack_justyb]

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.

Re: Would you even be looking for a job?

[thomn8r]

and Michigan

For the love of god and all that is holy - is there any 3rd-world country they *won't* exploit?