Slashdot Mirror
Cobol Job Market Heating Up
snydeq writes "Developers seeking job security in the years ahead could find an unlikely edge in Cobol. According to an InfoWorld report, demand for Cobol skills is surging, with salaries on the rise. More importantly, the short supply of offshore Cobol programmers and the fact that mainframes aren't going away anytime soon are spurring longevity for big-iron skills, with many companies looking to hire in-house Cobol pros to bridge mainframe Cobol apps to the rest of the enterprise. The report provides further evidence that Cobol may indeed be primed for a comeback, with new kinds of Cobol integration jobs emerging to prove old-guard skills are critical to some of the hottest areas of software development today."
Kill me.
You'll have that sometimes...
I usually turn to O'Reilly for getting started with a new language, but oddly they don't have a guide to COBOL (similar situation with LISP, which I'd love to master). How do people learn COBOL? I notice there's a COBOL for Dummies , but I honestly doubt it's a rigorous intro.
Or as I refer to it "COBOL of the 90s"
Why is Cobol still alive and in demand? What's so good about it? Why can't we just port everything over to a newer language and be done with it?
Doesn't it cost more to keep paying these rare programmers than to just update/convert/replace the systems?
I'd disagree with that. Schools in India are still providing lots of people with mainframe skills. The whole shebang, like InfoMan, CICS, etc. Not just Cobol. At least that's my impression. I see a lot of people from Tata, InfoSys and IBM Global Services doing mainframe-centric maintenance and even new development at companies I have contact with these days.
Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo
Cue up the Theme from Shaft, I'm ready to walk that aisle. Twenty-eight years later, I am ready for my place in the sun. You bunch of Java-smoking hippies make a hole cause I'm coming through. I told you that personal microcomputers were a flash in the pan. Take your Winchester drives and Hercules graphics and shove em up your ass. Big Iron is here to stay.
Dammit, where are my car keys? Honey, where are the keys to the Citation?
If you aren't part of the solution, there is good money to be made prolonging the problem
In other news, Cthulu has risen and has started eating nuns.
SUBTRACT 1 FROM WS-OLD-KARMA GIVING WS-NEW-KARMA.
There, fixed that for you.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
All the big Hartford insurers have their own programs: The Hartford, Aetna, Travelers, United Health Care, and I can't remember the rest.
They're the big consumers of Mainframe Cobol.
By the way, the reason they are staying with Cobol isn't just because of their legacy code, it's also because mainframes are the only solution now that solves their business problems.
Don't get me started on "distributed systems" because I'll have to slap you silly. Mainframes solve problems that can't be solved by other solutions. That's why they still exist.
A couple of things people should realize when thinking about getting into mainframe/cobol:
1. COBOL programmers are 99.9% baby boomers. If you want to spend your next decade getting talked down to by a 50-something or 60-something who thinks they're a programming god because of their teaching degree and 30 years writing COBOL, then you're probably into leather and whips, and would be happier staying in your dungeon. That's just my opinion, I could be wrong.
2. COBOL is not challenging to learn (it's designed that way), and the programming tasks are largely mundane. You'll be working almost exclusively on data processing tasks, because that's what the mainframe does best: massive throughput of number crunching.
3. You shouldn't just learn COBOL, you should spend time with JCL and DB2's version of SQL, and some CICS concepts would serve you very well. But without JCL and DB2, you're practically useless anyway. But they're not hard to learn.
4. zOS also runs Java now, so if we just stay back and let it rot, eventually perhaps they'll just throw it all to Java.
5. It's hard to just "take a class" on COBOL, but forward-thinking companies are starting to train people like disaffected teachers, just like what was done in the 70's. So if you want to work with/clean up after that sort of developer....
If, after all this, you really want to know more, IBM has most of the useful documentation online.
http://www-01.ibm.com/software/awdtools/cobol/zos/library/
But the "dummies" book should serve you very well.
Oh, and once you start working with them, expect lots of, "Why does my PC do this", kind of questions, because most of the COBOL people I've met in shops aren't very technical. (IBM people are bright enough though)
Is it 9999 already???
And so is Brain Damage:
"The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence." (1968) - Dijkstra
and I HaVe A FIREPLACE! Lets BURN IT!
Many moons ago, I wrote a disassembler that emitted mock "c" syntax, which I could turn into real C with a few global substitutes.
You can do the same with normal assembler syntax and an ad-hoc parser, and therefor you can turn the "accountant's assembler" from add foo to bar giving zot to zot = foo + bar;
This is just a special case of the semantics-preserving transformation problem, which my old employer used to do on a daily basis (I worked in a porting shop).
And yes, I'll do this for money if asked (;-))
--dave
davecb@spamcop.net
Just think of COBOL as a scripting language for business applications. Yes, the syntax is wordy. But the big advantage of COBOL isn't in the procedural code. It's in the data declarations. COBOL has very clear ways to talk about external data structures, and good integration with external data in files and databases.
I used to joke about "Visual Cobol" being the next big thing in computer languages... that is, until I learned that it's a real product!
I still think this is a trick to get all those Chinese and Indian software engineers to train for a worthless language, so we can get our old jobs back...
I've abandoned my search for truth; now I'm just looking for some useful delusions.
I know COBOL, I do not program in it for a living. The simple fact is that it works and it works well. Don't compare JAVA, C++, or C#, to it. Sorry those languages are so damn cluttered and so easily made incomprehensible it really is silly. The one thing I notice as a difference from COBOL (or similar) programmers compared to those using newer languages, the COBOL folks will use proven routines over the latest gee-whiz attempt to do it another way. I can go look into the C++ CMS and find a dozen ways to do the same damn thing because of developer ego or just plain ignorance. I have seen five lines of C exploded to a dozen lines simply because one guy didn't want to learn it or care to use something he didn't fully understand and was too sensitive to ask for help on.
I do code on the iSeries. I do RPG/LE, C, C++, SQL, and CL (iseries version of JCL). I can combine modules from each easily meaning I can easily make use of some of the COBOL our mainframers bring over. One or two minor changes and I have all the integrity of their routine which has been running for years. That running for years provides a great level of comfort that the other languages MUST earn. Declare the language of the week to be superior for whatever reason you want, it cannot provide the comfort level from proven existence and stability.
Would I want to go back to COBOL, not really. I will do so in a heart beat if it keeps me employed. I will do JAVA if necessary to stay employed but for ease of programming some of the older languages are where it is at. Now these languages are extended to share with other languages and you can embed SQL into IBM versions of SQL so you can have very good data access. All our interfaces to the web rely on COBOL/RPG backbones. The PC people tell us what they want and we deliver it. We might have one meeting to hash it out but for the most part we have our side done in a third of the time if not less.
Yeah, mainframe/mini bigot ... but I do each platform.
Finally, there is no reason to replace working systems just because you can. Businesses don't stay in business if they just replace it simply because someone has a woody over a glossy ad.
* Winners compare their achievements to their goals, losers compare theirs to that of others.
Anything Cobol can do, any other language can do as well absolutely false, most languages are incapable of doing proper decimal arithmetic out of the box.
Many years ago, right before the dot-com boom, I was out of college and looking for any job. The economy was lousy in 1988, and I had a computer science degree, and a big firm offered me a killer job with an awesome salary. Sadly, the job was all about COBOL.
Happily I had another job lined up at a famous research center. But it was heavily government funded, and their funding disappeared. So I took the Cobol job, as it was a job, and it paid well.
Well, it was the most awesome job I had ever. I learned a lot. COBOL was the worst part about it, but there were plenty of other design challenges, and I worked with a bunch of smart people who were also saddled with COBOL. Of course, you can do just about anything with enough COBOL and enough creative thinking. And, of course, as a computer science guy, sometimes it is fun to exercise a mainframe even if you can only exercise it with an antiquated language.
The nice thing about COBOL, of course, is that its pretty hard to get yourself in trouble. The bad thing is that it can't easily do all the great things that a modern (post 1962) language can do. Or at least in can't do those things in an elegant way. Yes, even in COBOL-72 you can dynamically allocate memory for a complex data structure - if you're creative enough.
The other nice thing about living in a Cobol/Mainframe shop for a while is that you realize that everything in modern computing was delivered like 40 years ago by IBM. Sure, some things have changed, but just about all the big important things have been in that mainframe environment forever.
Of course, the web and dot-com boom started to emerge and I left the mainframe world after a couple years. A lot of my mainframe buddies did successfully make the transition, and the others mostly retired.
I still have fond memories of the people and systems. Yes, they are both all crusty and old, even back then, but all those things ain't as bad as people say.
Except for JCL. I always hated JCL. Now that was a total senseless hack.
Actually, I don't think you need a modern guide. COBOL hasn't changed much, older books may be ok.
MicroFocus is good. Another segment in that space with a lot of potential is in the Sun CICS emulators (http://tinyurl.com/6od7wr). These are large systems that can offer a way out of the IBM mainframe trap while still supporting legacy OLTP systems. I don't know that they've achieved huge commercial success, but the options are out there.
It's all in the dollars, I guess. For some firms -- say, with 20 or 30 million customers to keep track of, the cost of the computing equipment isn't all that significant compared to the value of the data assets, so they're less likely to want to move away from Big Blue for their big iron. But for those in the middle with a strong desire to move down the ladder a bit, there are still things you can do before you have to re-engineer the lot. Much of the logic in old COBOL has to do with business rules and database manipulation.
You could probably redefine most of it as simple database table IO (which you could knock together in Iron Speed in a very short time). The problem is in the custom rules that would need to be rewritten in something else, like SeeBeyond -- to get verification and test, you'd need to talk to the business people, and getting them to agree would open up a brand new can of vermiform invertibrates. It would be like re-convening the Continental Congress. So although there are strong technical cases for re-engineering, there are equally strong business/political reasons for a simple application port to a different underlying platform. For mostly political reasons, code is remarkably difficult stuff to change sometimes.
Do not mock my vision of impractical footwear
There are some key differences between the COBOL and Java job market:
(1) Interviewer: Do you know COBOL?
You: Yes
Interviewer: Ok, you're hired.
(2) Interviewer: Do you know Java 1.5, Spring 2.0 and iBATIS?
You: Well, I don't know iBATIS but I know Hibernate and SQL. And I know Spring 1.2.
Interviewer: Well, we're looking for someone well versed in Hiberate and Spring 2. You don't get quite have the skillset, you don't get the job, have a nice day.
Where I work, COBOL is written once and run for a long time. The Java environments are always changing, and code is often re-written is different frameworks every few years. HR staff are full of buzzwords. And in the COBOL environment, there's only a few buzzwords: DB2, COBOL, JCL, IMS DB/DC and they haven't changed in decades.