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?

[Anonymous Coward]

cobol may not be hard, but the IBM mainframe environment/ecosystem those cobol apps run in is not trivial.

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.

Would you even be looking for a job?

[OrangeTide]

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.

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?

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

[jythie]

Yeah, I used to feel the same way about FORTRAN, then I discovered you could do the same tasks in Python with the right library, far more readable, and only marginally less efficient.

Re:COBOL Has Advantages

[Archtech]

That's the funniest thing I have read about software since the IT director who was quoted as saying, "We're going with XML because it's the fastest Internet protocol".

And that wasn't Dilbert - that was real life.

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.

It's not about COBOL, it's about the ecosystem

[crgrace]

When people are saying they need people to fill "COBOL jobs" they aren't actually looking for COBOL programmers. There are looking for people who are willing to jump into excruciatingly painful dead-end jobs dealing with obsolete technology and working just to keep something afloat.

I had an internship with a Fortune 500 company (not a tech company) working on COBOL software in the late 1990s. The COBOL part was easy. It is a pretty simple (but verbose) language and doesn't take long to learn if you've seen FORTRAN, Ada, or BASIC. What *was* really hard was learning how the reporting and monitoring systems worked (we were basically gathering data from food production machines, reporting and archiving it).

Basically, everything in this division was run on old IBM mainframes (actually new mainframes/minicomputers emulating old operating systems... MVS and AS/400 or something). You didn't have a command line where you did your compile and link stuff... oh no, you had to submit jobs in a very finicky format using the mainframe's JCL (job control language). It was heavily customized for no good reason (that I could tell) so only a few of the really acidic and unpleasant old-timers could help you get your stuff going. You couldn't look this stuff up on your own because it was basically macros built upon macros from I'm guessing the early 1970s.

Anyway, this internship was soul destroying. Like the worst job I ever had. I worked my ass off and barely accomplished anything because the simplest thing was so hard and no one knew what the hell was going on. Every so often a "consultant" from HQ (we were a remote site in a different state from the headquarters) would come, install something, and then he (always a he) would leave while everything broke. Even though my internship was to develop a specific piece of new functionality, I spent most of my time figuring out what was going wrong and patching it.

So technically, I have COBOL experience now, but really I have a bit of experience bashing my head against a custom one-of-a-kind wall, and that experience isn't transferable.

To add insult to injury, it wasn't even a high-paying internship. The only good thing about this company was the culture was everyone was out the door at 4PM (hours were strictly 8AM to 4PM). Once I stayed to 6:30PM to fix a production server that was mangled by a messed up JCL card. (Oh god, the JCL cards. Of course they weren't punch cards because this was the 1990s, but you had to format the commands AS IF THEY WERE FREAKING PUNCH CARDS I guess because they were reusing old punch card parsing code. So, if you put a JCL mnemonic in the wrong column, the job failed. I wish I were making this up, I really do, but I'm not.) Anyway, I stayed till 6:30PM one night and the plant manager was so excited with my "can-do" attitude that he gave me a "golden nickel" which was one free lunch at the plant cafeteria. Yes, this was six months of my sorry life.