Slashdot Mirror
Modernizing the Common Language - COBOL
Frumious Wombat writes "Over at the Register Developers section, they are quoting the head of research for Ovum Consulting on the continuing dominance of COBOL in certain business applications. The antique language accounted for 75% of all business transactions last year, and some 90% of financial transactions. For all the time spent arguing the merits of Ruby vs. C#, should the community spend more time building tools to make COBOL livable? The article goes into what it terms 'legacy modernization', and lays out some details on how to go about it. From the article: 'The first stage in the legacy modernization process is to understand the business value embodied within legacy systems. This means that developers must give business domain experts (business analysts) access to the legacy, using tools that help them find their way around it at the business level. Some awareness of, say, COBOL and of the legacy architectures will be helpful but we aren't talking about programmers rooting around in code - modern tools can automate much of this analysis for staff working at a higher level.'"
Seriously, MS has had no real reason to do a secure OS. In fact, the opposite is true. It is the add-ons that make money for everybody. Of course, with apple having been secured and linux up and coming, MS is finally under pressure to do the right thing.
Because, it makes sense.
You don't have to develop corporate variable naming standards, coding standards, and all that, because the language makes it happen automatically.
You can take a fresh wet behind the ears kid, give him the code, and he can figure out what's going on without any significant trouble, because it happens in order, there is none of this fancy renaming variables on the fly and obfuscating code with magic numbers stuff that is all the rage in C++, Java, and other "modern" languages.
You want to add 2 and 2? Great, you get 4, which is what the accountants want. You can't program 2+2 to equal 27 like you can in C++. One operation does one thing, does it well and accurately, and moves on.
Business only has one real question: "How much money did I make last year?" COBOL provides all the tools to answer it.
That is why COBOL lives, and always will.
From TFA: "So, perhaps the real bottom line is that legacy reclamation isnt a second-class project for tired developers. It is an important part of your IT process and needs access to your best, brightest and most flexible brains."
If only such decisions could be realized in today's business setting. Unfortunately, updating/migrating legacy systems (even mission-critical ones!) seems to be the assigned task for interns, new hires fresh out of university, and contract programmers in India.
Insisting on "correct" English is like saying that there is only one, definitive recipe for chili.
Every person I've met with writing talent throws lots of stuff away. They do it without a second thought, and the next attempt is almost always better. Why should writing software be any different? If the legacy is so bad as to be entirely undocumented and filled with back doors, work-arounds and pitfalls, what do you lose by rewriting? It's not like editing the crap code is going to be any faster or less error-prone.
In fact, there's many benefits to rewriting. It allows for proper documentation to be created (design diagrams, use cases, requirements documents) if it was missing. It allows for new technologies to be considered, and to plan for another 30 years of operation. If the software was created using a robust process, the design diagrams, use cases and requirements documents are already written. That's the hard part; any coder worth his salt should be able to exactly duplicate the application from those artifacts.
I don't think the risk is as bad as business types claim it to be. Is it really any more of a risk to "Rip and Replace" when it's at least as likely that either the ancient hardware that the application runs on fails without replacements being available, or that the one person in the entire company who actually knows all the stuff that should be written down in the non-existent documentation retires, and there's no replacement available? The article mentions in 2 of the 3 legacy reclamation techniques that a domain expert would be required. The fact that many of the domain experts are going to be or have already retired should be additional incentive to do the "Rip and Replace" while they're still available.
mandelbr0t
"Please describe the scientific nature of the 'whammy'" - Agent Scully
Modernize - the bottomless pit to throw consulting dollars into. Most attempts to rewrite a legacy app into a modern language have met with failure by way of the modern language becomming obsolete before the project is finished. One such project I witnessed ended up with 7 years of VB development being scrapped after a merger - in favor of the other company's unfinished conversion of their legacy app. Either way, there was a scheduled conversion from VB6 to .NET that hadn't even begun (and the app still was still heavily dependent on the legacy app to finish most tasks.) Ugh.
One, these figures result from the simple fact that COBOL was pretty much the only high-level language around at those pre-historic times many of the major applications were written. And banks are very, very conservative environments where something that works will not be thrown away for something that might have bugs, even if it's 10x as fast, easy to maintain or whatever. It has to work and that's priority #1, #2 and #3.
Two, the reason COBOL is so widespread in financial institutions has nothing to do with business sense and everything with business mind. It is "readable" to a business dude with zero computing experience. Something like "ADD PROFITMARGIN TO PRICE" just makes these people feel more at easy than "$price+=$p_margin".
Assorted stuff I do sometimes: Lemuria.org
This simply underlines the fact that there's a huge workload of easy, routine transactions that need to be done.
In terms of total complexity, the financial world is probably something like Excel 20%, C# 15%, Java 30%, C++ 30%, other 5%.
But in terms of transactions, I can well believe it's COBOL 70%, REXX/VB/4GLs 25%, other 5%.
Modelling a CDO *is* hard, and you don't do it in COBOL. Creating a visual system to monitor liquidity *is* hard and you don't do it in COBOL. 'Transactions' pure and simple are not hard... you can do them in COBOL... they're easy to maintain because changes are of the form 'deduct 5% if broker_country_of_incorporation = finland'... and they're also a darn silly way to measure the relevance of a language.
Whence? Hence. Whither? Thither.
But, does this mean that the "community" should help? Why should *I* build such tools, why should *you*? That's the problem of the financial institutes, and they are willing to pay large sums to get their code maintained and modernized in COBOL. And if they want to have a nice development tool, so they have to pay for it (probably indirect by paying a software development enterprise, which creates and then uses such a tool).
Once you guys get jobs in the Real World, you will realize that businesses don't care about technology, they care about solutions.
No business person in their right mind would rewrite all their COBOL code into C or Java just for the sake of modernization. That would be foolish and stupid, and they would deserve to be fired from their jobs. Everything works, why change it. Financial institutions that have their entire livelihood based on these COBOL programs would rather upgrade their hardware and make THAT modern, but keep their legacy code. They already went through a multi-billion dollar fixing for the Y2K industry, that's more than enough for them. The next problem is either 2038 or 2050, when the Y2K issue is revisited because of how most companies implemented their "fix" (any date > 50 would be considered in the 21st century).
I was working at a bank during late 90s and during a building-wide Y2K meeting, one of the project managers was explaining to us how they implemented the solution. Someone in the crowd asked "Won't we go through this problem again in 2050?" He answered "Yes, but I'll be dead then, so I don't care."
That is how business people think... they care about solutions, they don't care about technology. Don't waste your time navel-gazing and trying to figure out brilliant ways of modernization COBOL, because no one who uses it cares. Keep your great ideas for the new ideas where the barrier to implementing new solutions and new technology is much lower.
The problem I had with COBOL, PL/1, Pascal and Modula 2 were they were wordy.
A lot of typing to perform simple operations. This is why I like C, minimal typing for great power.
More or less works for Java and later languages, too.
A feeling of having made the same mistake before: Deja Foobar
The reason there is so much legacy code about is because that code has been around for some years, is proven and is bug free.
The slashdot article assumes that because of this the code may benefit from change. In fact the exact opposite is the case. Change introduces bugs and costs money, so I cannot see this happening.
The antique language accounted for 75% of all business transactions last year, and some 90% of financial transactions. For all the time spent arguing the merits of Ruby vs. C#, should the community spend more time building tools to make COBOL livable? The article goes into what it terms 'legacy modernization', and lays out some details on how to go about it.
I mean, it's only big (huge!) corporations running big back-ends that use COBOL, why should "the community" bother much with that? I doubt it's anyone's itch to scratch. Customers want to run COBOL because the code has had decades of real-world production use, not because of COBOLs merits. If the same people still ran assembler code, I'd trust that too. Doesn't mean I'd like to give up on modern languages because of it. If I heard the words "legacy modernization", I'd think "don't break what works". Doesn't mean big new developments are made in COBOL, they interface it.
I'm almost convinced that COBOL will be running on systems a hundred years from now. Any Turing complete language could produce working code to solve anything (or well, as much as any other Turing complete one, anyway). Clearly there's some such code in COBOL, which it makes no sense to reimplement in another language just for the sake of reimplementing it. But I don't see the benefit of trying to revive COBOL development, there are now much better tools for the job. How long has it been since the term "Completely Obsolete Business Oriented Language" was coined? It's dead, Jim. The only tools needed are those to ease its passing.
Live today, because you never know what tomorrow brings
ABEND: Syntax error.
You forgot the period.
Done with slashdot, done with nerds, getting a life.
According to that Wikipedia article, the most recent ANSI COBOL standard is from 2002. Doesn't sound like a dead language. Hm, the 2002 standard includes OOP and other modern features.
I think that rewriting it on VB is somehow related to the repeated failures.
VB is nice for the small things or even for the unambitious GUI layer of something larger, but it is just not suited for long-life projects - it introduces too much ugliness too early into the product life and maintenance usually makes it even uglier.
http://www.dieblinkenlights.com
The company I work for (large fortune 500 company) still uses a lot of cobol on the mainframe for financial transactions. Why use an "ancient" language? Because there is 20-30 years of business knowledge encoded in the cobol code. Not only that, but it is tested, tried, and it just works perfectly. Rewriting in a modern language would make no sense other than using the "latest technology." Rewriting would most certainly introduce bugs which could potentially cost the company millions since it is running financial processes. Cobol was meant for the business and financial world and is well suited for it.
I got nothin'
Oh please, god, no!!!
I started my professional programming career in 1999 by doing y2k conversion on an s/390. Millions of lines of COBOL. All my friends at college had the cool jobs of C++ GUI's and Java web apps. Even the professors laughed at me when I told them what I was doing. Do you know strange it is to work on code that was last updated 9 years before you were born.
In all seriousness...
I can understand why COBOL is still popular now. From my experience, most major companies made a big technology leap a long time ago, investing millions in massive mainframes to run the company. These systems are still held up and run by their aging staff. (I was 17, the next youngest programmer was 50+). These systems get so massive and complex, "modernizing" is just another word for rewriting.
I suppose 20 years down the road, we'll all be complaining about legacy java systems. 50 years down the road, legacy ruby systems.
Ever chased an else'less IF or a Case where someone forgot to put a "break" in C ?
Ever chased a very subtle bug in C++ where some moron overloaded the wrong operator?
Ever chased an End statement in Pascal where a ; was optional?
Ever chased a ... in any language?
The bottom line is this. Every language has its pluses and minuses. COBAL was designed as a language to handle business operations. It does it well, it does it faithfully and its Proven, Tested, Validated an most of all Trusted (PTVT).
Ask K&R if they think C is a good business operation language, I bet they would reply in the negative.
As to other languages...
The bottom line is COBAL was designed to do exactly what accountants and business need. Its been extended, but the basic functionality that it was designed to do is all still there.
If you don't like the wordiness of COBAL I can understand that, brevity has its place, so go spec a "modern" business transation orineted language, work the bugs out for about 30 years and I am sure banking will adopt it, provided it runs on an IBM Mainframe, since there is simply no way you are gonna handle the transactions on 400 million bank acounts in less then about 6 hours the way BofA or Wells Fargo does, night after night, after night.
Its one thing if your mashup of Perl, Python, Ruby on a rocket sled and javascript all come flying apart and someone cannot read Slashdot for a few hours or someone cannot place an on-line order for a while at Amazon. But just have several thousand ATM's go bonk because the Linux Cluster lost its mind or something like that so that people can't get cash, or make a deposit and see just how fast everyone comes after you with Tar, Feathers and a pitchfork!
Hey KID! Yeah you, get the fuck off my lawn!
Java is popular because strong typing prevents bad programmers from being stupid. If your application is designed by one intelligent architect, most of the coding can be done by code monkeys without causing too much damage (especially if the architecture team writes good automatic tests). With PHP, the code monkeys are going to make a mess. The compiler won't tell them that you can't return strings from functions that are supposed to return integers, etc. If it compiles, you know they're going to ship it. Java does strict checking and won't let people screw things up too badly.
OTOH, if your team is a bunch of good programmers, though, then Java's probably not a good solution. Use something like Perl or Haskell and everyone will be much happier. When you have people that know how to properly bend the rules and understand the consequences, Java is too constraining. (Which is why I use Perl for my personal projects. Wonderfully expressive.)
My other car is first.
The problem with all of these modernization projects is not the language. It is the mass of old data, and the huge mass of business rules that are implemented by the old code. Reimplementing the business rules in new code, without interrupting the business, is just about impossible. Turns out the easy way is usually to just port the old Cobol code to the new environment.
The problem is not the language. The problem is the environment. Consider: A lot of that old Cobol code presently runs on Autocoder 790 systems, which are run by emulators on an OS 360 system, which is run by an emulator on a 390 series "mainframe", which is run by an emulator in the old Sun box that gathers dust in the corner of the old data center.
We really don't need a new language. What we need is something like a Cobol compiler, with an ISAM file-system emulation library, that outputs code for a well defined machine such as a java virtual machine. Then the resulting executables can run on whatever box happens to be handy next year.
This is either funny or insightful. Maybe both.
"Design principles" don't make money. The rule of thumb used most places is, if it ain't broke then don't fix it. Most of these legacy systems are merely tweaked periodically, such as being updated to handle new tax laws. That's far less expensive to do than to throw it all away and start over. It may even be prohibitively expensive just to dig through everything and understand it. Redesigning for the sake of being modern is a waste of money.
Even if the lack of modern techniques makes the process of maintenance difficult (not necessarily true), it's easier to justify the short term cost of keeping it going than to get a budget for a long term rewrite and retraining the programmers (or worse, hiring young hotshots who think they know how things should be done).
good design and documentation.. or code for that matter.
How do you intend on building a replacement for a system that:
1) Is ancient and pretty hard to understand to begin with
2) Has no source code
3) Can never, EVER be turned off
4) You don't specifically know the function of
?
You can either keep using what it was originally built with (okay, not "no" source code, but very little remains)
Or you can add "and is written in very dissimilar and unrelated languages"
Often the best way to "just start using" a better language is to "just start using" a completely separate system, and a propagation tool.
-> which of course leads to "Oracle is slower than our VSAM files! We can't use this!"
I caught the tail end of a talk someone was giving about modern COBOL and how mainframes were becoming more and more relevant (delivered by a hip 19 year old to a room full of 50 year olds) I don't remember specifically what innovation was being talked about, but I think it was along the sophistications of a foreach loop
It was sad.
-- 'The' Lord and Master Bitman On High, Master Of All
You may be in touch with modern software principles but sadly you are out of touch with business principles. Ideology does not make a company money. And a company is about making money not writing code conforming to modern code design.
To make a business case for code change, you need to back up your reasoning by showing how it will either 1) save the company money within 5 years or less (including paying off all the money spent for the code upgrade which at large companies could run into hundreds of millions of dollars) or 2) earn more money for the company (including paying for the code changes) within 5 years or less. You could argue that these are the same things but I look at them differently as one causes earnings to increase indirectly through savings, and the other directly though increased revenue.
If you can't do either, then forget it. If you don't understand why, think about where your paycheque comes from and how the company is going to be able to afford to pay you to work on no-gain projects. If you don't want to understand why, then stay a coder... not even an analyst, stay a coder. You must justify the costs of these kinds of expenditures. Now it is possible and even likely that someone was able to justify the costs of fixing design issues on projects you worked on. However, in corporate life, wholesale 'fixing' of 30 or 40 year old stable code is not usually justifiable for design sake alone.
For example on on projects I have worked on where large companies have modernized their systems (often replacing Cobol code) it always involved monetary reasons. Many times Cobol systems are built on other Cobol systems, which are built on other Cobol systems... Business domains begin crossing back and forth across system boundaries and things (for example customer service) become a nightmare. Take a customer order management process: Customer wants three things, it might take three systems to order it, two different customer service reps, and if something goes wrong, support has to track things across 3 systems. If you want to create a new product package it takes too much time to coordinate between systems and one or more might need programming changes which might mean data conversions if the interfaces change between the systems, etc. If the pain threshold gets to high by holding back the company in effectively competing because their systems piss the users off, piss the customers off, and hold back introduction of competitive products (in other words, if it is costing them more money keeping the old system than replacing it will cost), then they will consider replacing the old systems.
Since we are talking Cobol and financial transactions, we are talking *mostly* about the corporate world. When you are talking about large corporations, the cost to replace even an ordering and billing system can run well into the hundred million dollar range or more. Tens of millions is not uncommon either. Projects in the million dollar range are a dime a dozen in the corporate world.
Note: I don't particularly like Cobol... actually I don't like it period (I like C/C++/Java syntax better because I understadn it :-). But for me to justify something to a customer, it must solve a customers problem. The first thing to remember is their main problem is how to make more money. Period. It is not about supporting good code design. They could have something in place that was the worst coding job in the history of the planet, but if it makes them money it won't matter. Unless of course you can show them in concrete terms that a good design will pay for itself by directly or indirectly making them more money.
-- I ignore anonymous replies to my comments and postings.
Actually, it's been my experiance that if you wait to relese When It's Done, it'll never be done. At some point, you have to hit the ground running and work with what you've got. That's actually how a lot of those old COBOL systems were built. They got to around 95% and found out what all the odd little business rules needed to be by actually using the system. That's what makes legacy projects such a daunting task; the core application isn't too difficult, it's 30 years of business rules that are embedded in the code (and no one knows what they are, where they are, or even why they're there. But when they dissapear, you find out about them fast).
"COBOL is hands down the worst language in common usage today"
Why? Do you have some facts that support your position?
IMHO, as a business oriented (that's what the B stands for) procedural language COBOL is at the top of the heap. COBOL, coupled with top-down structured coding techniques has produced some of the most bug free and easily maintainable code around. That's why it's still running. Think about it every time you stick your plastic into an ATM.
Maybe your problem is with procedural languages in general. When I look at the OOP extensions to COBOL I cringe. But I felt the same about C++. [flame bait]How in the world did C++ gain favor over Objective-C?[/flame bait]
"There are more things in heaven and earth, Horatio, than are dreamt of in your philosophy." Hamlet (I, v, 166-167)