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
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?
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???
I know I do a bit of a poo-poo job on mainframe development below, but I have to say: despite the terminal emulator, mainframe hardware is pretty godly.
5 nines uptime (99.999%)
Hot-swappable CPUs
Fail-predictive hardware throughout - an IBM tech will be at your door with replacement hardware before you even know it's going bad.
And the development environments aren't some freeware/just hacked together things. The tools have been developed by pros over the last 30 frickin' years. It's a very, very solid platform. And things like "dll hell" don't exist there. If you have decent admins (which is not uncommon), actually doing work in a mainframe environment can be pretty nice.
And so is Brain Damage:
"The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence." (1968) - Dijkstra
We havent heard from any Cobol programmers in years, they all went into suspended animation until the year 3000. They took their sharpened pencils and CODSYL approved 80 column forms with them!
Probibly the oldest code still running, is LEGACY COBOL code because its an older language than BASIC!
Every feature has not been added. Oh Hold your sickness bags. Are you Ready? Visual Cobol! Now you can safely co-develop c# applications side by side with your Cobol dinosaurs!
Shush about the punched cards. I still need them for christmas tree decorations!
Hot Swappable CPUs? Your so like 90s and stuff, these days, the zSeries mainframes have the CPUs already there, they can just turn them on and off like a light switch!
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.
You think that what businesses do and how they do them don't change over time?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
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.
Mod parent up...for those of who wonder why so much COBOL still runs today, this post explains it.
Momentarily, the need for the construction of new light will no longer exist.
...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
You think that what businesses do and how they do them don't change over time?
I think banks take peoples money, lend it to other people, and charge interest, possibly paying some of that interest to other the depositors. I also think they handle electronic transfers of funds. I think they've been doing this for a long time. Laws and regulations change, and tax systems get modified a lot, but I'm surprised the fundamentals of the businesses change enough that they can keep a significant number of COBOL programmers in work. It seems there are still a fair number of full time COBOL developers.
Obviously things do change enough but I'm surprised, and generally curious as to how they've changed.
If COBOL keeps alive for a couple of more years we will need a Ouija board to communicate with the developers.
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.
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.
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 people defend Cobol by virtue of its record definition capabilities, We just call them structs and objects
nope, only seeing half the issue. the actual *layout in memory* of the record can be defined in COBOL. Tell me about
struct recordlayout
{
int c;
float d;
double e;
char *f;
unsigned int;
};
now tell me how that looks in memory, on a 32 bit Sparc chip, an 80486, an opteron, a Vax.
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.
And this is usefull how? Other than when writing device drivers.
It's up to the customer. That's why they love it. You can take your accounting system written in COBOL on the 360 in the 1960s, and run it in 31 bit System/360 compatibility mode on your brand new System z z10 EC machine with 64 quad-core POWER-derived processors at a speed akin to 1,500 modern x86 machines.
And if you decided to store your business information in IBM IMS in 1968, you can migrate to the new IMS version 11 on your z10 and expand your library with up to 40 TB of data.
(Opinions mine, not IBM's, and I don't work in the mainframe division.)
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
We just call them structs and objects.
In C at least, if you don't add some sort of compiler specific decoration to the struct declaration, said compiler will "helpfully" re-arrange and pad it for you to get 'better' alignment. Too bad it's no longer compatible with the on-tape format you wrote it for!
Even the size of storage allocated for some types is apt to change based on the target platform (or not, at the whim of the platform).
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
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
Well, take mortgages.
You'd think amortization of a mortgage would be consistent.
Now, throw in new twists like interest-only loans.
-Did the programs assume you might want to pay nothing against principle, or would that throw an error?
-Is there a point where the loan converts to something that pays against the principle after N years? (often yes)
What about reverse mortgages? That's a loan you don't make payments on....think that might cause some errors in a standard mortgage module?
Take credit cards.
Add reward features - that's new (compared to cards themselves). So you have to build interfaces to companies that manage reward points for you, to airlines, etc.
Suppose your bank issues a card for some other, smaller bank or credit union. You have to build that product into your system.
New regulations come along, like SOX. And Visa/Mastercard change their compliance standards twice a year - you have to keep up.
The one constant in business is change.
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.
Maybe she'll get a COBOL job and leave..
I can hope...
deleting the extra space after periods so i can stay relevant, yeah.
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.
think about writing a DBMS, you can't take say Oracle data files and index files from one architecture to another, have to do full database export (platform neutral format, very texty) and re-import on another platform because of endian issues and data alignment issues. But you could write a DBMS in COBOL that had totally platform independent data files and indexes. (just as aside, COBOL also lets one use native types if one really wants to). Same issue can arise in any app with data files where the programmer uses representation-unaware defaults. Yes, there is a pile of libraries and techniques for C for dealing with such things, but complexity can and has led to bugs.
COBOL not suitable for writing OS, but you can nevertheless see the types of issues just looking at the pain operating system writers have going from various endian (high, low, mixed) platforms and from 32 to 64 bit. Those kind of things must be dealt with at low level like OS or device driver, but at higher level for business apps there are languages that eliminate troubles.
For a more modern alternative, at least in something like the JVM, everything is VERY well defined and predictable. Not that I'm a big fan of Java as it's still mostly warmed over c++ concepts, but it's going in the right direction for powerful structures.
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.
Anything Cobol can do, any other language can do as well.
BCD arithmetic? Build in! Not by a library. Mainframes usually have BCD arithmetic on CPU Level and with a library you loose opportunity for optimisation.
Apart from COBOL I only know of PL/1 and Ada which have BCD arithmetic build in. Ahh, and the IBM mainframe C compiler - which is a rather special kind of beast.
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 :-( .
Communication between various system.
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.
Then there's the whole selling over the internet kind of thing. And changes in tax rates (yeah, only an idiot would hardcode those). And new countries that you didn't do business in before. And new countries that didn't even exist before (or did, a long time ago, then stopped for a while).
Where to stop?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Oh, Im deeply sorry. Then you must have to use Braile-Cobol then?
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."
Are you even aware that the x86 instruction set includes BCD opcodes ?
If the compiler developers haven't been using them, that's not the languages' fault. Hardware BCD support is built into every desktop computer sold today.
-Billco, Fnarg.com
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
Which renders the struct no longer binary compatible with the on-tape format.