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

Re:Wow, it's like Code Talkers

[Dzimas]

Someday, they will die out but for now they have a use!

The same can be said for *any* technical skill.

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?

[pgmrdlm]

Sorry, I remember y2k bug. Cobol programmers brought down serious money. When there are no other cobol programmers, there will be serious money for them again. Do you know how many MILLIONS of lines of code there is still in cobol?
hink COBOL is dead? About 95 percent of ATM swipes use COBOL code, Reuters reported in April, and the 58-year-old language even powers 80 percent of in-person transactions. In fact, Reuters calculates that thereâ(TM)s still 220 billion lines of COBOL code currently being used in production today, and that every day, COBOL systems handle $3 trillion in commerce. Back in 2014, the prevalence of COBOL drew some concern from the trade newspaper American Banker.hink COBOL is dead? About 95 percent of ATM swipes use COBOL code, Reuters reported in April, and the 58-year-old language even powers 80 percent of in-person transactions. In fact, Reuters calculates that thereâ(TM)s still 220 billion lines of COBOL code currently being used in production today, and that every day, COBOL systems handle $3 trillion in commerce. Back in 2014, the prevalence of COBOL drew some concern from the trade newspaper American Banker.
That is from 2017.
https://thenewstack.io/cobol-everywhere-will-maintain/
You don't think that many lines of cobol will not offer top dollar so ATM's, hospitals, insurance claims systems and what not do not fail. Are you really as stupid as that?

Re:Seriously?

[Anonymous Coward]

It's nonsense anyway, the idea that Cobol is the most prevalent language in financial services still is complete and utter drivel.

I've worked for a number of financial services organisations, including banks, and I've not come across any still using it. After the whole Y2K drama and the amount they had to spend on contractors they spent the following decade deprecating it, and it's nowhere to be seen in the vast majority of financial services organisations anymore.

If you really want to know what the "most prevalent programming language in the financial-services industry world-wide" is, then it's Java, followed by C# and C++. R, Python, and SAS are fairly common in analytics work, and other specialist areas like quantitative analysis use the above coupled with a whole bunch of more niche language like F# and Ocaml (e.g. Credit Suisse), or even home grown languages like Slang at Goldman Sachs.

But Cobol? Yeah no, where did Slashdot find this article? 1999?

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?

[eth1]

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.

No, they're not going to pay well. Why do think they're doing this (from TFS):

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

Can't wait for all the banking systems to melt down a few years later

Re:Seriously?

[Cro Magnon]

Been there! I remember one mass of code that I called "spaghetti code with meatballs". For years it was unchanged because nobody but the original guy wanted to work on it. When he left they asked me to rewrite the SOB from scratch. Naturally, there wasn't any documentation.

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?

[thomn8r]

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

This. Years ago I was a COBOL coder for a major financial company. The anachronistic culture - having to over-dress for office work, micro-managed email and personal phone call quotas - drove me out. Turned out to have been the best unintended career move ever.

Re: Seriously?

[datavirtue]

Just left fin tech. Boring, great place to start but get the fuck out. They are notoriously bad at implementing tech and typically undervalue it.

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.

Re:Seriously?

[sjames]

They may also need to let go of things like expecting people to tie onions to their belt and rags around their neck.

Re:Seriously?

[Pulzar]

What's that? You don't want to pay me a reasonable wage?

Considering many of these jobs are in places where programmers don't get paid much, or there's not much of a demand for them, it looks like Cobol programmers do get paid quite a bit more.

I did a quick search on Glassdoor, in some very non-tech places... Programmers in Jefferson City, MO make $45-65K.. Cobol programmers make $88K. That's probably very good for Jefferson City cost of living.

Re:Seriously?

[Ol Olsoc]

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.

Where do they say that they are attempting to underpay these folks?

I've been doing something similar recently, and the pay is tremendous.

Re:Seriously?

[Ol Olsoc]

No, they're not going to pay well. Why do think they're doing this (from TFS):

It is the teachers who are getting paid well. If you are ever lucky enough to have accumulated knowledge about something that the noobs aren't doing, there will come a time when you can cash in on it. I know I have. All it takes is knowledge of both old and new.

4. Profit!

Re: Seriously?

[datavirtue]

And it continues to hold back the technical progress of the banking and payments industry because people are too chicken shit or incapable of moving away from it. I just spent five years dealing with one fiasco and limitation after another brought on by fucking COBOL and mainframe applications. They completely suck and totally mismatch with the way computer systems have been designed and built since it went out of style. It fell out of favor for a reason, don't glorify it. It hangs around frankly because government regulation is used to stifle innovation in the space where it dominates.

Re: Seriously?

[cshark]

Yeah, but every sufficiently large organization, corporation, and government has things about it that are untenable. For example, I'm working on a scala microservices stack right now, and it's relatively new. But the developers that deployed the original iteration didn't really know the language or the platforms they're working on, so the project six months in is as bad or worse than the worst vb and java apps I've ever seen.

Fucking verbose case classes EVERYWHERE, and entire sections of architecture that simply don't need to exist. And yet, pretty much everybody's okay with it. It works, right? At least against the mocks?

I guess my point is that there's no avoiding it. There's no such thing as quality in code in a production environment, and as a professional developer, you just get used to that unfortunate reality.

Granted, some environments are better than others, and I'm sure that's true about the banking sector as well.

Re:Seriously?

[dwywit]

I'm curious about COBOL. I was an RPGII/III/400 programmer on AS400s, and IBM was pretty responsive about modernising RPG over that period in the 80s and 90s (and since).

What's been done to modernise COBOL ?

Re:Seriously?

[Darinbob]

COBOL programmers are paid a very good wage. Much of that is due to the demand for the skills and the rarity of those with the skills.

Re:Seriously?

[Darinbob]

You're demanding that salary only 15 years out of college? Wow, just... wow. That's well above the norm even in Silicon Valley.

Re:Seriously?

[Darinbob]

Quite a lot like that, except that people who understand it are rarer than those who understand modern Rube Goldberg systems.

Re:Seriously?

[Wycliffe]

You're demanding that salary only 15 years out of college? Wow, just... wow. That's well above the norm even in Silicon Valley.

That's his point. If you want someone to learn a language that is old-fashion, tedious, has limited growth potential, and is full of bureaucracy then you need to pay above market rates. At most programming jobs you are paid marketing rates and continue to stay up to date with technology and therefore can get a new job when your current job ends. Many programmers are even willing to take below market rate jobs if the work is interesting and has learning potential. Taking a job as a COBOL programmer, you lose all the niceties of modern languages and you also put your career on hold for the duration of the job. They could improve their recruiting a little if they paid people while they learned COBOL but companies don't want to invest in people like that anymore. To improve their odds even more they could pay people while they learned AND give out five year contracts AND find people who only have 5 years till retirement so that people are willing send their careers down a black hole.

The other option might be to do something similar to what many open source projects do and let people spend 50% of their time pursuing personal projects. This still requires them to basically pay double what the market rate is (as they are only getting 50% of the work) but is probably the most workable solution.

Re:Seriously?

[Darinbob]

Is it a career dead end if you can spend 20 years doing that work? Ie, I'm doing C right now, it's in high demand, and very interesting, and yet a lot of younger people avoid it for being out of fashion. And yet nearly half the world runs on C and most of the other half runs on COBOL, with a sliver of leftover stuff for everything else.

In the past, people didn't choose careers for what was interesting and exciting. Sometimes stability and benefits come first. If people only did interesting stuff, we'd never have any accountants who knew how to keep double books for those who do interesting things.

Re:Seriously?

[angel'o'sphere]

aking a job as a COBOL programmer, you lose all the niceties of modern languages and you also put your career on hold for the duration of the job.
In america perhaps! There are plenty of other places where an odd language on your resume gives you huge bonus points!
Why the funk I would I not hire someone who did the previous 5 years an interesting COBOL project?

Re:Seriously?

[angel'o'sphere]

I'm doing C right now, it's in high demand, and very interesting, and yet a lot of younger people avoid it for being out of fashion.
That is double nonsense.
First it is not in high demand and secondly people don't "avoid it". It is simply not taught in universities and it is a cumbersome language, that is all.

Re: Seriously?

[Anonymous Coward]

One mans Spaghetti code is another mans accumulation of mandatory business requirement edge cases fixed under time constraints. Elegant code is for school.

Re:Seriously?

[DCFusor]

