COBOL and the Enterprise Business Programming Paradigm

Back to Blog List

COBOL and the Enterprise Business Programming Paradigm

Like

"Why COBOL"

What do Don Ameche, Wilfred Brimley, Jessica Tandy & COBOL have in common? Next year COBOL turns 60. While not as old as Wilfred, Don & Jessica, “COBOL” calls to mind scenes from the movie “Cocoon”. Ironically – just like the effervescent seniors in "Cocoon" – even at 60 years old The Great Software Lifeguard hasn't called COBOL out of the pool - not by a long shot. From “Exactly what is COBOL and why is COBOL still a widely used language in IT?”

Every year, COBOL (all caps plz) systems are responsible for transporting up to 72,000 shipping containers, caring for 60 million patients, processing and connecting 500 million mobile phone users.

[COBOL] Equates to 80% of the world’s actively used code (> 220,000,000,000 lines)”

200 times as many COBOL transactions take place each day than Google searches

From “COBOL Is Everywhere. Who Will Maintain It?”

About 95 percent of ATM swipes use COBOL code; Reuters

[COBOL] powers 80 percent of in-person transactions; Reuters

Every day, COBOL systems handle $3 trillion in commerce

In 2014, a vice president at Unisys, told American Banker about a government client with an IT worker “who’s on oxygen. He’s 70 years old, he knows the keys to the kingdom, he knows where everything is, it’s all sitting in his head. They send out a police car to pick him up every morning and bring him into work in a vault-like room”

And from “The inevitable return of COBOL”

1,500,000,000 (1.5 Billion) lines of new COBOL written each year

“Four years ago, local Fortune 500 employers encouraged the university to offer Cobol courses. Now, graduates who take Cobol electives earn starting salaries of $75,000 compared to starting salaries of $62,500 for those who did not.”; Wall Street Journal

As taboo as COBOL might be in the ping pong rooms of modern startup-driven culture today, its influence and irreplaceability will result in a spotlight

Besides this stat “As many as 75% of all rewrite projects have resulted in failure” and with the redoubtable Reuters reporting that when Commonwealth Bank of Australia replaced its core COBOL platform in 2012, it took five years —
and cost $749.9 million. Why is it that COBOL still supports large-scale, complex, long-lived business computing? Even more perplexing… how does a 60-year old software language deliver 1.5B new lines of code - on the sorts of complex AppDev requirements endemic to 2019 production enterprise systems?

COBOL and the Realities of Enterprise Business Application Development

In 1958, the first COBOL committee - a group of independent language experts and I/S technicians from industry (finance, manufacturing, retail, etc.) and including computer software vendors, government & academia was convened to blueprint a standard business-oriented computing language. This specification was not a for-profit venture but a solution to the current-day and future business data processing problem space – in other words a COmmon Business Oriented Language. Besides considering what computers were capable of in 1959 the group took into consideration that there are structural, financial, political and technical realities in large-scale, business programming.

Enterprise Business Applications are large, very large and very, very large

- As an example a large American car manufacturer runs 50,000 batch jobs each night
  - Each job consists of between 5 and 20 steps
  - Most steps execute a composite load module consisting of 2 to 200 COBOL programs
- Each COBOL program consists of 1,000 - 20,000 lines of code (go ahead – do the math)

In 2012 the IT group at the Bank of New York Mellon had to tend to 112,500 different COBOL programs — 343 million lines of code,
Computerworld

Enterprise Business Applications are complex

This is a real customer z/OS Application Flowchart

It’s no more than above-average in complexity

Enterprise Business Applications are long-lived

10, 15, 20, 25 and even 30-year-old applications are common

Think of the ROI for the initial dev-cost – amortized over 25 years

Enterprise Business Applications evolve

During the time business applications live in production they grow in complexity, and evolve well beyond the original design and specification requirements

Enterprise Business Applications are critical

- Capacity and throughput is often measured in the millions of transactions and hundreds of millions of records read per/day
  - Applications must be stable even (especially) at high transaction and data access volumes.

If applications ABEND they must be patch-able and re-start-able under duress (often during the wee hours of the morning) – and in a very short time - typically measured in hours

Enterprise Business Applications must integrate with, leverage, and grow with advances in I/T

- Business Computing Architectures and Development Environments evolve and change
  - The 1960s and 1970s saw mainframe operating systems grow from providing only 10K RAM to 16 Megs
  - The early (primarily batch) applications required an almost Assembler-close-to-the metal coding style ... COBOL accommodated this
  - Structured Programming became the darling of the 70’s academics - COBOL provided PERFORM, SCOPE-Terminators, etc.
  - The 1980s begat 4GLs and C.A.S.E. tools – which generated COBOL
  - The 1990s begat Visual Basic & PowerBuilder & other Client Server initiatives – which tried to displace COBOL (where are these usurpers now?)
  - The 2000s begat Java, .Net, SOA/Web Services – which interfaced with Enterprise COBOL
  - The 2010s -> today begat APIs, Micro Services, DevOps – which also interface with and harvest from Enterprise COBOL

Enterprise Business Applications must adapt to the realities of the current business world

Projects are understaffed and developers are overworked

Project teams change

Enterprise Business Applications needs are universal

I/S departments are unique – across the world

COBOL is the universal mainframe programming language – running on almost every mainframe in almost every country around the world.

How COBOL addresses the reality of business application development

After much analysis, research and discussion and unfettered by the need to turn a profit the nonpartisan COBOL committee came up with the first COBOL language standard in 1959 – and the first COBOL spec in 1960.

Over the last 60 years languages have excelled at one or even many of the elements in Figure 1, but COBOL alone underwrites all of them – because it is:

Self-documenting

