Why COBOL Could Come Back 405
snydeq writes "Sure 'legacy systems archaeologist' ranks as one of the 7 dirtiest jobs in IT, but COBOL skills might see a scant revival in the wake of California's high-profile pay-cut debacle. After all, as Fatal Exception's Neil McAllister points out, new code may in fact be more expensive than old code. According to an IDC survey, code complexity is on the rise. And it's not the applications that are growing more complex, but the technologies themselves. 'Multicore processing, SOA, and Web 2.0 all contribute to rising software development costs,' which include $5 million to $22 million spent on fixing defects per company per year. Do the math, and California's proposed $177 million nine-year modernization project cost will double, McAllister writes. Perhaps numbers like those won't deter modernization efforts, but the estimated 90,000 coders still versed in COBOL may find themselves in high demand teaching new dogs old tricks."
Same COBOL guys from Y2K? (Score:3, Informative)
Re:Who Cares What Language, It Reeks of Poor Desig (Score:5, Informative)
Re:the guy wasn't going to reduce the pay anyways (Score:4, Informative)
I've seen it, sure, but... I dunno. I've got no reason to think the guy's lying.
You want everybody's pay cut down to six whatever? I can do that for you in /ten minutes/. Guaranteed. You say you want it to happen, I make it happen.
You want everybody's pay cut down to six whatever, recalculating all employees as if they were paid on an hourly basis, reclassifying employees as appropriate, comply in full with all labor codes while I do so, maintain an escrow account with the difference between their real pay and their current pay, pay that out at some undetermined point in the future -- and have all of it work, perfectly, the first time and every time, taking full responsibility for every employee of the STATE OF CALIFORNIA?
Man says six months, I'm not telling you he's wrong.
Re:I can see it now . . . . (Score:3, Informative)
I can't tell if you're jesting, or if you simple don't know that most of the cobol variants you named actually do exist....
COBOL just works (Score:5, Informative)
Companies like Wal Mart, ACXIOM, and large transportation companies such as JB Hunt, ABF, USA Truck, Wingfoot Commercial Tire, and Data-Tronics use it day-in and day-out.
However, unlike the COBOL I always read about here on Slashdot, the code we work with is standardized, modularized, and backed with a relational database (IBM DB2).
I also happen to work in more modern languages (compared to COBOL) such as PHP, ASP, and
Don't disregard a language simply because it's old, or because you don't have a fancy IDE to rely upon. Compared to some of the messy AJAX implementations I've seen, I'd take COBOL any day.
Re:"find me a college that teaches it" (Score:1, Informative)
Southeast Community College in Milford Nebraska http://www.southeast.edu/academics/default.asp [southeast.edu] is One College that still teaches COBOL. They've done some re-vamping with the curriculum since I've been there (creating a COBOL back-end with a pc front-end) but COBOL programming is still their main language. They have multiple hiring agreements with large companies such as DST http://www.dstsystems.com/ [dstsystems.com]
Re:"find me a college that teaches it" (Score:5, Informative)
My old 2 year school still teaches COBOL, RPG, and AIX classes (Southwest Tennessee Community College) and even offers a 2 year A.S. degree in those technologies. The University of Memphis used to teach COBOL in the MIS track, but I have a feeling they've jumped on the .NET bandwagon. I can't speak for the rest of the country, but Memphis, TN has a lot of legacy mainframes and one of my former employer still churns out around 10k lines of new COBOL code a year, at minimum.
What a lot of folks also don't realize is, you don't just rip out a multi-million dollar mainframe system and just replace it with something new. It's also not as simple as "just coding it in Java" and deploying on that hardware. Hell, even writing it in C has issues on many of these machines. The mainframe I was exposed to didn't support the full ASCII character set and you had to use trigraphs. You can't just "apt-get compiler-for-language-of-choice" on these machines, nor download a .msi and get an instant installer.
These are mainframes. They don't even have a filesystem that you would recognize, much less a bash prompt. JCL anyone?
The point is, it's not a simple matter of just porting the software into a modern language. You'll also have to build out the entire hardware system, write the software, test extensively, and then run both concurrently to ensure consistency, and all of that costs money. Lots and lots of money. If what you have works for what you need it for, there's no impetus to change until something like this comes along. However, I'd be willing to bet it's easier and cheaper to change *policy* (the laws) than to scrap the old system completely and rebuild it from scratch.
I had mod points but didn't see Uninformed listed (Score:3, Informative)
Oh the dilemna of mod points....
IBM still makes brand spanking new Big Irons. But they're not quite as big as they used to be. And they do more. And they also do stuff like run Linux.
Please go educate yourself before you look like a bigger moron.
Re:Who Cares What Language, It Reeks of Poor Desig (Score:5, Informative)
Coming from someone who is currently supporting a legacy COBOL system, you're right on target.
COBOL is shit. Most legacy COBOL code is not designed with anything like what we'd consider "best practices" today. The language itself is unfriendly, and doesn't lend itself to the modern world.
What it does have is inertia. It works, right? Why replace it? It's the product of decades of business evolution, do you think you can replace that overnight? New code will never be as good.
Basically, they're comfortable with their crusty old bugs, and they don't want to deal with scary new bugs.
In my environment we've basically thrown this whole interface built on Oracle and Java on TOP of the old COBOL MPE/ix system. Placates the conservative financial types, while providing some modern functionality.
Still there are all kinds of problems with the old systems. You can end up with some really scary problems with old code, because it doesn't recover from failure like you'd expect modern code to. A java billing application running on a modern transactional database...If it crashes, you can just run it again. A COBOL app on a legacy database? That just ruined your day.
I would hope that the response to the situation would be to finally migrate your systems, not to accrete more levels of unsupportable crap by dragging COBOL programmers out of retirement, or forcing existing programmers into that outdated mold. I know the money types though; they are perfectly capable of trying to stick with the outdated method simply because it's in their comfort zone.
COBOL Less Expensive? (Score:3, Informative)
As a recovering COBOL Programmer (MVS/XA, IMS/DB, CICS, DB/2, VSAM, JCL ;^) I find it hard to believe that coding COBOL programs is "cheaper" in any real, absolute sense. If you are comparing "KLOC", then yes, COBOL is cheaper, because each line is "easier", but it likely does less work than a "higher-level"language line of code would do...
Comparing LOC per function point, not sure - it seems that we have lower expectaions/goals for COBOL code, so function points don't really compare.
Is it because programmers are cheaper for COBOL, ignoring function points and KLOC? Perhaps, but that ignores the likely greater number of cheaper COBOL programmers.
COBOL, Mainframes, and timesharing technologies have been on the way out for my entire career (I've been in IT since the late 80's), and the driver seems to be fashion, and it's saving grace is always that these proven technologies have stood the test of time and still work just fine, thank you very much.
Also, I refuse to believe that it would take half a year to cut state worker salaries to minimum wages - they can accomodate annual salary increases can't they?
Re:Cobol still runs on hardware (Score:4, Informative)
>Eventually the COBOL systems will be replaced simply because they run on computers that
>aren't compatible with today's designs.
Completely wrong. There is Cobol code from 1960s running on todays IBM Z10 processor. IBM is almost always backward compatible. IBM ain't Microsoft where the code breaks every couple years when MS releases a new windows or a service pack.
Re:Who Cares What Language, It Reeks of Poor Desig (Score:5, Informative)
Yup, no doubt the people that implemented this system were complete idiots, unable to come up a system that was 'well designed'. Oh wait, I wonder what 'good design' was when this was written. Maybe it included things such as 'being able to run in a machine with 16MB virtual address space, with 1MB real memory installed'.
As for security, you're probably also right there. It seems just about every week I read a report of some COBOL-based payroll system being hacked (which you would expect, since there are probably thousands of such installations). Oh wait, I never read that.
It seems to me you are quick to criticize, without even a basic understanding of the requirements for this change. It is NOT some simple 'raise minimum wage'. It is 'temporarily lower ALL employees wages (hourly and salaried) to minimum wage'. When the budget is passed, put the wages back where they were and issue back pay. Don't forget about little details like deductions for taxes, insurance, retirement, etc. How do you calculate the withholding rate for income tax? What do you do when someones deductions exceed their pay? When the pay is restored, what do you do about people that have left, retired, or died in the meantime?
I think that the timeframe they give is not all that unreasonable, considering all that must be done. It will take a substantial amount of time just to come up with complete requirements. Then the coding must be done. Since this is a financial application I am sure there is much testing, and probably some fairly stringent auditing that must also occur.
Re:I don't get it (Score:5, Informative)
Like was mentioned in a previous reply, it's not JUST learning COBOL, there is also other stuff like CICS, that you have to know as well.
But you take something else like C. I can get gcc, and start writing code. Same thing if I want to do some web 2.0 project. It's almost trivial to get a LAMP setup up and running.
There's nothing that can simulate a working z/OS environment. There's no compilers to download. There's an emulator out there called Hercules for various IBM mainframes, but you can't get the OS to run on top of it. It's near impossible to go grab "COBOL for Dummies", and start firing up code. COBOL is also rarely taught in university anymore. So the only place you COULD get some exposure to the system, you aren't going to get it. Even if you COULD download the OS, setting it up is very nontrivial. And it's NOTHING like you've seen before.
And these systems aren't just 100% COBOL either. There's a host of mainframe type things like Natural for an ADABAS Database that you're NEVER have experience doing unless you already have a job doing it. You got to the point to where you wrote that program in COBOL, now do you know the JCL to set it up to run? Ok it ran, know what a SOC-7 error is? BTW, it's an uninitialized numeric to save you from typing it into Google.
All these things mean the vast majority of people out there now just don't have ANY experience in dealing with these things. It's hard enough to find people that can step into a team to support a major project. Add in those legacy requirements, and it's probably nil. Anyone qualified to do it, is probably 3 years from retirement from where they are at, and would probably have to offer 7 figures a year to make it worth their while to screw up their retirement options.
Re:Who Cares What Language, It Reeks of Poor Desig (Score:5, Informative)
>I think many people missed the point of the California problem
That was part of it but reality is that it is mostly politics.
According to a post on USENET (in bit.listserv.ibm-main) by a guy who actually worked on the code, it is all VSAM files for database and table driven. Trival to change to min wage and just being VSAM means you could just duplicate the files and easily maintain 2 sets of files - one with min wage and one with the real wage.
No, the answer is the politician don't want to do it so just come up with any excuse to say it is "impossible".
a little refreshment of COBOL for all (Score:5, Informative)
http://99-bottles-of-beer.net/language-cobol-1820.html [99-bottles-of-beer.net]
*nawcom reads the first part of the code and pukes all over the screen*
Re:COBOL has loops? (Score:3, Informative)
Re:I don't get it (Score:0, Informative)
No, its a SYSTEM ERROR number 0C7 (zero cee seven) DATA EXCEPTION. There! I saved hundreds of queries from
Re:Who Cares What Language, It Reeks of Poor Desig (Score:3, Informative)
Since COBOL doesn't have subroutines or any way to pass parameters save global variables, I would say that is a safe bet.
Actually that is what CICS and other architecture layers are used for. What we like to refer to as a COBOL program is usually a module or piece of a larger system flow. The language doesn't provide robust support for modularization, so various architects developed frameworks to support the need. One of the aspects of that is that many systems are composed of small, fairly simple modules which are passed a communications control record, which is used for inter-module communication. Within each module, you're right, all variables are global, but COBOL modules in these systems tend to be comparable in size to class files in the Java I work with today.
It's possible, and fairly common even, for large COBOL systems to have quite a bit of architecture and structure available. Sure, I like modern stuff better, but it's just ignorant to pretend that modern coding practices emerged in 1997 like a mushroom after the rain.
Re:Who Cares What Language, It Reeks of Poor Desig (Score:3, Informative)