The weirder and rarer it is, the better the pay, especially if legacy code is spaghetti. Perl for me, for $. Plenty of people wrote too clever for anyone's good in that one, it makes it easy to show off. Job security for them, and for me. When I write it for myself, you'd not recognize it as perl, it looks sane - freedom can be used either way.

Re: Seriously?

[CaptainDork]

Like buzzwords are for boors.

Re:Seriously?

[Wycliffe]

aking a job as a COBOL programmer, you lose all the niceties of modern languages and you also put your career on hold for the duration of the job.
In america perhaps! There are plenty of other places where an odd language on your resume gives you huge bonus points!
Why the funk I would I not hire someone who did the previous 5 years an interesting COBOL project?

On odd language gives you huge bonus points if you also know the language of the job you are applying for. Same goes for an interesting COBOL project (likely not interesting though but rather just maintaining dying code). They problem is that you are now either 5 years behind in the other stacks or you have been doing double time during your off time to maintain your more relevant skills. Either case should command a premium.

Re: Seriously?

[astrofurter]

"Can't wait for all the banking systems to melt down a few years later"

That actually sounds like a pretty cool side effect!

Re: Seriously?

[astrofurter]

Ever wonder how many back doors were buried down in the spaghetti?

Re:Seriously?

[aviators99]

Pretty much every credit card transaction in the world uses COBOL.

When I do expert witness work dealing with COBOL I am paid very well.

Old joke from the '80s: "Have you heard of the new 'object oriented COBOL'? It's called 'Add 1 to COBOL'"

Re:Seriously?

[angel'o'sphere]

They problem is that you are now either 5 years behind in the other stacks
And who cares about that?

to maintain your more relevant skills.
There is nothing to maintain. Skills don't just rot away.

I mostly do Java related stuff ... most companies are using Java 7, some Java 6, some 8 ... never met one that is actually using the most recent version, or the second recent version.

There never will be a job interview where the most recent Java or C++ version is of any relevance. Actually most of the time, the programming language is not of any relevance anyway.

Re:Seriously?

[houghi]

Friend of mine studied IT and had COBOL because of the Y2K 'issue' so that getting a job would be almost guearanteed.
The minor issue was that he would have finished mid 2001, so the world would have been burnt by then.

He dropped out and did (what was then possible) the job search without a degree. Just saying "I know Internet" was enough in that time to get a job. Many people where "promoted" to IT manager after they put up their hand when people asked in a random meeting"Who owns a computer?".
Their first meeting in the new function with the CEO was: "We heard a lot about this Intertube thing and you must do this fore us. You have no budget and 3 weeks." Ah, the good old times when knowing 'telnet' and 'ping' was enough to be called a guru.

Re: Seriously?

[CaptainDork]

When I worked COBOL there was no Internet.

Re:Seriously?

[AmiMoJo]

It is that hard, at least for many modern programmers. COBOL 2002 made it a bit easier, but a lot of existing code goes way back before then and upgrading it is a major task in itself.

I dare say most people could be taught to do COBOL, but companies prefer to let someone else do the investment and then just tempt those staff away with a slightly better offer.

Re: Seriously?

[Type44Q]

"Most of the other half" does *not* run on COBOL or this debate simply wouldn't be taking place.

Re:Seriously?

[Wycliffe]

There is nothing to maintain. Skills don't just rot away.

