Pete Dashwood has been a programmer since 1965. He says he intends to keep programming as long as he can see and type. He worked as a contract programmer, business and systems analyst, and project manager all over the world using many different languages and platforms, for around 30 years. Currently, he manages a company which specializes in salvaging and refactoring legacy COBOL. His articles and comments are published in newspapers, magazines, and on the Web and he has had his own regular column in more than one printed magazine. As a consultant to some of the World’s Blue Chip Corporations, he has brought major projects in on time and budget and really enjoys working with technical teams. Peter has posted 1 posts at DZone. You can read more from them at their website. View Full User Profile

Cretaceous COBOL Can Spawn Jurassic Java

04.17.2012
| 14877 views |
  • submit to reddit

FORTRESS COBOL

For many people working on mainframe sites, it was impossible to predict the demise of COBOL.

One minute, it was in the top three programming languages (for around 30 years) then suddenly it is around 30th.

COBOL programmers mostly never saw the approaching comet and the ones who did were viewed with suspicion by the Priests of COBOL whose job it was to protect the sanctity of the Holy Source Code. Deep within Fortress COBOL, innovation and change were not accepted gladly; rather, any form of heresy (like using Relational databases instead of indexed files) was immediately nipped in the bud and ridiculed by the use of arguments about efficiency, ghastly overheads in RDBMS, and the inexorable and irrefutable: “We’ve ALWAYS done it this way and it works.”

Life was pretty good for the Knights COBOLLers.  They lived behind a magic waterfall which provided seclusion from the annoyance of having to write applications. Mostly, they could treat the Holy Mainframe as if it were their own property and spend time checking out new packages and software that would look good on a résumé.  Writing COBOL is actually fun, so even when real work had to be done, it wasn’t so terrible. And nobody outside of IT understood what they were doing anyway…

It was a heady time when Computer Science was still a toddler and practical experience was everything. People received a two week COBOL course and became “computer programmers”. (Many of them did the job very well but, without “best practice” guidelines, and allied with COBOL’s “English like” propensity, there was a tendency to devise logic in muddled English and, after a few years of various practitioners taking their own crack at it, the result was code that no-one dared maintain.)

The Waterfall ensured that anything that was delivered was at least six months out of date and the business received “something like” what they had requested during “Requirements Gathering”  which may have been a year ago.  This led to the situation where the business would accept the new system and immediately have to request amendments to it. These requests made the COBOL people feel unloved and unappreciated so they slunk off behind the waterfall and took their time getting the new enhancements implemented.

Sorcery and Heresy

Robert Townsend in his 1970 Novel “Up the Organisation” summed up the IT department as follows:

"Most computer technicians are complicators, not simplifiers. They're trying to make it look tough. Not easy. They're building a mystique, a priesthood, their own mumbo-jumbo ritual to keep you from knowing what they - and you - are doing."

It was pretty fair comment for the time. (Some would say we haven’t changed much, but I like to think we have; there is a big difference between prototyping new functionality or deriving Use Cases with users in a JAD workshop or Agile scrum, and having an “IT only” meeting to develop a task oriented PERT Network that decides when the next milestone on the waterfall should be delivered…)

PERT (Program Evaluation and Review Technique) was developed to support the Polaris submarine building program.  Hardly surprising then that many waterfalled IT projects end up torpedoed or submerged…

The IT world changed in the early 1980s with the advent of a desktop personal computer/workstation and the development of the Relational Data Model.

Kids started programming in BASIC. The “professionals” heaped their derision on the new “toy computers” that could never possibly take on the business loads handled daily by the mainframe.

Then people started connecting computers together so they could share information and have more processors available. The “network” grew rapidly in power and strength and the “Internet” (a network of networks) emerged.

The procedural paradigm, which had been ideal for a centralised single processor, was overtaken by a new paradigm where, instead of everything being controlled from  centralised code, events occurred and were dealt with immediately in real time, by small, encapsulated “objects” that could be re-used and even flashed around the network to  different processors so that loads could be levelled.

Functionality could be viewed as “Classes” of code which contained attributes and behaviours and communicated by means of an interface which kept the “internals” isolated from the environment. Code development became “component based”. Systems were built like Lego; very quickly from components already available. The old days of “knock on” errors in monolithic code became a thing of the past. A one line change in a COBOL program could have consequences down the processing chain, many thousands of lines of code away from where the change was made.  Languages using the new OO paradigm did not suffer from this to anything like the same extent. Everything communicated through interfaces and there were layers and separation of functions like Presentation, Business Logic, and Data Access.

