cobol s defense

7/30/2019 Cobol s Defense

http://slidepdf.com/reader/full/cobol-s-defense 1/4

70 IEEE SOFTWARE March/ April 2000 0740-7459/00/$10.00 © 2000 IEEE

Ed Arranga conducted a conferencecall roundtable with six leaders in theCobol field: Ian Archbell, VP ProductManagement, M ERANT; John Bradley,CEO, Liant Software; Pamela Coker,CEO, Acucorp; Ron Langer, Director

Cobol Development, Fujitsu Software;Chuck Townsend, CEO, LegacyJ; andMichael Wheatley, M anager, PLI and Cobol

Strategy and Development. These passionate, intelligent peo-ple discussed a wide range of topics, including Cobol’s indus-

try role, reputation, and future.One question that is not in-

cluded here deserves mentioning:What will happen come Y2K?Each of the participants, in a nut-shell, said “nothing much.” Inthe midst of the Y2K media feed-ing frenzy, I don’t remember oneinterview with a Cobol vendor

executive. Then again, it’s hard to sell news-papers with the three-inch headline, “At theStroke of Y2K: Nothing Much.”

Is Cobol dead? Why or why not? What doesthe future have in store for Cobol?Bradley: If it were dead, we wouldn’t be

here. The question is, why is Cobol still inwidespread use? The answer is, it does the

job, it was conceived for business. Cobol isbuilt around the concept of moving thingsaround in storage. M ost languages are builtaround a lower abstraction level and aremore focused on algorithms. Cobol is not thebest language for every aspect of building abusiness application—Visual Basic might be

better for building user interfaces—but ourinterest is in meeting customers’ needs.Archbell: Cobol is still a very important

part of business-enterprise development. The investments in Cobol are well-known.Here are some interesting facts:

s 75% of all production transactions onmainframes is done using Cobol.

s Over 60% of all Web-access data resideson a mainframe.

s Cobol mainframes process more than83% of all transactions worldwide.

s Over 95% of finance–insurance data isprocessed with Cobol.

Given an option of developing fromscratch, developers might or might not pickCobol. However, the reality is that thosecompanies that have invested in Cobol needto interface old and new. MERANT’s focus isenabling existing investments to be reusedwith a rapid time to market. Cobol is theright choice for developing the businesslogic. When you get to the client–server side,the language choice is less clear.

Coker: Cobol is very much alive and hasevolved and improved through five stan-dards. We at Acucorp feel comfortable cre-ating GUIs in Cobol by giving programmersCobol extensions. Cobol works, it’s a data-centric language, it’s reliable, and it’s fast.Langer:Cobol is definitely not dead. The

investments of the vendors here demonstratethat. The reasons are its maintainabilty andthat the code is still doing useful work.Other languages have not demonstrated thismaintenance capability, and big organiza-

roundtable

In Cobol’s Defense

Ed Arranga



March/April 2000 IEEE SOFTWARE 71

ROUNDTABLE

tions understand this. Fujitsu offers aGUI solution in Cobol that providesthe same functionality as other lan-guages. Cobol is important whenthere is a need for interlanguage sup-port; I’m not sure folks know howwell Cobol supports interlanguagedevelopment.Townsend:Cobol is

dead if we considerthat it is not an attrac-tive programming lan-guage for creating newapplications. New ap-plications are beingbuilt to take advan-tage of new and evolv-ing technologies beingbrought to the mar-

ket, such as MQSeries,SQL Stored Proce-dures, XML, Corba, JavaBeans, andEnterprise JavaBeans. Cobol also isdead if it doesn’t take advantage of leveraging reusable components fromother applications, whether they arewritten in C++or Java. Cobol is deadwhen the alternatives for building at-tractive applications move the cus-tomer beyond Cobol to other solu-tions such as Visual Basic or Java. If our Cobol programmers are getting

older and it’s not being taught in ourschools, then Cobol is dead.

The future of Cobol is putting to-gether solutions thatlet the programmerembrace other lan-guages. Our job is toadd some jazz, to givecompanies what theyare looking for, and toprovide multiplatformsolutions.Archbell: I glossed

over the fact that MER-ANT also has a GUI so-lution. We make Cobolattractive by connect-ing enterprise values with COM,Corba, and EJBs.

Regarding what Chuck Townsendmentioned about schools not teachingCobol, MERANT has an academic grantprogram, which over the last threeyears has grown by almost 60 schools.We have over 350 universities and col-

leges in the US and Canada teachingCobol. We are building large-scalebusiness components with interfacesbetween business logic and the rest of the applications. We get the benefits of write-once, run-anywhere programswith Cobol and deploy them using

COM or EJBs, with100% pure Cobol forthe applications’ busi-ness-logic components.Wheatley: In 1995,

the industry estimatedthat approximately 100billion lines of Cobolwere in production,and many pundits wereforecasting the immi-nent death of the main-