Yes they do. Ask any foreign language speaker. They have to constantly maintain their language or they start to forget it. I used to be an excellent at C++. I haven't used it in 10 years and my skills are definitely a lot more rusty. I've forgotten many of the shortcuts for debugging, etc... I've also forgotten most of the calculus and physics I've learned in college as well as no longer have the periodical table memorized. I once read that you need to read X (don't remember the number) books per year just to not go backwards. This is the reason that most professional certifications require continuous education in order to maintain your certificate and license.

Re:Seriously?

[DarthVain]

Having taken a COBOL in university (years ago), I'd go farther to say not only is COBOL not hard, it is probably easier that most. It is a very literal language if you can call it that.

The only thing that makes it "hard", is that outside of perhaps some specialized uses (i.e. banking for example), it isn't used anywhere. So aside from learning the basics in university, there isn't a lot of places to really cut your teeth on it, thus likely most COBOL coders are of the graybeard variety. Additionally the only other thing being that almost all of the code associated with it will be Legacy (with a fscking capitol "L"), meaning that much of it will be an incomprehensible undocumented and uncommented mess to be untangled. Which isn't to say that is unique to COBOL, only that much of it would fall into that category unlike some of the more modern languages and maybe more importantly more modern techniques used to write them (i.e. proper documentation). Maybe... :) I work with a lot of legacy systems, none of which are COBOL, but all of them probably have similar if not as extensive issues.

Re: Seriously?

[LordWabbit2]

because people are too chicken shit or incapable of moving away from it

Wrong! COBOL is still around because there are millions of lines of it running, to rewrite that into xyz language would take YEARS and cost BILLIONS. I don't think you realize exactly how much code is running the worlds financial institutions, and how thoroughly it gets tested before going live. Don't even get me started on the cost of replacing a mainframe with a server room full of servers, but then modern mainframes can actually run Linux VM's, so technically they could still carry on using their mainframes. One other reason it's still so much in use is that an IBM mainframe is fucking stable, you don't need to reboot for AGES,. What bank in their right mind would fork up money (and a LOT of it) to replace something that works 100% and is rock solid stable for something that keeps falling over and needs a restart?

It fell out of favor for a reason, don't glorify it.

It fell out of favor because it's boring fucking work, I started out in COBOL after 4 years I was bored out of my mind and moved to front end development.

It hangs around frankly because government regulation is used to stifle innovation in the space where it dominates.

I don't know where you live, but my government is not mandating that ANY financial institution HAS to use COBOL, yes there are regulations etc. but that is more to do with how you store sensitive data, how long you have to store it etc. etc.

One thing I miss about COBOL was how it handles splitting up strings. Works like a charm, and was probably your biggest problem when trying to communicate with a COBOL program on a mainframe. It's literally built into the language, to split up a string all you have to do is define it segments in your working storage, drop the string into the 01 level and it automagically slices and dices the string into it's component parts and will even cast the string into the relevant data format (numbers etc.) No other code is required, and yes, one of the front end programs I worked on had to talk to a COBOL program (several actually) on a mainframe.

Re:Seriously?

[DarthVain]

Regardless of language, ANY legacy system that is decades old, that likely has little or no documentation, which has had development upon development piled upon in by a variety of developers, some good, some not so much makes it "difficult" no mater what language you are working in. It just happens that with COBOL, being so old, is what you mostly find. The language itself is pretty literal.

I've worked with legacy systems for years. I've found some pretty "interesting" things in my time (in most cases a OMFG why the heck did they do it this way), which upon deep inspection usually end up being what was thought at the time as an expedient or elegant hack to solve some unique problem of the day. I am literally trying to reverse engineer a DB data model which are just full or what I perceive as development shortcuts which were done primarily because it was just easier to do at the time rather than them making any sort of comprehensive sense. The person that did them is 20 years gone, so you can only guess as to the motivation in many cases. Though often time when you look hard enough you can see the business rule that changed, and the kludge was done to address it. Some are even a bit inspired, however it takes a lot of sorting out before you get it.

Re:Seriously?

[LordWabbit2]

Erm, yeah are SO wrong there it's not funny. Just because you worked for a bank on their software systems that didn't interface directly with COBOL does not mean it does not exist, it just means you probably worked on a lot of their web pages. I would also bet money on the fact that somewhere in that suite of libraries you had to call to get data etc. there is a call to a COBOL mainframe, it was just wrapped up in a class you were handed to do the communication for you. Just because you didn't have to work with it directly does not mean it no longer exists, or is not still in use.

I've worked for (or with) 4 of our major banks and the settlement and clearing house in our country, they ALL use COBOL in the backend. Nice GUI front end (or web) but in the back doing the heavy lifting - is COBOL.

Re: Seriously?

[Darinbob]

Well, "half the world" doesn't say in what units or the like. But in terms of number of computers running COBOL it is very small. In terms of the number of transactions processed by COBOL it's massive. It keeps the world spinning. If Google searched vanished tomorrow the world would go on, but if all the COBOL systems vanished then it's likely we'd have a massive economic depression and multiple industries would collapse. This is foundational stuff that so much of modern life is built on top of.

Re: Seriously?

[HornWumpus]

Cobol is more or less married to CICS. DB2 would be great, but no, your going to be using a database engine/middleware server from 1968.

Re:Seriously?

[HornWumpus]

May a Fortran program with calculated goto* land in your support bucket.

That's Goto intvar, where intvar contains a line number.

Re:Seriously?

[HornWumpus]

That's just self modifying code.

If you've never written self modifying code, turn in your nerd card.

Re: Seriously?

[zwarte piet]

If it worked then, it works now! Now Get of my Lawn!

Re:Seriously?

[angel'o'sphere]

Your programming skills don't rot away.
It has nothing to do with doing calculus or physics anymore since graduation.

It is just a language. Half an hour working with it bring you right back to where you dropped it 10 years ago.

This is the reason that most professional certifications require continuous education in order to maintain your certificate and license.
Because they usually require physical skills and a "protocol". As in surgery or piloting.

well as no longer have the periodical table memorized.
And for what, except passing a stupid constructed test, would you need to memorize that?
The basics you can reconstruct from your mind, and if an obscure element like Tellurium or Circonium is in that column or the other one hardly matters for the jobs or hobbies you are working in.

Re:Seriously?

[SCVonSteroids]

It is just a language. Half an hour working with it bring you right back to where you dropped it 10 years ago.

HTML doesn't count.

Re:Seriously?

[Tablizer]

The last paragraph appears to contradict itself. It seems you only loved your go-to's, not others'.

I skipped COBOL class deliberately

[presidenteloco]

So as to never be roped into a job like that.

In my defense, back then, COBOL did not even have an ELSE statement.

It was just pretty dumb.
And all the stuff written in it was stultifyingly boring.

That was the best 1% mark I ever sacrificed.

Re:I skipped COBOL class deliberately

[Archtech]

It was just pretty dumb.
And all the stuff written in it was stultifyingly boring.

Yes, all about money and stuff like that. Paralyzingly boring. Who cares about lousy old money?

Re:I skipped COBOL class deliberately

[jedidiah]

> Yeah, who wants steady employment anyway! Stick with Obj-C and Rust and Lisp and the flavor of the month instead...

Never had a problem really.

As an added bonus of sound planning and not being located in Silicon Valley, I can work as much or as little as I like. I can take early retirement any time I want.

Re: I skipped COBOL class deliberately

[datavirtue]

How about C#, Java, and Python instead. COBOL is a world of suck. It is like assembly language for batch jobs.

Re:I skipped COBOL class deliberately

[Greyfox]

I was forced to take THREE in college, for some reason, and have never it since then. When Y2K reared its ugly head, I set my asking price for COBOL programming to $300 an hour. Never had any takers. Nowadays I reckon I'd be pretty rusty at it but if someone wants to pay me $3000 a day plus expenses, I suppose I could dust off an old textbook.

Re: I skipped COBOL class deliberately

[angel'o'sphere]

Uhhhh ... the batch jobs you write in JCL ...

Re:I skipped COBOL class deliberately

[Ol Olsoc]

It was just pretty dumb. And all the stuff written in it was stultifyingly boring.

Yes, all about money and stuff like that. Paralyzingly boring. Who cares about lousy old money?

Quiet! all these young guys need to think that there's no money in supporting legacy systems.

Stay away! You'll be paid less than minimum wage! COBOL is dead anyhow - this is just fake News!

Repost

[Anonymous Coward]

This same thing has been said every five years since the 90s. You think they would have done something by now after they realized what a mess things were prior to Y2K.

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:Repost

[alvinrod]

I wouldn't be surprised if about 8,000 years from now, there's a massive Y10K crisis because some ancient Cobol programmers only used 4 digits for their date fields.

Re:Repost

[Darinbob]

Short term thinking is part of it, as in the bottom line for the next 4 quarters is of vital importance to keeping your stock price inflated. The other big snag is that there's a much bigger tendency in modern time for huge projects to have exorbitant cost overruns.

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.

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

[Ichijo]

Excellent! More bugs to fix, bugs created by programmers who didn't know what they were doing and were never expected to maintain the codebase in the future and so they made a big unreadable mess that just barely works, usually.

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

[oh-dark-thirty]

I'm around 10 years from retiirement and would happily ride that wave into the sunset. My very first real job was coding COBOL on a Wang VS80 (later we upgraded to the VS100, woo), I'm sure it would all come back to me.

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

[oh-dark-thirty]

It's not impossible to make spaghetti with the language, but it's also not that hard to read and follow the logic to make block diagrams, flowcharts, etc from old code.. This is just a guess but I'd bet there are tools out there to do just that.

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

[PPH]

'In the U.S.'

So what are other countries using? Because a few more years of 'do what we say or else' and banking, being the reserve currency and the seat of the world's energy markets will just go overseas. Find out what they use and learn that.

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

[vtcodger]

Some COBOL work will surely be offshored, but for bank systems -- unlike web crap and similar stuff -- the software deals directly with money. Erroneous outputs are perhaps likely to be more easily seen than in other fields. I'm not sure that some COBOL programming won't hang around in the US to take advantage of easier communications and less management aggravation. OTOH, programming for banks may not be a terribly high paying job. Banks are somewhat notorious for giving the low level staff the mushroom treatment.

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

[angel'o'sphere]

In Europe the banks are actually the highest payers, and insurances.

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

[byteherder]

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.

You will have a job for a few years and then they will outsource your position. A few years later you can come back as a consultant to fix the spaghetti code that the overseas 'coders' ran through a blender.

I see it happen all the time.

You can learn Cobol well enough to get a job

[rsilvergun]

in about 90 days. Buddy of mine did it back in the day. But without a college degree you won't make it through modern HR filters. Why hire a high school grad for $80k + 40/hr/week when you can import a dev for $60k + 72/hr/week?

Most prevalent? No.

[Anonymous Coward]

"Cobol is still the most prevalent programming language in the financial-services industry world-wide". Not a chance. Don't pretend every bank has decades old mainframes and that there's no way or incentive to replace the hardware or software.

It's one of these stupid anecdotes that was true back in the 90's.

Re:Most prevalent? No.

[Archtech]

Don't pretend every bank has decades old mainframes.

No - just the ones whose systems work reliably and consistently, and don't have regular catastrophic "IT outages".

Ever heard the definition of a "legacy system"? One that works.

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:Most prevalent? No.

[bws111]

Where does this STUPID idea that mainframes are 'decades old' come from? Of course these companies replace hardware. They spend MILLIONS of dollars doing it, and they do it every few years. And what do they replace it with? NEW mainframes, because they are best suited for the job. The latest IBM Z mainframe was released 4 whole months ago.

Re:Most prevalent? No.

[Penguinisto]

Don't pretend every bank has decades old mainframes...

You're right - many of them have fairly new mainframes. Running the same software.

(hint: guess what most web banking firms have to keep writing connectors for, even today?)

Re:Most prevalent? No.

[shadowknot]

Mainframe (z/OS or zTPF) centric applications like CICS and WAS have native SOAP/REST interfaces now, so while it may be true that interfaces are being written because they need to understand how to actually address the data that is stored in these systems, developers are able to do so with modern APIs for the most part. Now as for the backends themselves, i.e. the programs that facilitate the business logic, that's what the COBOL and in some cases Assembler programmers are needed for!

Re:Most prevalent? No.

[tazan]

I don't know about the best suited reason. When I worked in a mainframe shop they bought new ones because they were locked in because of their 4 decades of software. They actually wanted out pretty bad.

Re: Most prevalent? No.

[datavirtue]

They are locked in for various reasons. They want out but getting out sets off the risk meter and they just bow thier head and buy another. Don't act like these people are jazzed about maintaining this expensive, inflexible shit.

Re:Most prevalent? No.

[Darinbob]

Not just banks though. It's common in payroll processing and stuff like that as well.

Re:Most prevalent? No.

[LordWabbit2]

Insurance companies too, I know of at least of logistics system running a large retailers order and payment system that is written in COBOL - I know this because my sister works there (yes she is a COBOL programmer). They have just finished a big update to the system so that it handles the automatic loading of trucks as well. Each distribution center has it's own mainframe, and when they open up more, they buy a mainframe for it. So COBOL is definitely not dead, neither are mainframes, it's just a LOT quieter than other IT industries, probably because of the stigma attached to the language, they don't want to admit working with it around non COBOL developers.

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.

Re:It's the context of the job that matters

[Tablizer]

Could I stomach being employed in the banking industry and facilitating the awful [bleep] they pull?

I've worked at/for a lot co's, and jerkativity is NOT limited to just banking.

Re:It's the context of the job that matters

[bobbied]

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.

I'm curious.. What stuff do they pull that you don't like?

Re:It's the context of the job that matters

[westlake]

Simply knowing COBOL isn't the deciding factor. Could I stomach being employed in the banking industry and facilitating the awful shit they pull?

Now you know why out-sourcing to countries with workers more interested in gainful employment than nursing old grievances makes good sense.

Re:It's the context of the job that matters

[bobbied]

If you are actually seeking knowledge and not just trolling to start a confrontation from the expected answer, I am not the person to educate you about the banking industry. That history is well documented. Go read, since you've managed to grow to adulthood without paying attention.

Actually, instead of assuming something, I was asking to be sure what issues where being alluded to. I may not interpret history the same way as you, so it was an effort to stay focused and relevant in the discussion.

My perspective on the banking industry is similar to my perspective on oil refineries. They have their bad points and can be messy, but we'd be in bad shape as a society without them.

However, reading between the lines of your two posts, I'm guessing you are just wanting to bash the banking system, and not really discuss the specifics of why you want to do that. I further figure you really don't have any specifics about your issues, at least ones you can defend. So I'll leave you to bash that which you don't understand in peace.

Re:It's the context of the job that matters

[macraig]

Now you know why out-sourcing to countries with workers so desperate to merely survive that they'll tolerate any degree of disadvantagement makes good sense.

FTFY.

Outsourcing bites those greedy employers in the ass soon enough: when the local standard of living rises just enough that thriving and not surviving is now the focus, those disadvantaged people will begin to rebel and demand fair treatment. Then the greedy employers pull up the anchor and sail for the next region full of desperate people... until there are none left. First it was Mexico, then India, then Moldova. It won't go on forever. That's even assuming that awareness of global ethics doesn't put a stop to such abuse entirely.

Re:It's the context of the job that matters

[djinn6]

Do you honestly think anyone smart enough to learn to code wouldn't also be smart enough to see it's a language with no future? Indian or not, they'll be gone as soon as they find something better.

Re:It's the context of the job that matters

[LordWabbit2]

I could stomach a boring job in finance for the right price.

Perhaps, but when you slit your wrists at the thought of going to work on a Monday morning, the right price will mean little.

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

[bob4u2c]

do you know cobol? IF so, there MIGHT be a job for you.

Yeah, sure let me get right on that. If, might; why not waste my time on vague promises?

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?

[cyber-vandal]

Don't worry. India will do the needful.

Re: Would you even be looking for a job?

[OrangeTide]

Indian jobs are getting outsourced to Poland, Romania, Brazil, China, Philippines, and Michigan.

Re:Would you even be looking for a job?

[deKernel]

And how much would you like to bet on that 5 year prediction? Before you decide, let me give you a little history lesson. I have been in the financial sector since the very early 90's, and every 5 years or so, all of the really smart people claim just what you are claiming, and guess what happens.....

Re:Would you even be looking for a job?

[OrangeTide]

One of these 5 year periods I'll get it right.

But more seriously if you look at the ages, say some was 20 when they started programming COBOL in 1978. They'd be 60 now. In 5 years They'd be 65. Maybe they'd retire and spend time with your grandkids, maybe you'd work until they're 70 or even 75. What I don't find reasonable is the sustainability of an industry based on a population of 80 year old programmers.

Now here's where my argument falls apart. It assumes people aren't learning COBOL. If you look at data from university computer science programs, you'd believe that not enough college graduates are bothering to learn it to sustain the industry. What is harder to factor in is that a lot of the old timers were self-taught computer operators and techs that transitioned to programming. There may be some significant number of people outside of the computer science industry. I don't have that data, but I would not estimate it to be a huge number.

Re:Would you even be looking for a job?

[OrangeTide]

Maybe they'd retire and spend time with your grandkids

oops, that turned unexpectedly creepy. substitute the appropriate pronounce.

Re:Would you even be looking for a job?

[jythie]

but.. I thought blockchain was going to replace it all? Can you implement blockchain in COBOL?

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?

Re:Would you even be looking for a job?

[PolygamousRanchKid]

Can you implement blockchain in COBOL?

Here's where you can ask: https://www.ibm.com/it-infrast...

Go ahead and ask . . . and then tell us how it went . . .

Re:Would you even be looking for a job?

[deKernel]

I'm not just how familiar you are with the core banking packages that banks use, but they are quite complex and consists of my components. The only parts that are typically still in COBOL is the part that holds balances and transactions on the accounts which typically require very little maintenance...if any at all. It is because of this stability plus the fact that IBM does do a good job of maintaining compatibility that COBOL code like this will continue to be in production systems at banks for long after people like you and me are retired.

Re:Would you even be looking for a job?

[OrangeTide]

Yup. relying on the continued support from a single vendor is always a good plan.

Re: Would you even be looking for a job?

[datavirtue]

Rolling on the floor kicking and crying with laughter...holy shit

Re: Would you even be looking for a job?

[datavirtue]

It doesn't exist but they will hurry up and promise it to you for a fee.

Re:Would you even be looking for a job?

[dwywit]

How many vendors of Z-series or compatible mainframes are there? How many have been and gone? Who's still around, charging up the wazoo for maintenance and strangely enough, providing that support?

If it was easier and cheaper to move to a bunker of intel servers, don't you think they'd have done it by now?

Re:Would you even be looking for a job?

[OrangeTide]

Agreed. IBM will be around forever. There never has been a highly profitable business that failed due to mismanagement.

Re: Would you even be looking for a job?

[cyber-vandal]

European devs can do way better than a job trying to decipher a 40 year old mess of COBOL. There's a big shortage of 21st century skills too.

Re:Would you even be looking for a job?

[dwywit]

Yes, they're very slow to respond to changing business and economic circumstances, leading to questionable business decisions such as licencing instead of buying DOS from Bill Gates.

What they do really well is: R&D, and build reliable minicomputers and mainframes. They've also relatively recently started responding better to the real world, e.g. adopting, promoting, and supporting Linux as a platform. I'd like to see the POWER9 systems placed on an economically competitive scale with Intel servers, but that's not their thing.

My point stands - there are no other vendors to choose from.

Re:Would you even be looking for a job?

[OrangeTide]

I believe strongly that a company is only as good as its executive management. Once positions have been swapped out a few times, a company's culture and business strategy changes pretty dramatically. Tying your business's fate to another when you have no crystal ball is a real gamble in my opinion. It's fine to use a vendor like IBM, they provide an excellent product in this case (I'm slightly familiar with z/System, z/OS and z/Linux). But a backup plan so that one failed company doesn't take several others with it seems prudent to me.