The programming world was abuzz with words like “Object Orientation”, “Polymorphism”, “Method Signatures”, their own jargon that made it possible to swap ideas across different programming languages. Methods and properties were the same whether you implemented them in Java or C++ (and, a little later, in C#).

Enlightenment dawns

The new world was far removed from COBOL and the COBOLLers watched from their Fortresses as the Barbarians on their lighter faster ponies, simply overran the world.

Programming languages, scripting languages, web development; the world voted with its feet and embraced the OO paradigm.

Object Orientation WAS added to COBOL around 1990 but IBM did not implement it fully and it fell to companies like Micro Focus and Fujitsu, who were providing compilers for the workstation platforms, to do a proper job of it.

Sadly, the COBOL community mostly did not embrace it and the reasons for this are complex and manifold. The fact is that COBOL missed the OO boat and now there is some frantic paddling to try and catch up. Modern languages like Java and C# are moving to fill the space and most of the early hesitation about commercial software development in OO languages has proven to be groundless.

Here in 2012, a new generation that has grown up with computers is arriving in the workplace. They know about spreadsheets and databases and use applications easily. It is as if the mysterious role of the COBOL Priest was subsumed as soon as everyone could read the scripture for themselves.  Within the Fortress though, the web is awash with wailing and gnashing of teeth on big business sites over the decline of COBOL and where to go next.

I was recently reading an article on the Computerworld site that seems to think the decline is being forced because the world’s COBOL programmers have all turned into old codgers and will be retiring soon.

It isn't a "brain drain" on the part of COBOL programmers that is causing the problem; it is failure by senior management to stay in touch and recognize that there is a sea change going on. It isn't like it happened overnight.

Management sometimes don’t get it

For over 20 years now it has been apparent that the paradigm has changed.

Management should have seen what was coming and planned for it YEARS ago, long before Y2K.  (To be fair, in many smaller organizations they did; it is the big outfits who believed they were immune. Those same outfits are ponderous, resistant to change, and now wondering where to go next. So what do they do? Blame the programmers. They're all retiring... Gee, who could have predicted that?)

I can't find much sympathy for the leader of a major Bank who employs a couple of hundred COBOL guys and responds to the problem by deciding that they will keep on doing what they have always done. Or an IBM guy (with an obvious vested interest), whose attitude is "nothing to see here" and who patently doesn't get it either. No imagination, no solution and no grasp of what the options are. Same old, same old... buy a new compiler, we'll look after you in COBOL...

Various tools have been developed to convert COBOL into Java.

(Search hint: COBOL into Java)

There are even COBOL compilers that emit Java code.

(Search hint:  COBOL compiler to Java)

The problem with that is that if you input Cretaceous COBOL you will get Jurassic Java.

Management generally doesn’t understand why it matters, but programmers do.

You still haven’t addressed the paradigm clash and you can’t get a worthwhile solution until you do.

Simply re-hosting COBOL on a network is NOT a complete solution and only a blind fool would think it is.

You might save some hardware costs but you still haven’t addressed the real problem.

Converting existing procedural code to Java is also NO solution and any decent Java programmer will tell you WHY it isn't. It's like whisky and water; ruins two good things.

If there are priceless "untouchable" nuggets of business rules encapsulated in COBOL in the existing systems, the people to deal with that are the existing programmers who understand the Business. It isn't about outsourcing it to coders who have no knowledge, understanding, or perception of the business, just because they will work for $8 an hour...

Moving on from COBOL is NOT just a coding exercise in ANY language. If there is no strategic vision and the people tasked with making the decisions have no idea what is involved, how can it be anything other than a fiasco?

They need to look at the options and tools available, get skills and knowledge transfer going on while they still have people on site who understand the code, and they should be ensuring that the "rising generation" of programmers are involved with the legacy systems.

It isn't hard for a modern programmer to learn the COBOL they need to know, and the best way to learn it is to work alongside an "old timer" who not only knows the language but knows the applications and the business. Certainly, the old timers may never understand OO or even want to, but the new breed do and they CAN re-wrap COBOL to migrate it, where it makes sense to do so. It is also possible to build COBOL Classes which incorporate the legacy functionality and can interact with any other OO language.  There are tools and compilers to help with this.

One example of a company that provides this technology is Micro Focus, who's been providing COBOL compilers for the PC platform ever since 16 bit computing. They have a tool called Visual COBOL, which is a fully OO .Net compiler that can be useful for refactoring legacy COBOL. It gets legacy programmers used to using a modern IDE and thinking in terms of Classes and Objects. Because it is a CIL generating compiler, Classes developed with it can be used by any other .Net language and also by Java. 

More examples: (Search hint:  COBOL Eclipse)

COBOL CAN be salvaged and it can be “objectified” so it can play on a level playing field like .Net or Mono, and interact properly (and seamlessly) with more modern OO languages,  but the first questions should not be about technical options, they should be about functional options. Can you afford to write off the existing COBOL investment? If not, how much of it is essential to your business? Focus on what NEEDS to be salvaged and get people working on that.

There are more tools arriving every day that can help you refactor your existing COBOL. Other Toolsets extend the life of the COBOL legacy allowing it to be useful for longer and buying you time for new development and migration.

(Search hint: Refactoring COBOL for the 21st Century)

It isn't about a "war" between COBOL and Java (to be frank, that is no contest...), it is about programmers with different training and backgrounds working together to leverage old systems and salvage what is useful, in order to bring timely functionality to the business.

And it needs managers who understand what is important and don’t just formulate strategy based on what some journalist wrote in an airline magazine.
The important thing here is not about what language you move to (some people simply buy a package), it is about ensuring that FUNCTIONALITY (and that includes functionality buried deep in legacy COBOL systems) is made available to the business.

Java guys may find having some COBOL skill or knowledge to be advantageous to them, especially if they are working in large organizations that are still running mainframes.

There is a place for COBOL (especially alongside Java) in today’s world but it is not the same place it held in the last century.
 

Published at DZone with permission of its author, Peter E. C. Dashwood.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Jonathan Fisher replied on Wed, 2012/04/18 - 10:28am

Fantastic article on all points. Anyone who has worked in a mixed environement can attest to the truth of this! The best thing to do is use each language correctly, and write an integration layer that handles the paradigm clash gracefully.

 I think this also applies to Java and Rubyists/Pythonists as well. If you have old Java programs written in the stone age, merely converting them to Ruby/Python is a waste of time. Not try to hijack your article and self promote, but here is my comparison: http://thecodemechanic.wordpress.com/2011/05/30/hate-java/

Pete Dashwood replied on Wed, 2012/05/09 - 8:52am

Thanks for your comment Jonathan.

I think we share a number of concerns but I am possibly more optimistic about the COBOL core being replaced than you are.

It will happen for the following reasons: 1. There is rising awareness (even in Fortress COBOL :-)) that a centralized mainframe costs far more to run and ISN'T more powerful than a properly configured, scalable, distributed Networked system with servers that are becoming ever more powerful and the chance to load level and parallell process better than the mainframe can.

2. Said networked system is cheaper to set up and run than the mainframe also.

3. COBOL is still needed mainly to maintain legacy and to implement batch processing (which it is ideally suited for). Modern systems are designed to reflect everything in real time and don't have much need for overnight "catch-up" processing. Application systems are becoming smaller and more localised and batch processing is simply not required. Once Legacy has been mined and the essentials refactored, there is then no further need for COBOL.

4. COBOL costs more to maintain and run than component based systems comprised of smaller encapsulated Classes that can be reused like Lego blocks.

5. Modern OO approaches address development by working closely with the business. (Agile as opposed to Waterfall). This means the clients have more "buy in" and the delivered applications are more timely and useful.

6. If you want to cling to COBOL you will have to train your own people because the schools are generally not doing it. That is an additional cost on something that is already more expensive than the modern alternative.

For all of these reasons (and a number of other less serious ones), pressure is mounting to move on from COBOL.

I have written more about this and examined the question of whether COBOL is even still relevant, at: http://primacomputing.co.nz/cobol21/COBOLRelevance.aspx

Derek Britton replied on Wed, 2012/05/02 - 4:53am

Normal 0 false false false EN-GB X-NONE X-NONE MicrosoftInternetExplorer4 /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0cm 5.4pt 0cm 5.4pt; mso-para-margin:0cm; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:10.0pt; font-family:"Times New Roman","serif"; mso-fareast-font-family:"Times New Roman";} Normal 0 false false false EN-GB X-NONE X-NONE MicrosoftInternetExplorer4 /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0cm 5.4pt 0cm 5.4pt; mso-para-margin:0cm; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:10.0pt; font-family:"Times New Roman","serif";}

