The Death of COBOL By John Murray APPLICATIONS I read an article a while ago that made a strong defense for using COBOL. Unfortunately, I can_t recall the publication or the name o f the author. The author talked about a group of gurus who, during the mid-1980s, proclaimed the immediate death of Cobol and the flowering of fou rth generation programming languages (4GLs). The thrust of the article, as I recall, implied that we can all sleep well because Cob ol is alive and well and is here to stay. As a speaker at various conferences and seminars during that period, I was one of those (not a guru by any means, more a humble recr uit at the taffeta booth) proclaiming the death of Cobol. Because I took that stand, I feel responsible to set the record straight a bout Cobol. People still mention my comments from those days past. Usually when the subject comes up, the cast of the comments is that I may hav e been premature, if not mistaken in my pronouncements. Mark it down: Cobol is dead! _Oh no,_ comes the response, _look at all the information processing installations using COBOL._ I know, I know! I did not say, have never said, that Cobol is gone. I only said it is dead. Is this a hard idea to understand? It sh ouldn_t be. Look around your office. There is, I suspect, at least one person who has died and yet still shows up for work. The word _dead_ would seem to have shades of meaning. Perhaps Cobol is not dead; it may be a Zombie. So, something can be dead and yet not gone? Right! Cobol is an excellent example of that phenomenon. COBOL is probably not alone; th ere are, I suspect, even some vestiges of Autocoder still extant. Autocoder, for those under 45 who may have never heard the term, w as a precursor of COBOL. It is unlikely anyone would argue very forcefully that Autocoder is not dead, yet some remnants of it are p robably still with us. There are two reasons that COBOL, although dead, has not yet been buried. The first has to do with the large established base of sys tems written in the language. Of course, it will take time and effort to move those systems from COBOL to a sound 4GL. During that i nterim, the COBOL base has to be maintained. It would be an economic impossibility for most MIS installations to mount a campaign to redo everything now in COBOL to a more advan ced programming language (just for the sake of moving to a 4GL environment). The area of contention lies in those situations where r ewrites or new systems are begun and the only option considered is to do the work in COBOL. In some installations, of course, there will not be any other option. The cause will be the absence of a 4GL within the installation . The circumstance may be that MIS management is unwilling to mount a campaign to move to a 4GL. Perhaps the managers have a COBOL b ias and therefore have no interest in moving to a 4GL. It may be the case that the organization_s senior management will not provide the funds to go to a 4GL. If that is the case, the cause of that circumstance has more to do with the ineffectiveness of MIS manage ment to sell the benefits of the 4GL than with any other fact. Selling the benefit of a 4GL is not a particularly difficult thing to do, but doing so requires an awareness by MIS management of th e value of that tool to the organization. Selling the 4GL is not terribly different from any other sales effort. You have to believe in the product or service to make the sale. The reality in our profession is that too many people do not, or will not, believe in t he value of a 4GL. Even with the demonstrated productivity of the technology and the general acceptance of the 4GL, you still come across people who wi ll contend that the tools take too much hardware resource. What? I would have thought that argument would be dead by now. Perhaps th is is yet another example of dead, but not gone. Anyone who feels they can develop a case today that says, given the dramatic improv ements in the cost of raw processing power (particularly in the microcomputer area), the use of a 4GL concerning hardware expense is prohibitive, is simply incorrect. Even in installations that have the tools, you can find resistance to moving away from the use of COBOL. In those installations, the re is usually no valid reason to continue with COBOL. But then who said that COBOL bigots were reasonable? In those installations, t he strategy should be to eliminate the use of COBOL as quickly as possible. Doing so is not going to be easy. It may not happen fast , but it should be accomplished. Another reason COBOL hangs on has nothing to do with the technology. The issues here are managerial, cultural and emotional. Many of our peers are comfortable with COBOL. Many have, from a business perspective, grown up with COBOL. That being the case, moving to something different, albeit something de monstrably better, can be a very difficult proposition. A lot of people are saddled with COBOL baggage. It_s going to take time to e ffect the necessary changes. To a large extent, the problem is a generation problem. People entering the work force, either with technical training or with micro computer experience, are usually exposed to some type of 4GL. Convincing those people that COBOL is a better language to use than a good 4GL is probably not going to work. Not to say they don_t fall into situations where, if they want to remain employed, they are going to have to use COBOL. That represents an unfortunate circumstance, not only for the employee, but ultimately for the organizat ion. Is Using a 4GL really better? Yes, there is simply no doubt about that answer. You can find 4GL adherents, even some reformed COBOL types, who will state that cod e can be developed much more rapidly in a 4GL compared to COBOL. People will cite increased productivity levels of four times to 10 times or even greater. My experience is that an improvement average of four times to six times represents a figure you can take to t he bank. Granted, done correctly, the other aspects of project development, preparing the specifications, system design, testing etc., are go ing to take approximately the same amount of time in most instances regardless of whether a 4GL is used or not. However, no one can dispute that speeding the coding process by factors of four or five has to be viewed as a significant improvement. When we talk of increasing programming productivity by factors of four or five, we are talking significant savings. If those savings can be realized, the money saved can be directed toward the reduction of the typical MIS development section project backlog. There are examples of installations that have installed a data base and a 4GL, and by aggressively following a plan to reduce the backlog have delivered dramatic results. Beyond coding improvements, we are talking about something more dramatic and ultimately of more value to our organizations. The spee d and flexibility of a 4GL can help improve competitive advantages. Increasingly, organizations are attempting to find ways to diffe rentiate themselves from their competitors. One of those ways is to provide improved customer service. In most organizations, there is a direct link between the work done in the MIS section and the levels of service delivered to customers. More and more information processing installations are finding themselves pressured to raise the bar in terms of reworking existing systems or developing new systems. MIS managers are beginning to hear from their senior management that any project that takes longe r than six months to bring operational is going to be a project that takes too long. Given that circumstance, it is likely to become a larger issue as we move forward. Any installation relying heavily on COBOL is in trouble. The bar is not going to be raised by th e continued use of COBOL. Consider this: In the past, when COBOL was the only practical option, obtaining a competitive advantage through the rapid developmen t of new applications systems, or the enhancement of existing systems, took everyone about the same amount of time. Of course, some well managed installations, which had installed the proper discipline and had a strong focus, could deliver systems a bit faster. Be cause no one could dramatically reduce development time; no one had a clear advantage. That is changing, and the cause of the change is the effective use of data base technology and 4GL programming tools. Has it taken longer than it should for those results to appear? Yes! The reasons are many. The point is that using the technology ha s finally come of age. No question about it. If your organization is locked into COBOL, you face some real problems in the future. T he proof is easy to present. Overall, our industry has had a less than sterling performance record, considering the resources that have been invested. The industry has been built on a COBOL foundation. Could there be any correlation between COBOL and where we ar e today? The causes transcend COBOL, but it plays a large part in the problem. So much for COBOL: dead is dead. Now, thinking about OS/2! /* Was this article of value to you? If so, please let us know by circling Reader Service No. 78. The Death of COBOL By John Murray COBOL is Dead! RIP! I DIGITAL CONSULTING NEW MATS CYAN READER SERVICE NO. 8 PAGE 23 The Death of COBOL Technical Support / June 1992 18 John P. Murray is a senior MIS consultant with the Viking Insurance Company in Madison, Wis.