My point stands - there are no other vendors to choose from.

In house development exists, but it's terribly inefficient. I worked at a few that do that. And even dabbled a bit with some third party compilers on z. Maybe it won't matter, and IBM will last another 100 years. I really don't have any way of knowing.

Re: Would you even be looking for a job?

[Joey Vegetables]

Not all of Michigan can fairly be described as third-world. Parts of Detroit, Flint, etc. are much worse. :)

Stupid question

[Nidi62]

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.

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:Stupid question

[bluefoxlucid]

Better question: why aren't they rewriting this stuff?

This is technical debt, a particular type of risk that piles up over time unless mitigated by taking other risks. Technical debt occurs when you solve a problem with a less-than-optimal solution to avoid a cost--whether that be time, money, or risk. Time isn't a factor here; rather, it's expense (small) and risk (large).

Banks pay quite a lot for maintenance of these systems, and can afford redevelopment. It's not that they're loaded with money, but rather that redevelopment isn't much more expensive (and is possibly short-term cheaper) than maintenance. Because time isn't a factor, a slow approach expending little cost per time--stretch the schedule to accommodate the available budget per quarter--would allow for redevelopment at about any cost constraint; and an agile delivery method integrating the old system onto a new baseline and delivering new components over time would allow better testing, earlier (partial) deployment, and risk mitigation.

Instead, they add new components, adapt to new regulatory needs, and write bits in Java and C and whatever. They cobble components together, integrate with other systems, and somehow get their complex and expensive code base to talk to another system written in Python to provide online banking. They keep dragging the whole thing on while adding more glue code and more core functions.

Somebody says it's not broken; everybody sort of shuffles around and tries not to mention that it might break if you sneeze too hard, and that it might not be easy to put it back together. If it's expensive to maintain and carrying the risk of minimal professional knowledge available in the field, it's broken: it's a huge risk waiting to bring immense monetary, regulatory, and reputational damage to your organization, and you're paying excessively to keep it around instead of trying to replace it.