A thoroughly interesting read. The topic of what constitutes the right approach for future enterprise application development and what languages and platforms best support this is a critical issue in the future of IT. 

I have just written a blog that offers my own take on the continued relevance of COBOL and its relation to (and co-existence with) Java for business applications. While many continue to debate the relevance of COBOL, many have found that it remains the preferred choice for systems where application quality and operating cost remain important considerations. Further to this, its relevance as a key business IT language also stems from its ability to comfortably co-exist with other programming languages such as Java.

I invite you to have a read and offer your thoughts: http://blog.microfocus.com/cobol-still-standing-the-test-of-time/1540/

Best wishes,

Derek Britton (Micro Focus)

Pete Dashwood replied on Thu, 2012/05/03 - 10:32am in response to: Derek Britton

Hi Derek,

Thanks for commenting.

I did follow the link and read your blog several times.

Obviously, there are some points we disagree about, but I think we are both interested in seeing a proper evolution of COBOL. It is really a question of how to go about it.

I don't see COBOL as "standing the test of time" at all. It's time was up back in 1995 when the network and the OO paradigm became generally available.

It certainly did what it was designed for and was a reliable and robust language for the environment and paradigm it was intended for. But that was true during most of the latter half of the last century and time moves on.

You CAN write OO Classes in COBOL just as you CAN make fire by rubbing sticks together. It isn't that you CAN'T do it, it is just that there are better ways to do it (like matches or cigarette lighters... :-))

The modern languages (like Java, C#, even VB.Net) just do it better and cheaper.

Please don't take my comments as being in any way personal or hostile; they aren't. I just happen to disagree with some of what you wrote. (I'd be the first to admit that some of what I wrote is arguable, also :-))

I think if we got together, we could spend an interesting and productive time (probably over a few beers) looking at the various strategies for COBOL in the future.

Sadly, distances preclude that, but I'll be happy to comment on any future blog posts if you want me to.

Best Regards,

Pete.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.