From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: ** X-Spam-Status: No, score=2.1 required=5.0 tests=BAYES_05,INVALID_DATE, MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Xref: utzoo alt.cobol:115 comp.lang.ada:3515 comp.infosystems:78 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!usc!ucsd!ucsdhub!hp-sdd!ncr-sd!ncrcae!hubcap!billwolf%hazel.cs.clemson.edu From: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) Newsgroups: alt.cobol,comp.lang.ada,comp.infosystems Subject: Re: What's really wrong with COBOL? Message-ID: <8458@hubcap.clemson.edu> Date: 22 Mar 90 02:18:38 GMT References: <420@mck-csc.UUCP> Sender: news@hubcap.clemson.edu Reply-To: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu List-Id: >From article <420@mck-csc.UUCP>, by jw@mck-csc.UUCP (Jeffrey Weiss): > All these recent jokes about COBOL's age and verbosity are fun, but, if > we can get serious for just a sec. or two... > > What are the real SUBSTANTIVE problems with COBOL? Suppose I were suddenly in > charge of a large DP shop. Would it make sense for me to migrate away from > COBOL? Remember that my DP shop has billions of lines of installed code in > COBOL, and conversion will require enormous time and cost. Not to mention > exposing me to the risk of problems when installing new softwares. > > Now, I'm a reasonably hi-tech guy, not long out of Engineering school, but > I need real arguments (that make business sense) to give to my boss, the CEO. > And, are there viable alternatives such as "re-engineering" the existing code > and investing in tools that make the COBOL environment more palatable? From a business perspective, the real substantive problem with COBOL is that typically 80% of effort is spent trying to maintain code which fundamentally is unmaintainable. The reason for this is that COBOL has found itself unable to evolve quickly enough to keep up with the last 20-30 years' worth of evolution in programming language technology. The language COBOL was invented by the US Department of Defense, and later abandoned because it was no longer adequate as a tool for the effective support of good software engineering practices. Since the DoD also has had a large installed base of COBOL software, it has been the leader in applying effective strategies for dealing with that particular problem. The Ada programming language was designed with a mechanism called "pragma Interface" which enables it to call code written in other languages. If you have one of the compilers which supports calls to COBOL (the IBM Ada compiler should certainly be able to do this), you can simply call upon your existing COBOL software system for as long as it remains serviceable. Ultimately, old COBOL systems become so unmaintainable that it makes sense to rewrite the system, and at that point the system should be rewritten in Ada. So the conversion need not be done all at once (although there are a number of companies which will gladly do such a conversion for you, for enough $$$); by simply using Ada for all NEW code, it is possible to upgrade to Ada incrementally without too much stress on the organization. Now let me just briefly sketch out why COBOL is considered to be no longer adequate. In Ada there is a concept of separating specification from implementation. You can design a software system in terms of different subsystems by specifying (in a "package specification") how each of the subsystems is to function. Then you compile these into the Ada program library. Now there is an agreement among the members of the software development team that this is what the different subsystems will do, and all that remains is to write the software which will cause the subsystems to do what is expected of them. What has happened is: we have broken down a large problem into several smaller subproblems. Now the project can be broken up into several different programming teams, NONE OF WHICH KNOWS ANYTHING ABOUT HOW ANY OF THE OTHER SUBSYSTEMS ARE ACTUALLY IMPLEMENTED. It is enough that they understand how the other subsystems are to operate. They can then write their particular subsystem relying only on the services which the other subsystems have agreed to provide -- the specification of their subsystem is a "contract" that they must fulfill, and in turn the other teams must fulfill their contracts. The Ada compiler will ensure that the terms of the contract are adhered to. So why is this going to help us in maintenance? Well, let's assume that a change is needed. Unless it's a truly major change which would basically invalidate the entire system, we can almost always limit the scope of the change to a particular subsystem. If that subsystem is in turn partitioned into different sub-subsystems, the change can be limited even further. Only the changed area will have to be recompiled, and soon the modified system is up and running. But what if there has to be a change in the terms of a contract? Now the Ada compiler REALLY helps you out... it will automatically identify parts of the software system which depended upon the old contract but which are no longer being satisfied due to the changes which were made. It helps you to minimize the extent of any needed changes, and helps you to track and control the effects of any major change. But more than this -- think about the potential for reusing subsystems. Once you have a very useful subsystem written and tested, you can use it over and over again without any copying of code. With copying of code there is the problem of trying to find all the copies to update them in case there is a change, but in Ada there is no need. If you find a defect in the implementation of a subsystem, you can simply correct the implementation and let the Ada compiler handle the rest. And there is even the ability to construct "generic" subsystems -- subsystems which are written to do something generally and which (with you supplying a small amount of information) can be quickly customized to do it in a particular fashion. For one example, suppose that you wanted to have a priority queue (a system in which items are deposited with different priorities, and you always want to retrieve the item which has the minimum or maximum priority). In Ada, you can write a package Generic_Priority_Queue in which the idea of a priority queue is programmed, without knowing exactly what type of object is to be carried in the queue (the user will decide this). Later, the user comes along, describes the type of object to be carried, and all that software for handling a priority queue is immediately made available for use with that type of object, courtesy of your Ada compiler. You could also describe a network and how to do things with it (compute the shortest path between two points, find out how many connections will have to break in order to cut off all paths between two given points, etc.) independently of the type of object at each point or the nature of the connections. As you can see, this is a very powerful mechanism for reuse. This article is long enough already, but if you pick up a book on the Ada programming language and study it, you will begin to realize just how much advancement has occurred over the last 20-30 years, and how COBOL has not kept up with the times. Please contact me via electronic mail (the address is wtwolfe@hubcap.clemson.edu) if there is anything I can provide (such as hard numbers on exactly how much Ada has been demonstrated to improve productivity) which would fall outside of the intended scope of the alt.cobol newsgroup. As a specialist in Business Information Systems who has chosen Ada as the preferred technology for that domain, I will be happy to provide assistance to anyone who would like more information on why I believe this is far and away the best language technology for the domain of Information Systems applications. Bill Wolfe, wtwolfe@hubcap.clemson.edu