Re:Stupid question

[jythie]

Part of the problem is, it wasn't really an suboptimal solution. It has worked really well, with the problem being that the industry has moved on and does not produce new programmers with the same 'hit the ground running' skills. But the technical solution has uptime that modern frameworks can only dream of.

Re:Stupid question

[hey!]

Because employment is a short term thing these days.

Getting a job used to be like getting married. It wasn't unusual to get a job at a place (the mill, Big Blue, the bank) in your 20s, and retire from that place forty years later. People changed employers maybe three times in their career. The average today according to BLS is twelve, with the average duration 4.2 years, and the trend is toward even shorter term employment.

If someone is going to work for you for ten or more years, you might well invest in them because you'll reap the benefits later. Companies have more of a "just in time" mentality too. IF they need specialized skills they'd rather hire them, then let them go. So even if you are technically an employee, you've got to think more like a contractor.

Re:Stupid question

[bluefoxlucid]

Oh, you can architect software that way; it just takes one hell of a lot of investment. It's not so much expensive as it is time-intensive and procedural. This is where you use project management to the fullest, you have a real QA team, you have disaster recovery and hot sites, and all that. Those things are all products of risk decisions, and the requirements here dictate a large investment in risk mitigation.

This is the kind of system for which you produce architectural documents first; you build test suites; and you ensure your organizational history is archived, indexed, and maintained by a dedicated department. It's not just about writing good code; it's about not flying by the seat of your pants on a system nobody understands with a bunch of very smart people who can tinker with it until it works and hope it doesn't break again.

Re:Stupid question

[Comrade Ogilvy]

Better question: why aren't they rewriting this stuff?

Because the actual requirements are pretty complex and easily underestimated. If you underestimate the complexity of a core system, the replacement project will be very expensive and could easily fail regardless of how much you pay. What makes it worse is these services shops like Accenture love big messy projects with vague requirements because they can make bank on the endless late game change requests that are necessary for the system to be usable.

It is not actually rare for big companies like banks and insurance companies to blow $50-100 million on replacement projects that fail. Literally. But the cost are rolled into some generic multiyear infrastructure improvement project and the CIT is forced out. Bummer.

Re: Stupid question

[datavirtue]

Absolute bullshit. Some processors like TSYS have rewritten this shit several times and use Java. Mastercard has had outages of their COBOL mainframe stack several times in the last few years.

Re:Stupid question

[bluefoxlucid]

Absolutely true. You implement systems like this in an incremental manner, with parallel deployment so you can thoroughly test. Basically, you form the foundations first, then begin building components, and create adapters to connect your existing system to these new components where they replace parts of the old one; and you run this stuff side by side, duplicating all actions so you can compare results from both systems. Each time you've sufficiently demonstrated a subset of components, you replace production with the new stack.

It's not cheap, and it's not easy; it's something you do when the risk of maintaining legacy is getting too big.

Programs are connected sets of operations and projects to fulfill a common business need; each project is a finite, well-defined, planned, and temporary endeavor. No project should vary its scope unless some risk event makes the prior scope unusable; changes within scope are common and natural, and your project needs a change control board to determine if and how to make those changes.

Unscrupulous project management shops with little technical expertise will suck your business dry by proclaiming that "the customer is always right!" and doing whatever you ask. As a project manager, it is your job to discover what your client wants--not what they're asking for, but what they expect to achieve. If they want you to build something and it won't achieve their purposes, you push back. They can cut the contract or force things through their executive suites if they want, and it's your job to drive them that far if they're trying to make unnecessary and damaging scope changes that will harm their business and ultimately cause the project to fail by delivering something not appropriate or functional.

They call that "Agile"; that's not agile. Iterative and incremental delivery is agile: show each workable unit so the customer can test, analyze, and give feedback before you go basing the next piece on that. This increases customer interaction frequency and reduces risk by continuously validating that the project is developing as expected and actually fits the needs of the business and the product. Running around with no plan and no governance isn't agile; it's bullshit.

Of course I like to get shit done; a lot of people seem to just like money.

Re:Stupid question

[Comrade Ogilvy]

Unscrupulous project management shops with little technical expertise will suck your business dry by proclaiming that "the customer is always right!" and doing whatever you ask. As a project manager, it is your job to discover what your client wants--not what they're asking for, but what they expect to achieve. If they want you to build something and it won't achieve their purposes, you push back. They can cut the contract or force things through their executive suites if they want, and it's your job to drive them that far if they're trying to make unnecessary and damaging scope changes that will harm their business and ultimately cause the project to fail by delivering something not appropriate or functional.

They call that "Agile"; that's not agile. Iterative and incremental delivery is agile: show each workable unit so the customer can test, analyze, and give feedback before you go basing the next piece on that. This increases customer interaction frequency and reduces risk by continuously validating that the project is developing as expected and actually fits the needs of the business and the product. Running around with no plan and no governance isn't agile; it's bullshit.

Of course I like to get shit done; a lot of people seem to just like money.

In a nutshell, it sounds like you know your stuff. But project managers with your perspective and sufficient subject area expertise (or team with experts who can assist) are not easy to find, apparently.

I would emphasize your point that "the customer is always right" can be a CYA gambit for bad behavior. I would also say that services shops that brag about CMM5 are often playing a variant of the same game. After all, it is really not that difficult to find contractors who can document their work precisely if given extremely explicit and detailed instructions; what is genuinely valuable are those who can achieve good results for the customer in the face of ambiguity.

Re:Stupid question

[Comrade Ogilvy]

Another factor: relevant in house expertise.

I would further add that core system replacement project management is effectively a rare skillset. There are reasons that these big giant companies avoid replacing these systems for 25+ years. Of course the time comes that it needs to be done. Then what? Well, nobody who who did the deed 25 years ago works here anymore.

If I need to buy a new car, that is a significant cost to me, but I can easily find lots of excellent advice from people who have experience on the topic. If I need to buy a house, that is a huge event in my life that does not happen often, but, again, I can easily find lots of excellent advice.

If I am Citibank and I want to replace a core system there may only be a few hundred people on the planet with truly relevant experience of working in such a complex crufty system and keeping the plane flying while replacing the wings. And, of course, for Citibank, there are all kinds of reasons, good and bad, that so-and-so's experience in that bank over there might be argued to not apply to a big important company like Citibank. Do you dare go outside and hire on a team of people for resumes that sort of apply? Do you dare stick with the people inside the company that you at least you know but lack certain key experience? Tough call.

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:not again! they don't want COBOL they want CICS

[Archtech]

there is a huge glut of out of work CICS experts to pick from.

Hmmm. Let's think about that for about seven seconds. "A huge glut", you say. That implies that many of the CICS experts who used to be needed have become redundant. (Even though many will have died or retired, considerabl;y diminishing the size of the pool).

How can that be unless many or most of the existing CICS systems have been retired? And, you know, they haven't - because no one has the time and money to recreate them.

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

[pgmrdlm]

Damn, even where I work which has it's claims system written in Cobol. I haven't heard CICS, VSAM(Remember ISAM). Lol, I also worked with IMS. That made all other database structures easy to understand. What do you mean a relational database is hard. shittttttttttttttttttttt, nada but a thang.

Re:First?

[Mikkeles]

You're using COBOL, right?

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!

There isn't enough money in the world

[IWantMoreSpamPlease]

To make me go back to programming COBOL on mainframes.
I did it for 3 years. I still have the 9mm scars as a consequence. /h (maybe)

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

[Waffle Iron]

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

But then again, so could almost any other decent general-purpose computer language.

(But without all that boilerplate and flowery prose syntax.)

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

[sycodon]

Not the same way.

Read up on the Redefines features.

Slice and dice before the code so your code isn't cluttered with Mid, Left, Right, Strip, etc.

Re:COBOL Has Advantages

[Anonymous Coward]

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

Uh, no you don't, because everyone knows in the 21st Century the answer for this is blockchain. Doesn't matter if all you're building is a fucking toilet that needs to be able to flush reliably and repeatedly, it better be blockchain-enabled.

Blockchain! It's what's for dinner. It's what Nike now uses to Just Do It. It's what Donald Trump snorts every day before tweeting. It's what makes Charlie Sheen a Winner. It's what makes Soylent Green!

Blockchain!

Re:COBOL Has Advantages

[Waffle Iron]

That's great if all of your strings are of fixed length, like in some kind of 1960s punched card stack.

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

[Waffle Iron]