frame and a rapid aban-donment of Cobol ap-plications. Recent studies bythe Gartner Group indicatethat between 150 and 175billion lines of Cobol are inproduction and that the codebase continues to grow.Many, if not most, firmshave learned from their Y2K experience that the Cobol as-sets that run their businessesare much larger and more

complex than they had pre-viously understood, that thedegree of corporate depen-

dence on those assets ismuch higher than theyexpected. An IT execu-tive from a large bro-kerage house recentlytold me they spent tensof millions of dollars inthe late 1980s imple-menting their currentCobol/CICS-based

trading system andthat the thought of re-placing it at this pointis unimaginable.

The challenge for Cobol users isnot how to retire or replace their as-sets but how to transform them inCobol and marry them with newtechnology such as Java applicationsand IBM’s WebSphere to effectivelymeet today’s and tomorrow’s realbusiness needs.

Today, rapid application develop-ment is very important. Does Cobolsupport RAD?Langer:Moving quickly means em-

bracing new technology and going innew directions. If you’re going torewrite in another language, then thecost and time investments are large.

The key is, we can transform Cobolinto new things and can support COMand other technologies so that whenyou want to add a storefront or e-busi-ness piece, the Cobol business logiccan fit in well with that. In some cases,the Cobol pieces are controlling theWeb server or are the business rulescalled from the server. Cobol can par-ticipate and outshine some of theseother languages.

Townsend: Cobol does what itdoes very well, but it’s not very sexyor glamorous.Anoutfit in Red-mond, Washing-ton, is taking ourlunch away, andour message isnot getting out.We need to dis-tinguish ourselvesby doing thingsbetter than it can.

Coker: Obvi-ously, we’ve hadpoor marketing

for years and years. Because Cobolwas “it,” nobody thought we had todefend it. Every new manufacturer—whether M icrosoft, Oracle, or who-ever promoting a different solution—had to say Cobol was dead to createa market for themselves. They’vedone that effectively, and nobody inthe Cobol world has responded. Weneed to focus on applications, not

technology. We need to get our mes-sage out by talking about applica-tions and how happy our customersare, not necessarily focus at the toollevel. Perhaps then, our message willcome through more clearly.Wheatley: Cobol has proven to be

an outstanding language for expressingbusiness rules, manipulating the opera-tional data that businesses depend on,and handling transactions. The subsys-tems in which a large portion of the

Ian Archbell

Pamela Coker

John Bradley



72 IEEE SOFTWARE March/ April 2000

ROUNDTABLE

world’s Cobol code run have proven tobe highly reliable, scalable, and respon-sive. All these characteristics are im-portant components of a successfulbusiness operating on the Internet oranywhere else.

One challenge is tounderstand where wecan most effectivelyuse Cobol to addresscritical business needs.Another is to find waysof marrying it withother technologies thatare more effective thanCobol for doing otherparts of the job (suchas Java for client–sideapplets). A third chal-

lenge is to equip the Cobol developerwith tools and automation that let himor her be responsive to business needs.

Getting back to the language envi-ronment, Steve McConnell has sug-gested that much of what gives a lan-guage its productivity is the inte-grated development environment.Would you agree that Cobol IDEshave not been as powerful as otherlanguages in the recent past?Coker: In the last 10 years, the

IDEs offered by Cobol vendors havebecome as powerful as any offeredby Delphi, Powerbuilder, or VisualBasic.Archbell: Historically, we haven’t

gotten the message out about the tech-nology that is underpinning thoseIDEs and just how powerful our IDEsare. For example, if you take COM andthe Microsoft Trans-action Server, wehaven’t done enough

to let our customersknow you can takeadvantage of thesetechnologies usingCobol. Net Expressworks very effectivelywith COM . An orga-nization will choosethe product that will deliver the solu-tion—the reason is business value.CIOs have to make pragmatic deci-sions: how to leverage what they

have, how to get to the Web, and howto reduce time to market. Given thesefactors, I have no doubt that organi-zations will deploy a majority of theirapplications in Cobol.

What are Cobol’sstrengths? Weaknesses?Archbell: Some

strengths that come tomind are reliability,maintainability, porta-bility, performance ef-ficiency, and availabil-ity. A weakness is thatCobol is seen as static,even though the lan-guage is very dynamic.It is not seen as elegant

in the object-oriented world.Langer: I agree with those strengthsand would add Cobol’s data-accessand data-manipulation capabilities,which no other languagehas. Its weakness is aperception problem.Visual Basic and Javaare very heavily pro-moted, and tremen-dous amounts of money are spent onmarketing. There are a

lot of Cobol vendors,but there is never any-thing in the press, sopeople conclude thelanguage must be dy-ing.Coker:Cobol’s strengths are inter-

operatability and the standardsprocess, but Cobol hasa huge marketingproblem. It has beenoutflanked by Mi-crosoft, the best com-