COBOL is an English, readable, self-documenting programming language. Large, complex, and long-lived application development projects benefit from COBOL's self-documenting syntax and semantics.

Most importantly - maintenance and production support-related tasks benefit, particularly when assigned to developers who were not the original application authors

Tractable

When the first COBOL applications had to be written to run in 10K (early) mainframe regions – COBOL enabled the near-Assembly-language coding style

When MVS opened-up 16 Megs of RAM – COBOL was extended to provide a functional-decomposition or “structured programming” style (PERFORM, Scope Terminators, etc.)

When 3-Tier or N-Tier application architecture was considered preferable – COBOL supported that

When O-O became the dominant software paradigm the ANSI committee grafted O-O constructs into COBOL

COBOL applications can be designed/coded as small, tightly compact structured programs (think Java Micro Services)

And COBOL still runs the colossal production application stacks created in the 70’s 80’s 90’s -
COBOL is nothing if not tractable

Simple

COBOL supports a wide syntax vocabulary – something you’d expect after 60 years of production use. Yet it encourages a simple, uncluttered coding style.

Programmers develop complex applications combining straightforward procedural constructs. They don’t write the kind of impenetrable, terse code you’d find in lengthy-sentence/class-based languages.
This facilitates a readable, maintainable codebase - even if program comments are not F. Scott Fitzgerald-esque.

Lifecycle-Agnostic

Given modern IDEs (IDz/ADFz, z Open DeveloÍpment, etc.) COBOL applications – and all aspects of their project and task work are at home in the SDLC workflow from the 1970’s classic Waterfall to Agile & 2019 DevOps

ADFz & zOpen Development support COBOL application Continual Delivery, providing Unit Test capability and integrating with modern 3rd Party tools like: Git, Jenkins/Jira, Sonar, etc.

Nonproprietary

COBOL is an extremely 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 almost every operating system on almost every hardware platform - x86, Network, mid-range, mainframe - O.S.: Windows, Unix, DOS, AS/400, Linux, VSE, VMS, VM, MVS, z/OS

And file system/DBMS for these platforms

You name it, COBOL's been there, and has run on that.

Efficient

COBOL has a 40-year history of optimizing compiler technology advances - Enough said

Scalable

Through COBOL's availability on all common I/S run-time environments, and through ANSI-Standard CALL USING constructs COBOL applications can scale up with loose or tight coupling - and even O-O message binding with ease.

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,000,000 programmers worldwide are expert in COBOL. COBOL solutions do not require hard-to-find, expensive consultants to develop, maintain and support them.

Through the efforts of the ANSI committee, COBOL programs written in Germany run on mainframes from Delhi to Santa Cruz to Manhattan to Iceland.

IBM told Reuters that
“over the last 12 years they’ve trained more than 180,000 developers through fellowships and other training programs — which averages out to 15,000 a year.”

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 businesses.

Mature

COBOL has upwards of 1,000 3rd-Party products from well over 100 companies boasting well over thirty years of support for the COBOL market.

Products and add-ons 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 computer-software languages combined.

Why COBOL?

Table 1 below describes the COBOL language’s attributes positioned against the realities and requirements of the Business Application Paradigm. COBOL evolved from the business development paradigm, and as a single language is uniquely suited for business application development, maintenance and production support.

This is not to say that COBOL is all you need to create contemporary applications. Nor am I implying that COBOL is best for every class and type of business application.

But if you are developing large, complex, long-lived enterprise production systems, that will be maintained by a heterogenous group of developers 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 accelerates towards warp speed.

Why COBOL? While many of today’s software products languages are sunset in 6, 16, (definitely in 26) or so years, COBOL is all about long-term, enterprise computing ROI. I’ll leave you with a quote from Dave Babson, president of Burl Technologies;
"The new technology providers bash COBOL because they must create a throw away - build from scratch mentality in order for their products to succeed."

COBOL Language Elements and Properties

Business Application Paradigm Realities and Requirements	Self-Documenting	Simple	Portable	Efficient	Scalable	Universal	Open	Complete	Mature	Reliable
Large Applications	x	x	x	x	x	x	x	x	x	x
Complex Applications	x	x	x	x	x	x	x	x	x	x
Long-lived Applications	x	x	x	x	x	x	x	x	x	x
Dynamic Applications	x	x	x	x	x	x	x	x	x	x
Critical Applications	x	x	x	x	x	x	x	x	x	x
Evolving Applications	x	x	x	x	x	x	x	x	x	x
Business-orientation	x	x	x	x	x	x	x	x	x	x
Project understaffing	x	x	x	x	x	x	x	x	x	x
Bell-shaped curve of talent	x	x	x	x	x	x	x	x	x	x
Every shop is unique	x	x	x	x	x	x	x	x	x	x
Maintenance/production supp.	x	x	x	x	x	x	x	x	x	x

Table 1, How the COBOL language properties support the Business Computing Paradigm

Jonathan Sayles, Business Application Developer, IBM/Raleigh,

Mr. Sayles has published 16 books and over 300 technical I/T articles, courses and white-papers on topics such as; RDBMS, Data Modeling, Enterprise Modernization, IBM’s modern IDEs (IDz, ADFz), Traditional IBM languages and development tools, Client/Server development – with tools like: Visual Basic, PowerBuilder, DB2, Oracle, and SQL. He has been editor of the DB2 Journal, and the Relational Database Journal. Mr. Sayles has spoken at IBM, Rational, Fortune 500 company, Powersoft, VBits, IBM, Micro Focus, and DBExpo international conferences, as well as hundreds of regional conferences. As a technical consultant, Mr. Sayles has worked in over 90 of the Fortune 500 shops in the last 30 years of his career.

COBOL - Group home