COBOL's greatest advantage over C and its decedents is no IEEE 754, floating point arithmetic "issues." Granted the precision may be viewed as "negligible," but not for penny pinchers. Now, the problem with the precision is taxed on the programmer to do their math/algorithm correctly.

That's only seen as an advantage because accountants are such decimal chauvinists.

It there were 64 cents in a dollar, they'd have no problem with IEEE 754 math, since any errors introduced by the algorithm would be the exact same errors they would get by doing the problem with paper and pencil. (They want to see familiar errors, not unfamiliar ones. The familiar errors are defined by accountants to be "correct".).

Re:COBOL Has Advantages

[PPH]

You do the serious work that involves billions of dollars of transactions.

Meh. A slow day on Wall Street. What do the big exchanges use? Learn that. Probably not a batch oriented language and underlying system. Something that can support event-driven high frequency trading.

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: COBOL Has Advantages

[datavirtue]

Not flexible. That's why it is still around.

Re:COBOL Has Advantages

[Darinbob]

Well, the mainframes that do this work do not act like PCs. They are optimized for fast I/O rather than fast processing. Part of writing good mainframe code is in knowing how to optimally use the machine, and much of that isn't even in COBOL it's in all the stuff that goes around it (JCL, etc).

Re:COBOL Has Advantages

[dwywit]

All of that. And RPG stands for Report Program Generator. It's a language originally written to process in batch-mode. It's even got a built-in cycle, you don't have to tell it to READ a file, that's what it'll do when you give it a file name. Of course there are specific read functions (and derivatives), but it gives you an idea of its design. It's damn fast, too.

Now, getting it to process things interactively, like a terminal screen, that's a bit clumsy, and another language would be preferable.

Re:COBOL Has Advantages

[Krishnoid]

So based on that focus, it's a very practical extraction and reporting language?

Re:COBOL Has Advantages

[slack_justyb]

It's even got a built-in cycle, you don't have to tell it to READ a file, that's what it'll do when you give it a file name

Indeed the cycle is still there for OPM, but if you want ILE you have to ditch the cycle. OPM biggest use is exactly what you said, if you want to batch process a massive load of records. Where I'm at there's still some programs that use cycle because we load up data sent in from all the branches, doesn't matter if the file is 1,000 records or 100,000,000 records the batch for each branch is so quick the timing is considered to trivial.

Now, getting it to process things interactively, like a terminal screen

That gets more into where you'd used ILE to break things up into pieces. Granted, there hasn't been any motion to move away from DDS for TN5250, but with PCML and node.js now integrated into the stack, you can code a service program to build JSON and then send that to the IFS and have the UI done up by node.js programmers. Or if JS isn't your thing, there's Zend server that can speak to COBOL or RPG ILE via PCML, again though, you really want to be outside the cycle for any of that to be less than nightmarish.

But biggest thing is that you have a choice in which mode you want to run in, cycle is still king for a ton of ETL. But ILE makes more sense for larger, more complex projects. But it's still good that we have a choice.

Re:COBOL Has Advantages

[djinn6]

Seriously? Millions of records overnight is 230 records per second. I think even JS running on a cell phone could handle that.

Any implementation in a respectable programming language would be bounded by IO, not CPU or lack of programmers.

Re:COBOL Has Advantages

[jythie]

This is true, and there is always room for taking a close look at those tightly wound paths that need to execute over and over. But more often than not, the savings there tend to come from how the path is structured as opposed to which language it was written in.

Re:COBOL Has Advantages

[jythie]

Heh. I spent a great deal of my career working on problems that came down to 'shaving off 2ms means this works or does not' or 'you have a hard memory limit of X before trashing will render the application unusable', so I do indeed put in the elbow grease to verify if something really does behave well enough or not. What I have generally found is that the language and library writers tend to be pretty good. Python has a pretty large scientific computing community where time is money and if you use the number crunching libraries correctly they can actually be surprisingly efficient even when compared to custom rolled solutions in C or FORTRAN. When you have something specialized that REALLY needs to be tiny and fast it can still be best to switch to other languages, but even then it can be difficult to match the work of the library authors without putting in similar amounts of time and effort.

Re:What about PDP-8 assembly

[ArchieBunker]

Know any PDP/11? https://www.theregister.co.uk/...

easy..

[SuperDre]

If you already really know how to code it shouldn't be a problem to learn cobol in a short time. We had in our IT classes, and I thought it to be a breeze..

Learning COBOL is easy

[Toshito]

Anyone with some coding experience can learn it in a couple of weeks.

What's more difficult is that every single company has it's own editing/compiling tools, source management, home made subroutines, programming standards, etc...

Coding for batch processing is a lot different than for a web pages or user applications.

And forget about the documentation, it has probably been lost in all the movings and restructurations. Some systems are more than 30 years old.

It's a fadso!

[Impy the Impiuos Imp]

These firms are on the hook for correct transactions, screwups of which can cost millions.

So if it ain't broke, don't fix it. Go away, refactoring busywork generator portion of latest software engineering strategy fad.

Not just COBOL

[TomGreenhaw]

Learning COBOL is not really a big deal. What you need to be successful in that environment is experience with a whole raft of older IBM technologies like MVS, ISAM, SPUFI, MQ, etc. etc., etc... Layer that on top of modern "Get off the mainframe" stuff that emulates these things in a *NIX environment and you begin to realize you need to be Dr. Frankenstein from the past, not a good developer who can pick up yet another language.

Use marketing BS

[Tablizer]

I've been hearing about COBOL being the new hot job ticket for 20+ years. I haven't seen anyone offer a training, boot camp or workshop in COBOL

Banks don't want to pay for training, they want plug-and-play staff, and a pony.

Perhaps they should rename it to sound hip and cool. Stupider things have caught on*. Call it Cloudbol++ or node.bol or Bolockchain.

* Or applied to the wrong things or places

Re:Use marketing BS

[dwywit]

Bolock

Now you're talking.

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

[Tablizer]

Trump would love COBOL; it's usually in all capitals and makes small things sound important, as if you are God commanding an army of millions who don't question orders.

Where Do They Get Their Hardware?

[organgtool]

Banks and other companies have come to the uncomfortable realization that ripping out old mainframes is pricey and complicated

