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.
What's next after that, Plain Ol' K&R C?
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
COBOL is, after all, an acronym.
I heard there were some editors on the payroll but I have yet to see evidence of this.
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
*Browses over to Amazon for a COBOL book and adds a meatgrinder to the shopping cart*
While I'm emulsifying my brain I may as well do the same to my manhood.
"Creationists make it sound as though a 'theory' is something you dreamt up after being drunk all night." -Asimov
Comment Of Bozo On Lithium.
Check out my sci-fi/humor trilogy at PatriotsBooks.
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."
Didn't I see this same headline 2 years ago? And 2 years before that? And another 2 years before that? And there was that big "post-y2k-bugs need cobol programmers even more!" 2 years before that ... and of course, the "Need for cobol programmers for pre-y2k" each of the 2 years before that ...
Seriously, we get it. Every even year, someone is required to post an article stating that the need for cobol programmers is increasing.
Can yah shut up about it now?
The need for C, C++, Java, *.NET, and other language programmers is also increasing, and it so far outstrips the need for cobol programmers that they're statistically insignificant, and that includes factoring in any salary differences.
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.
Apparently, he hasn't yet taken his lithium today.
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)
Somewhere I have a 1970's vintage Cobol text book. Any takers?
I'm intrigued about this so hoping there might be a COBOL programmer to answer. Have the applications been ported to newer hardware, or are some banks still running ancient machines based on transistors and 1st generation microchips?
I'm surprised there's still code to maintain on these old workhorses. Surely every bug must have been discovered by now, and every feature anyone could want added. Obviously not but what do COBOL programs need done to them?
Oh, and guys - you can type directly on one of these new fangled desktop computers. No need to use punch cards.
Did I just sleep for 6 months?
The cancel button is your friend. Do not hesitate to use it.
13 - All slain enemies will be cremated, or at least have several rounds of ammunition emptied into them, not left for dead at the bottom of the cliff. The announcement of their deaths, as well as any accompanying celebration, will be deferred until after the aforementioned disposal.
My first program:
Hell Segmentation fault
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
Yes, COBOL was an excellent skill, until it was posted here. Now every two-bit hacker is going to learn COBOL so they can apply everywhere.
Reminds me of turbolinux, or whatever the last big bubble IPO was. It was posted on linux, and I knew then and there that I was looking at a stock that would be skyrocketing. It ended up making some investors something like 1000% profit, and I'm positive the fact that it was posted here contributed.
It's been a long time.
I'D RATHER SHOOT MYSELF = YES
C/C++ developers are worth MUCH more than Java and .NET developers. The fact is, as programming languages get simpler to use, the amount of money you can make from coding in them goes down. Like Cobol, a LOT of critical C/C++ code has been written and deployed, and since most new programmers turn their noses up at these languages in favour of Visual Basic, Java and .NET, the market for these skills is much more profitable.
Cobol shmobol --> I can code COM objects in C++, you're gonna need me forever!!!!!
Seriously, at this stage no one wants a beginner COBOL programmer and by the time I learn COBOL (which will probably take forever since I have zero care about it) it's little surge will probably be long gone.
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.
Everyone who wonders why COBOL still exists should recall the oft repeated advice to use the language that is best suited to solving the problem. Then look up the meaning of the acronym. COBOL is the acronym for COmmon Business-Oriented Language. COBOL still exists because it was designed to implement business applications and most businesses, wonder of wonders, rely on business applications.
That and "if it works don't break it."
Here's the question I'm interested in. How many COBOL programmers telecommute?
Shai Schticks:"You don't make peace with friends, you make peace with enemies"
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.
The equivalent to Tim O'Reilly is Mike Murach at www.murach.com - his COBOL, DB2, CICS, VSAM, JCL, etc are the best books and great for self learning. I taught myself the mainframe using them.
...but try to avoid using COBOL." - Nicholas M. Moffitt
PHEM - party like it's 1997-2003!
What would be todays Mainframe language?
I read the specs of a current Sun Mainframe last week and it listed FORTRAN, COBOL, C++ and Java as the key PLs to develop apps in. FORTRAN! (No Joke!)
I found that rather hilarious. And while I'd have no problem learning COBOL, if the payment is right. After all I've developed in Lingo (as far as developing is actually possible in Lingo), Transscript and the one or other bizar language in the last 10 years. And people still use SQL, which I personally consider the most superflous, ancient and bizar PL in existance.
But still the question arises: Which would be todays programming language for mainframes. Perl? I heard there's a European Bank or two using Perl for their number-crunching (also no joke!) Would it be a hip interpreted language such as Python, Lua, Ruby or something? What kind of PL is COBOL anyway, an interpreted language or is it a compiled one?
Input please.
We suffer more in our imagination than in reality. - Seneca
I just want these guys to write Cobol viruses so the world can migrate away from these dinosaurs once and for all.
Anything Cobol can do, any other language can do as well. The difference is Cobol developers, being a rare and dying breed, cost a lot more than any modern developer.
Many people defend Cobol by virtue of its record definition capabilities, and while it was possibly the first language to implement such functionality natively, most other languages have copied the concept. We just call them structs and objects.
-Billco, Fnarg.com
If COBOL keeps alive for a couple of more years we will need a Ouija board to communicate with the developers.
Nobody wants to write in this stuff.
Just use a COBOL to Java converter and hire some Java monkeys
COBOL on the mainframe processes data like you would not believe.
if you have boatloads and boatloads of data and you need it massaged, there is no other tool that can outperform COBOL on big iron, unless it SYNCSORT on the mainframe.
besides, the side effect of needing to write JCL makes COBOL that much cooler.
It's called "ADD 1 TO COBOL GIVING OBJECT-COBOL".
According to the /. filter, which is probably not written in COBOL, I should not use so many caps, because it's like yelling.
Solution: automated language translation tools. I moved an app in Progress FGL to PHP. There was a lot of debugging as the original code had many different styles over the years, and I was aiming for automating only the easiest 99%, but I could have spent more time up front. One could write a COBOL interpreter, or even compiler for the JVM. It would require a compatibility environment, but from the comments here, COBOL doesn't seem to place too many demands on the OS.
If the problem is "nobody understands the original intent, only what it does now", admit you have no real control over the source and turn the whole thing over to a translator. You still won't have any control over the new source, but at least you can run it on Linux.
GUIs are doubtless easier to learn than text based entry but, if speed is a consideration, a text-based entry system is much faster.
I'll see your Constitution and raise you a Queen.
In High School(1986) we had a PDP 1134 running RSTS/E (if I am remember correctly) and they taught BASIC, ForTran77, Pascal, RPG & the dreaded CoBOL - 81 I believe.
I hated it - to wordy a language (pic (X) this honkiss) - plus I disliked the teacher!! Then came Y2k and CoBOL programmers were needed, now they are hot again? I thought the "new" Pascal language was going to be it, oh well.
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.
How about we agree to let India specialize in our COBOL jobs if they agree to leave the interesting languages to us.
Table-ized A.I.
Have you heard of the object oriented COBOL compiler? It's called "ADD 1 TO COBOL."
Do not mock my vision of impractical footwear
IMHO - About every three years, IBM pays a few shill reporters to write hack articles about how mainframes and COBOL are coming back. What a load of B*llsh!T...
Here's how I see the scam - IBM Mainframes and UNIX servers have the same CPU chips in them - the mainframes just run a different microcode and OS.
When you buy the chips as part of a UNIX system, they cost you 10 cents per MIP. In a mainframe system they cost about $500/MIP
Companies will pay the higher (extortion) price because of the well engineered FUD used to scare them against conversion off the mainframe. Y'know- UNIX isn't reliable, it isn't powerful enough.
The laughable thing is that Mainframe systems are only fair to midlin servers today - note that IBM won't publish competitive benchmarks.
But if all the COBOL programmers die/retire - companies will be forced to migrate, and will discover just how badly they have been gypped all this time.
So a few well-spread buckaroos in the trade rags create a periodic "buzz" that COBOL is coming back. Right about the same time as we all learn to speak esperanto...sheesh... just how gullible are people?
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
"the short supply of offshore Cobol programmers" ...
As long as M$ and $un keep the indians and chinese busy w/ .net and java, just maybe this might not have changed the moment it posted.
Anyone can sign up. The current contest iteration is running through the end of the year. There are some COBOL programming exercises. This contest is also a recruitment vehicle. You could end up with a full-time job if you do OK in the contest and want the job.
How do you find even find jobs in this area? How do you even get your foot in the door, its not like people are running mainframes in their garage? I've been searching, don't find much COBOL jobs, except for those with like 10 years experience. I'm in NY.
Maybe she'll get a COBOL job and leave..
I can hope...
deleting the extra space after periods so i can stay relevant, yeah.
The article (Yes, I did RTF) was trying to identify a trend, but had no numbers to speak of. There were no tables or graphs showing the advance of open COBOL reqs during the last year, this quarter over last quarter, or this month over one year ago. Nothing.
Go out to Monster, Dice, or the employment site of your choice. Type in COBOL, mainframe, VSAM, JCL, and DB2, or any combination of those words. Do the same thing next month and compare the results. There are some hot spots, with brief flurries of activity, but I don't see the "trend" they are talking about.
When I got my programming degree in 2003 COBOL was a required course and I was laughed at for having to take it, but I kicked ass at it and really enjoyed it, actually.
The wonderful thing about COBOL is that it lays out memory for data in one place, pretty much the way you declare it in Working-Storage. I used to be a great dump reader, and I was thrilled to be able to see the data. We also had dumps of the procedure code and could look at the generated assembly language in one of the compiler outputs. I was rather shocked when I tried the same sort of thing in PL/1, which put the data wherever it felt like. COBOL interfaced with any type of DBMS that existed at the time -- IMS, IDMS, DB2 come to mind. I'm sure IBM has it hooked up to whatever you like. The mainframe now has lovely debuggers, just like any other development environment. Even then, we had a debugger for CICS. I am happy being a DBA now, but I have no complaints about the good old days. We were productive and even imaginative in our use of this language. And our programs were structured.
I understand that they have object-oriented Cobol now. It's called COBOL-INCREMENTED-BY-ONE
There is virtually no alternative. I mean you cannot use floating point and need to guarantee a certain number of digits of precision. Other languages can only do this with lots of work. Besides COBOL probably doesn't do buffer overflows.
It's essentially the same question as why Fortran still is around. It simply is, to date, the best language for scientific processing. Unlike C it's easy to optimize by the compiler.
Too bad it's no longer compatible with the on-tape format you wrote it for!
Well Ada has representation clauses for that:
http://www.adaic.com/standards/05rm/html/RM-13-5-1.html#I4559
But then Ada programmers are even more difficult to come by :-( .
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.
If that's what you want, your only real option are college textbooks. Back in college, I used an older version of this book, by the Sterns.
Life is hard, and the world is cruel
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.
What's your problem? Do you think you're smart, or do you think everyone else is fucking stupid?
Read the post I was replying to. In a nutshell, the Bible-waving loon says cobol is still in use because of hardware reasons. As nothing is too obvious around here, you might like to know that the word "right" is often used in an ironic way.
Now look up, you might see it.
P.S. clueless_geek (947733) can fuck off too.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Of course I am aware of that. The POWER 5 CPU even got BCD floating point arithmetic on chip. And - hey - the 6502 (Apple II, Atari 800, C=64) had BCD arithmetic. They all have - because it is important!
And that is the whole point of my post. A compiler with build in BCD arithmetic - like Ada, Cobol and PL/1 can make use those instructions far better then a compiler which only has a BCD add on in form of a library. And the reason is that a library - once compiled - can not run true the optimiser any more. And it is not the fault of the compiler vendors it's a problem of the standardisation bodies which designed the language itself.
But note that GNU C is getting Decimal floating point as well - build in not as a library:
http://gcc.gnu.org/onlinedocs/gcc-4.2.4/gcc/Decimal-Float.html
Problem is: Financial institution prefer decimal fixed point.
Add it's an extension only available to GNU C.
Martin