COBOL and the Business Programing Paradigm
by Fred Silverberg, Technology Manager, CompuLink, Inc.
The "Contract on COBOL"
Have you gone to a Client/Server or O-O Technology conference...or picked up a computer trade journal lately? If you did, you probably couldn't miss listening to or reading some demeaning, derogatory, and generally malicious remark about the COBOLlanguage, COBOL development culture and COBOL programmers. Yes, it's 1996, and the anti-COBOL extremists are once again on the warpath, with their "new AS improved" (as opposed to the temperate, "new as unproven") line of rhetoric on how to solve I/S's woes. Only this time they're taking no prisoners. They're stating - unequivocally - that COBOL is a computing language whose time has come and (long since) gone. And that I/S's only salvation from COBOL's dank legacy lies in rewriting "ancient and creaky" COBOL applications using modern (alternative) technology. Managers, directors and vice presidents out there should be alert to the implications of this message: "COBOL may be what's always - and is currently - keeping your data center from a procedural meltdown, but you should bet your personal - and the company's - technical and financial fortunes on technologies with little-to-no track record in the production world." They actually expect you to buy into this high-stakes crap shoot. For all the hype you'd think that 95% of the production business applications around the world were written in Smalltalk, C++ and Visual Basic and only 5% were written in COBOL - when in fact, just the opposite is the case.
Adding insult to injury
Not content to stop at burying the language, many alternative-technology-proposers feel compelled to debase COBOL programmers, descending to suggest that they are "dim-wits" all of whom should be replaced by latent college-graduated "software engineers" armed with the latest software fads and silver bullet technologies (usually technologies the proposers just so happen to be vested in). Some have even gone so far as to allege that the reason for past silver bullet technologies failures in the real world has to with dumb-old, incorrigible COBOL programmers getting in the way of progress (remember "new AS improved"). Few have the honesty and candor to admit that silver bullet technologies fail because they lack the bandwidth necessary to cope with the complexities intrinsic to production business requirements, production business capacity and scale. And that silver bullet software is nothing more than a way for vendors - and their venture capitalists - to make a buck.
How does this garbage ever get into print?
Dave Babson, president of Burl Technologies sums it up nicely; "The new technology providers bash COBOL because they must create a throw away - build from scratch mentality in order for their products to succeed." And this new wave of anti-COBOL dogma might seem so much adolescent amusement - even simply ignore-able (remember how early 4GLs/ReportWriters, CASE, AI and Expert Systems, and end-user computing were going to spell the end of COBOL production systems?) were it not so pervasive and completely unchallenged by technicians unwilling to be politically incorrect.
COBOL developers and responsible I/S professionals have to start responding to these absurdities. Otherwise the anti-COBOL alternative-rockers will wind up in control of I/S. Then we'll all be attempting to build enterprise-level business applications with languages that don't scale, using the latest trendy "cool" development software to write unmaintainable code. This I/S version of the near-death experience can be thought of as "Dilbert" made manifest. And this none-too-far-fledged, and fictional scenario of the alternative glass house will do serious damage to business information systems technology - and consequently corporate financials - for years to come. How is it that COBOL-based paradigm is different? Why is it that COBOL is a perfect fit with the needs of business computing and contemporary business application development?
COBOL and the Business Application Paradigm
The first COBOL committee - a group of independent language experts and I/S technicians from all walks of life (many commercial-industry, but also including computer software vendors, government, and university professionals) was convened to design a business oriented computing language that was to become a standard throughout the commercial data processing world. Besides taking into account what computers were capable of - at the time, and what business needed from a general-purpose data processing language, the group took into serious consideration that there are fundamental, critical and non-negotiable realities of business application development. Let us call these realities the "Business Application Paradigm." They are listed below in figure one.
After much analysis, research and discussion, the independent COBOL committee came up with the first COBOL language standard. COBOL was designed to meet both the technical requirements for business processing at the time, and the critical requirements of the Business Application Paradigm. The committee did an excellent job of reconciling the contradictory requirements inherent in Figure 1. Through their intelligence, independence, foresight and hard work, they created a standard, pragmatic general-purpose business-oriented computing language, which over time, has kept production systems - and the businesses they support - operational. Because COBOL as a business computing language is:
Self-documenting
COBOL is far and away the most readable, self-documenting programming language. Large, complex, and long-lived application development projects benefit from COBOL's English-like syntax and semantics. Most importantly - and relatively unheard of outside of the COBOL paradigm - maintenance and production support-related tasks benefit, particularly when done by I/S technicians who are not the original application authors (that would be every shop I've ever consulted in).
Simple
COBOL encourages a simple, straight-forward programming style. Programmers develop complex applications using simple procedural constructs, instead of writing impenetrable, terse code. This facilitates maintainable, production-enabled programs for large, long-lived, dynamic, complex applications.
NonProprietary
COBOL is far and away the most portable language. Because the independent ANSI-COBOL committee legislates non-vendor-specific syntax and semantic standards, COBOL applications can be developed, ported, down-sized, upsized, rehosted, reused and rightsized to every operating system on every hardware platform - PC, Network, mid-range, mainframe, Windows, OS/2, every flavor of Unix, DOS, AS/400, VSE, VMS, VM, MVS, you name it, COBOL's been there, done that.
Efficient
COBOL has a 20 year history of optimizing compiler technology, which by now is sophisticated to the point of object code reengineering for greatest run-time efficiency specific to given hardware platforms.
Scalable
Through vendor-independent CALL USING constructs COBOL applications can scale up with loose or tight coupling - and even O-O message binding. CALL USING allows a COBOL application's functionality and capacity to be expanded at any point in the system, in a controlled, contained, structured and stable way. Complex business data processing activity which is supported by huge COBOL applications (millions of lines of code) is common and maintained through this simple, scalable construct.
Universal
Well over 1,500,000 I/S technicians and programmers worldwide are expert in COBOL. COBOL solutions do not require hard-to-find, expensive consultants to develop, maintain and support them (although lately, with all the fuss and attention paid to non-COBOL technologies, want-ads for COBOL programmers are dramatically on the rise!). Through the efforts of the ANSI committee COBOL programs written in Germany run on mainframes from Deli to Santa Cruz to Manhattan. The COBOL language is a constant from shop-to-shop, from project-to-project.
Open
COBOL integrates and can converse with all other 3GLs (C, PL/I Fortran, etc.) all 4GLs (CA-Eztrieve, FOCUS, Visual Basic, PowerBuilder, Delphi), assembler languages (ALC), pure and hybrid O-O languages (Smalltalk, C++...), API-based technologies (Windows SDK, DCE...), relational (aka Client/Server) DBMSs, non-relational DBMSs (IMS, CA-IDMS, Total), object DBMSs, and all pointer-based and sequential file systems.
Complete
In spite of its simplicity and in addition to its business orientation COBOL is "computationally complete" - and can be used in applications that run the gamut from simple batch reporting to complex transaction and windowed systems across all industries and business and computing requirements.
Mature
COBOL has thousands of 3rd-Party products from hundreds of companies with upwards of thirty years of support for the COBOL market. Hundreds of products exist in the critical areas of application testing, debugging, application analysis, maintenance, production support and code reuse. New COBOL compilers and development tools are announced every quarter.
Reliable and Proven
Perhaps most significantly COBOL is used in more production systems and has a more proven and reliable production history than all other business languages combined.
Why COBOL?
Figure 2 describes the above COBOL attributes positioned against the realities and requirements of the Business Application Paradigm. As figure 2 makes apparent, COBOL evolved from the business development paradigm, and is uniquely suited for business application development, maintenance and production support. COBOL is the one constant that can be depended on to protect your investment in business application development in an age where intemperate change in I/S technology is accelerating towards warp speed.
Is it any wonder that COBOL's death, while anxiously anticipated by vendors wishing to replace the language with their own proprietary wares, is "greatly exaggerated"? Is it any wonder that COBOL is still the "language of choice" for Enterprise application development? Gartner Group August 1995 reports that COBOL is used in over 65% of new application development! The only wonder is that COBOL doesn't dominate the I/S tabloids and conference seminars the way that "flash-in-the-pan" technologies do. It's always best to wait for the shock of the new to wear off. It's the follow-up that shows if a technology has staying power. But then, in an industry exploited by commercialism, and led by individuals who put the self interest of their technical resumes ahead of realistic, financially-responsible day-to-day corporate I/S decisions anything is possible.
COBOL Language Elements and Properties
|