But where do they get replacement hardware for mainframes and how secure are those supply channels? If it's going to take years to create a newer system, are the channels that provide replacement hardware guaranteed to be in place for the entire duration from the time a replacement project starts (let alone the time management continues to procrastinate in approving a replacement system)? Of course, that's not too likely to happen on the current executive's watch, so it's really a problem for their successors (or at least that's the way they see it).

Re:Where Do They Get Their Hardware?

[bws111]

The truth is, nobody is really running on old mainframes. They are running on brand new mainframes, most likely ones that have been released in the last five years. The latest mainframe was released just 4 months ago. Mainframes are still in active development, with new models coming out every 1.5-2 years.

Re:Where Do They Get Their Hardware?

[Eravnrekaree]

They get their new mainframes from IBM of course, which also provides repair parts. Many of them use IBM mainframes for which there is an upgrade path to newer mainframe models built on todays technology. This is the case with the z/OS stuff which originated as System 360. IBM prides itself in full backwards compatability, mostly the case that an app written in 1965 for System 360 should still run on a 2018 IBM mainframe. Upgrading to a new mainframe is a fine solution. mainframes are designed to provide high uptime and are price competitive with commodity hardware

Re:What about PDP-8 assembly

[bobbied]

DEC went belly up a couple of decades ago... PDP-8 went out of favor for the PDP-11, then the VAX-11 did that in with the thumb switches on the thing.

I'm with you though, I wonder if my DEC VAX Administrator training certificates are worth anything more than for starting a bonfire, or my demonstrated ability to adjust the boot loader for the Harris H100 to use the correct CDC 300 Megabyte 8 platter Drive to boot Vulcan is a marketable skill. Somehow, I'm guessing not.

Staying power

[Tablizer]

why aren't they rewriting this stuff?

Into what? COBOL has lasted 50+ years. How do you know Java or C# or Python will last that long (in viable numbers)? COBOL is kind of like Latin: it's stable because it's a dead language. Scientific taxonomies use Latin because it won't change on them.

COBOL also has a lot of built-in idioms for business data processing. Java etc. would have to use libraries to get similar, and those libraries may fall out of maintenance even if Java itself lasts.

Re:Staying power

[bluefoxlucid]

COBOL hasn't lasted 50 years; it's an old legacy language that's running because people are still using it and paying huge money for it. MS-DOS still runs some POS systems.

You make a disjoint argument, as well: if something is so popular and powerful that it lasts 50 years, why would something else critically-important to large, super-rich clients simply fall out of maintenance?

Finally, C# is current, it's well-known, it's easily-maintained, it has modern OOP which allows extensibility and flexibility in your architecture to reduce long-term risks. In the future, C# will probably not be a language--or maybe it will. We then cycle this around again when it becomes clear we may end up stuck with an event nobody can resolve, with the global banking system in tatters, with nobody able to spend money, and our best countermeasure is trying to get people invested in a dead-end career doing nothing exciting.

Re:Staying power

[Tablizer]

COBOL hasn't lasted 50 years; it's an old legacy language that's running because people are still using it and paying huge money for it.

But that's largely because it does relatively well in its domain.

why would something else critically-important to large, super-rich clients simply fall out of maintenance?

Even if something doesn't fall out of maintenance, it still may be difficult to find people versed in it. Like I said, a more general-purpose language would probably need lots of libraries to be competitive with COBOL, and those need learning and maintaining also. Learning COBOL is also learning the built-in keywords and idioms for handling its domain. With C# that would be a separate extra step.

In the Year 2000......

[commodore64_love]

Cobol programmers will be in high demand, in order to stop the Millenium Y2K bug

In the year 2018... the problem is still not fixed.

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.

I have to laugh..

[bduncan]

In the early nineties I was contracting for a large financial institution that were re-training COBOL programmers to be C programmers. I was called in to fix the most awful C code that I've ever seen, before or since. e.g. Functions that would span for 25 pages and blow up compilers.. Later of course, they needed all those COBOL programmers back for Y2K. Now they need 'em back for the boomers retiring. Such foresight.

Here's a thought.. What about building a modern language preprocesser that spit out COBOL? Something like RATFOR did for Fortran?

Re:I have to laugh..

[LordWabbit2]

It's called XGEN - ok, tried to find a link to it and came up with lots of other crap. It WAS called XGEN, and when I first started working as a programmer, we used that. It was a 4GL language that would generate COBOL code. I liked it, and was sad when they retired it and we ended up with all this generated COBOL code to maintain. Flags fucken everywhere, it was a mess for humans to maintain. So they tried to clean it up and replace it with more human readable / maintainable code, and that was better, but still a mess. So it was decided to rewrite the whole thing in non generated COBOL - written by programmers. So they hired a plane load of Indians and got them a long term place to stay, the project was supposed to last 2 years, by the first year they were six months behind. Politics had changed, the cost had just gone way up and the project was cancelled. So we still had to maintain the generated (and slightly cleaned) code base. We eventually just start rewriting sections to make it more readable, logged it to "Code Maintenance".

The only issue I had with XGEN was sometimes you would miss a delimiter for an if or whatever, and it would give you a thousand COBOL errors when it tried to compile the XGEN to COBOL, trying to fucking find that missing delimiter was a pain in the ass.

Re:I have to laugh..

[LordWabbit2]

Oh yeah, and the way it looped backwards was interesting to see in the COBOL generated, definitely not efficient, you used it with caution. But at the time to do it in COBOL would have been almost as bad, it was not designed for that (at the time). I think sometimes it's like looking at the queries the Entity Framework for MS creates when generating SQL queries, sometimes I just lean back and think "WTF is that?"

Fixed Point Math

[KalvinB]

Besides the hundreds of billions of lines of code that would need to be translated, COBOL does fixed point math exceptionally well which is why banks used it in the first place.

If developers are serious about replacing COBOL, they need to focus on fixed point math and then figure out how to make a compelling financial case for using it. Change for the sake of change is not a reason to spend the money to change a language.

https://medium.com/@bellmar/is...

Re:Fixed Point Math

[Todd Knarr]

Part of why COBOL's so efficient at fixed-point math is that the hardware it runs on has fixed-point math instructions and the compiler uses them directly. The x86 instruction set doesn't include those (it has support for BCD math but the instructions are relegated to the "rarely used, don't bother optimizing" category and you have to keep track of the decimal point separately) and the available compilers don't generate code to use them so the math routines aren't very efficient. Frankly though I'd love to see fixed-point types as a compiler- and instruction-set-supported data type, I've written way too much code that had to deal with money that could've made use of them.

The world makes money go around

[presidenteloco]

not the other way round. Never forget that.

But "seriously", if you can code up a new altcoin in COBOL, I will be seriously impressed and not bored, admiring the sheer surrealist abstract impressionist audacity of it.

Re:What about PDP-8 assembly

[sjames]

Yet the PDP-11 lives on. In the '90's and early 2000s in the form of the Osprey, a PDP-11 on a PCI card. Now, software emulators are fast enough.

My first prof programmer job offer was for COBOL

[hAckz0r]

I tuned it down without any hesitation.

I had been working at a company whos draconian monolith called Data Processing Department had no clue how to run a manufacturing plant. We had asked for 6 years to have a report for a fully expanded bill of materials (supposedly an impossible task) for our products so we could get a jump on the purchasing and inventory analysis of long lead items, and yet we were stuck with the hand entry on paper, whch was hand typed twice by data processing operators, which generated reams of paper,. That initial process fed the next level of hand entry on paper for all the subassemblies, which gave the next level of product, and at the end, we humans got out a calculator to total up what was needed to actually build something. To make matters worse, each run of that program was overnight and filled reams of paper we had to sift through, just to get a clue what we needed to complete the orders.

One day I stayed late to play with my dual-floppy IBM 8088 PC 4.77 mhz with an interface board that let it act as a terminal to the mainframe. I had just bought a Pascal compiler and reprogrammed that interface board so to teach it how to pull up the interactive programs that displayed our parts catalogs, read the virtual screen data, and then to switched to the non-interactive mainframe partition where the same "report" jobs could be submitted through a virtual card deck, and then receive those paper reports as text data from those same programs". I now had access to all the information we needed to do our own fully nested bill of materials. The next day I sat down at lunch and threw together a recursive routine to do exactly that, and it submitted those batch jobs during the day and compiled the results from each job submission. This program cut an entire week from the time to deliver, and it took me half an afternoon to write. A week later I had that same program checking inventory and produced a consolidated list of what needed to be purchased.

When my boss saw the output I created he grabbed my report and ran down to data processing to ask, no tell, them once again to write this 'impossible' report he now had in his hand. The data processing department took 6 man months to write that exact same report, and they had direct access to the database, and didn't have to reprogram any hardware, or write libraries, or to make the tail wag the dog. They just wrote straight COBOL

In summary
Pascal: 6 hours (once the libraries were written)
COBOL: 6 man-months with no special development required
You get to decide

Re: India will do it

[presidenteloco]

Nice try but China is developing AI that translates COBOL to rust, while stealing one US penny per transaction and locking the penny away on a blockchain implemented on a distributed network of Huawei smartphones. Don't cha know.

Really makes me wonder

[cshark]

We live in an age where programmers are pretty used to transpiling. We have entire languages like Elixir and Scala that transpile to Erlang and Java respectively, and dozens of others. This has been going on for 20 years. We do it all the time. React, Typescript, and Angular couldn't exist without it.

The way I see it, transpiling is the answer here. Doesn't even matter which way you do it.

Say for example, you wanted to hire young cheap programmers to write code against legacy systems. Just come up with a transpiler that converts whatever it is they're working in into COBOL/DB2 that'll compile against those ancient IBM steel giants. It'll take work to get there, but you're writing non trivial in house code with it's own frameworks and coding standards anyway. If you're still using COBOL, complex projects are pretty commonplace.

Or, if you're feeling enterprising, you could write something that will work against the existing code in your environment, and transpile yourself out of cobol completely, and into something a little more modern like Java, Go, or C. They've had the time, they certainly have the resources to do something like this. And if they did, they would be able to cut costs in the longer term, be more platform flexible than they are, and deliver a higher quality of product to their internal stakeholders, other employees, and customers.

If they really cared about solving this problem, they would just do it. It wouldn't even be a conversation. It would happen, it would be done. No, this isn't really about COBOL or a shortage of old programmers who know COBOL. This is a pretense to bring in exploited offshore labor from the third world, in order to drive down rates in the labor market when the cost of living is at an all time high. "There's no solution, so we have no choice but to train offshore resources and bring them stateside to do it" is pure fucking transparent bullshit. And we should know better than to fall for it.

Obligatory Old, Bad COBOL Joke

[14erCleaner]

Did you hear there's now an object-oriented version of COBOL? It's called "ADD ONE TO COBOL GIVING COBOL".

COBOL is The Future

[hcs_$reboot]

COBOL is the future, of 1954.

Re:Gee...

[angel'o'sphere]

I haven't seen anyone offer a training, boot camp or workshop in COBOL.
Because you did not look for it.

Google: cobol workshop

About 832,000 results (0.35 seconds)

AWK versus OS2200

[emil]

I must confess that many of my coworkers love the original UNIVAC operating system, OS2200, known in a previous life as EXEC 8.

UNIVAC seemed to have gotten the ASCII message earlier than IBM, so EBCDIC isn't a problem.

What is a problem is socket programming in COBOL - we had people who knew how to do it in EXEC 8, but they are gone.

I have done obscene things with stunnel defending this beast. I'm actually an Oracle junkie in real life, but I am thankful for the COBOL cards that I wrote in high school and rubber-banded every class for understanding what the hell that machine is doing, and I don't understand 1% of it.

But the best of these COBOL guys love the flexibility and expressiveness of AWK, and their descent into the C languages begins at this guidepost.

Who says that you can't teach an old dog new tricks?

No...

[tigersha]

But i know about toilet cleaning. Does this mean there is a job for me too? I would probably prefer it to COBOL

Don't learn Cobol, let it die

[Nocturrne]

It's time to force them to update those crappy old systems.

Re:Don't learn Cobol, let it die

[hcs_$reboot]

Hardware update is easy, and they do that. But they don't want to rewrite those millions of source code lines, as long as they run ; "we don't need an upgrade"

Working for a company that uses COBOL

[Tony Isaac]

I wrote COBOL back in the day, moved to C++ ASAP. But it's not the language. A company that is still using COBOL also has entrenched, archaic ways of doing EVERYTHING. Sorry, not interested in the least!

Re:Working for a company that uses COBOL

[hcs_$reboot]

A company that is still using COBOL also has entrenched, archaic ways of doing EVERYTHING

They're called "banks".

Specialisation has leverage.

[Qbertino]

If you're able to find the right customer/client. Specialisation is the reason I'm torn hither and fro on wether I should ditch PHP or dive deeper. There are setups out there that are not trivial and need someone who's way beyond regular web stuff.
Same goes for Cobol. Anything running in Cobol today is bound to be seriously mission critical and thus non-trivial to maintain. Which means if you are able to handle such a set-up you're in a position to ask big bucks.

There are quite a few jobs not doing the latest fad in technology and instead dealing with some obscure ERP system and its internal PL or something similar. Those systems aren't going away and are good places to find positions that are basically unfireable.

Yep. But would I do it for a living?

[Pezbian]

No. IDGAF what you're paying.

Wow, slashdot poster too k3wl

[whitroth]

Oh, yeah, all the k3wl tools in the latest language...

Right. Perhaps most of you missed "it works just fine, and does the right thing" in the story. Explain why it should all be tossed, preferably without running in parallel for a year or so, and replaced with RubyOnRails, er, I mean, whatever Goggle's latest language is, or M$'s.... most of which will be forgotten in 10 years.

Got a standards committee for your favorite language? (I've got one, but my fav's C).

Oh, and about mainframes... how many VM's can you run on your system? Back around 2000, some nuts at IBM, using IBM's VM (which dates back to the seventies) maxed out a then-current mainframe... with 48,000 VMs running Linux, and the mainframe ran comfortably with 32k VMs.

Would I go back to writing COBOL, Hell, no. because I like pointers, and more control structures. All the rest is excess... and before you try to argue that, why, wasn't that story on slashdot the other day, that the new versions of apps for the latest i-droid phones running *slower*, becuase what they're pushing out the door is crap alpha software?

Let's see *your* software running 15 years from now. And do you *really* think financial services should be constantly rewriting software into new languages, becuase. they're new? So they can charge you more, because they're constantly hiring new develpers, rather than paying you more, or letting you learn a new language?

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

[LordWabbit2]

makes small things sound important,

If you think the daily calculation of interest for your savings account or home loan is "little" then you have no real understanding of the complexities involved.
When I was still working for a bank one of my work colleagues was tasked with finding a 0.5 discrepancy in general ledger program. He eventually printed it out, it took a ream of paper, and he printed double sided and with as small a font as he could use and still read it. Granted, it was one of the larger programs in use, but still. You print out 99% of programs today (without supporting libraries) and it won't use up a ream of paper. That was his only work task for over a year, find the discrepancy and fix it. He printed it out so he could staple a dog's leash on it and drag it around behind him when he went for coffee. Eventually he hung a porcelain pig with feathers from the air vent in his office and stuck a half cent in it's mouth (not sure where he got the half cent - it's been out of circulation for ages) and told anyone who asked WTF that when pigs fly he will find the half cent. He broke over 3 keyboards by pounding the shit out of them, it was probably more, we stopped counting, but there were always little keyboard keys scattered around his office. Eventually he resigned and his manager / team lead took over the bug hunt, keep in mind that he wasn't the first person to attempt to find the bug. AFAIK they never found it, and each month they have to do a manual transaction to get the general ledger to balance. I worked there for almost 10 years, luckily by that time I had moved to front end, so the bug wasn't dropped on my desk.