puter-marketing ma-chine in the world.Wheatley: I’m sure

I tend to lose sightof the forest for thetrees when it comes toCobol’s weaknesses.It’s a big and general

language that we have been growingand enhancing for over 40 years.Clearly, it suffers from carrying for-ward some of the baggage of the past.

Nonetheless, the fact that we continueto execute programs today that werewritten to 1968 Cobol syntax and se-mantics (including preserving error be-havior) is a tribute to the value we’vedelivered to our customers. The ques-tion is not whether Cobol is better orworse than Java; both offer benefits,and they should be used together incomplex and large-scale systems wherewe can achieve those benefits.Bradley: For strengths, I’ll add

Cobol’s precision; it’s precise in aworld of imprecise languages. That’sparticularly important given what it’sused for. Cobol doesn’t do anythinghalfway, doesn’t conceal results. Itsprecision is one reason people staywith or come back to Cobol.

Archbell: I agree with what’s beensaid about Cobol’s strengths. I see thelack of shared knowledge as a weak-ness, as one of the reasons there is

this perception aboutCobol. You canpurchase a thousandbooks on Visual Basicand utilizing new tech-nology. We haven’tdone a good job lettingdevelopers know whatyou can do with Cobol.

Is Cobol a force in in-formation technologyor an anchor?Archbell: We ought

to see Cobol as the anchor against aturbulent onslaught of untried, un-proven, academically driven new infor-mation technology solutions. The in-dustry is always looking for a silverbullet. We had CASE in the ’70s andSmalltalk in the ’80s and ’90s. Cobolwill not be the complete solution for

everyone, but it is and will continue tobe a strong force in business-enterprisedevelopment.Bradley: Cobol’s influence on the

future is great because of its massand the sheer number of users. Smallimprovements in Cobol combine tocreate a large overall benefit in infor-mation technology.Wheatley: Cobol is both a force

and an anchor. The 175 billion linesof Cobol code certainly anchor us

Michael Wheatley

Chuck Townsend

The 175 billionlines of Cobolcode certainly

anchor us down,but they get the

job donereliably,

effectively, andresponsively.

continued on page 75



March/April 2000 IEEE SOFTWARE 75

down in many decisions, but those175 billion lines of code, for the most

part, get the job done reliably, effec-tively, and responsively. An example Iheard recently involved the merger of two major banks where the Cobol-based assets of one bank were cited asa key reason that made the merger at-tractive to the other party. Cobol runsthe operational systems for large andsuccessful businesses—it’s a real force

in the marketplace.

Should something be done to speedup the standard? The last Cobolstandard was in 1985. The next onecomes out in 2002.Archbell: Just because the standard

does not come out does not mean weare static. We put out improvementsabout every 18 months. The slowspeed of the standards does not holdup our products. MERANT has alreadyadopted many of the features of thenew standard such as objects, user-de-fined functions, file sharing, recordlocking, and local storage. We wouldsupport breaking the standard effort

into smaller chunks.Wheatley: There is a big difference

between releasing a new version of alanguage product or tool set and ap-proving a new international standard.I think that you’d be hard pressed tofind a standards body churning outstandards as rapidly as companies cre-ate new versions and releases of soft-ware. Nor do I think that the Cobolcommunity would be well served witha standards committee that released amajor new work every 18 months. Onthe other hand, I think it has been toolong since we updated the last Cobolstandard. We need a happy medium. Ithink two things would help: The

Cobol standards organizations shouldresist the urge to solve all the world’sproblems in one new standard andshould concentrate on smaller andmore frequent enhancements that fo-cus on segments of the language. Tothe extent it is possible, the standardsorganization should resist inventing anew language in a committee. I believethey are most effective when they stan-dardize, rationalize, normalize, andbless what already exists.

ROUNDTABLE

continued from page 72

How to Reach Us

Writers

For detailed information on submitting articles,write for our Editorial Guidelines ([email protected]), or access computer.org/software/author.htm.

Letters to the EditorSend letters to

Letters Editor

IEEE Software 10662 Los Vaqueros CircleLos Alamitos, CA [email protected]

Please provide an e-mail address ordaytime phone number with your letter.

On the Web

Access computer.org/software for informationaboutIEEE Software.

Subscription Change of AddressSend change-of-address requests for magazinesubscriptions to [email protected] sure to specifyIEEESoftware .

Membership Change of AddressSend change-of-address requests for the mem-bership directory to [email protected].

Missing or Damaged CopiesIf you are missing an issue or you receiveda damaged copy, contact [email protected].

Reprints of ArticlesFor price information or to order reprints, sende-mail to [email protected] or fax +1714 821 4010.

Reprint Permission To obtain permission to reprint an article, con-

tact WilliamHagen, IEEE Copyrights and Trade-marks Manager, at [email protected].

How to Reach Us

cobol s defense

Documents