A few thoughts on COBOL...

[erp_consultant]

1) Programming in COBOL is not difficult. It is a very procedural language. It also takes a LOT of lines of code to actually do anything.
2) COBOL is alive and well. In fact, on the ERP system that I work on there are many COBOL programs still around and they are crucial for Payroll processing. Nobody, and I mean nobody, wants to mess with these programs.
3) COBOL, despite the fact that is is very old, is extremely good at moving around huge volumes of data. It is also very stable.
4) If you are going to even attempt to modify a COBOL program you had better have a firm understanding of Copybooks and JCL, as the code is likely used in a lot of other programs.
5) It's not going anywhere. The banks have no incentive to rewrite the code into a modern language. For one thing, it's incredibly complex to try and unravel. Secondly, you are not likely to get any discernible processing improvements. Thirdly, it would cost a fortune.
6) Programming in COBOL is really boring. It is almost entirely back end processing. What doesn't kill you makes you stronger :-)
7) As time goes on, skills in COBOL will command a very high hourly rate. Think government and banks. If you can stand all the politics and overhead you will be able to make a good living at it.

Re:My first prof programmer job offer was for COBO

[LordWabbit2]

I would say your data processing department didn't consider your report a high priority and it got shifted down the list of other shit they had to work on. It probably only took a couple hours to write in COBOL, same as in Pascal, but they only GOT to it 6 months later.

Change control can also be a pain in the ass (if they actually had any) where my wife works a small change means 3 weeks of waiting for change control approval.

Their release schedule might be 6 months as well, where my sister works they only release twice a year, unless it's an emergency bug fix.

Either that or they are a useless bunch of twats, the time taken has fuckall to do with the language it was written in.

Re:My first prof programmer job offer was for COBO

[hAckz0r]

I would say your data processing department didn't consider your report a high priority

That is an understatement if there ever was one. Somehow the production schedule, which is the only way you stay in business, should have been a higher priority than anything else, other than the sales reports. During my time of 6.5 years, there were six large layoffs. The company was bleeding money badly because of the inefficiencies of the corporate structure, and bitter fighting between departments grappling for power, and data processing was no different. The only group of people that were actually treated well all the time was the Sales team. The salespeople were the elite, and they could do no wrong.

Change control can also be a pain in the ass (if they actually had any)

Their change control was a COBOL comment block. They had so much dead code it's a wonder anything worked at all.

Either that or they are a useless bunch of twats, the time taken has fuckall to do with the language it was written in.

This. Exactly. Nobody knew how their system worked (or didn't), and to do the same report they needed to clean up the database of parts lists. There were recursively nested parts lists as well as broken/missing references, misspellings, all of which I had logic to detect and did workarounds. I had a couple of years experience working around those problems on paper, so I at least I understood how it needed to be coded logically.

When I said 6 man-months I meant exactly that. That is the time that was actually charged to get it all done. They finally could not ignore all the problems they created for themselves, and they were thus forced to understand their own spaghetti code. As for the language itself, COBOL, in general, is extremely verbose. I could do in one line of Pascal what it took them more than a full page of their COBOL to do. Modularity was a completely an alien concept to them as well. I've read the code, been there, done that, because that is the only way to get them to fix the business and job tracking logic, and I would have gone insane if I had to deal with all that stupidity on a daily basis.