3 minute read time

AMC Tech Tips: COBOL Conversations

by in Application Modernization & Connectivity

Introduction

Over the last month or so there has been some dramatic questions arising because of challenges faced in New Jersey’s employment COBOL systems. Many of the questions ask quite critically how the state of New Jersey could be still using a sixty-year-old programming language.

A more interesting question is perhaps, why are so many companies in the world still using technology that has been around for so long in so many critical systems, and for so many of the financial calculations our modern world depends on?

Setting the Standard for Design

The originators of COBOL designed the language specifically to process business data, so much so that “Business Oriented” provides the “BO” of the acronym COBOL. Originally conceived in 1959, in 1968 it was standardised by the International Standards Organisation (ISO) with strict, agreed rules as to what the language provided as to features and syntax and as to how it behaved. This standard has gone through a number of revisions with the latest being ISO/IEC 1989:2014.

Being compliant with the ISO standard provides a very high degree of portability and predictability in program operation for organizations who used it to develop systems up to fifty years ago through many changes of hardware and operating systems. The same programs continue to work unchanged. Contrast that with a technology world in which any application may stop working when the operating system rolls forward every few months.

A numbers game

At COBOL’s core was fixed point decimal, rather than binary arithmetic as most other languages are designed best for. Within the COBOL standard, arithmetic is covered in detail and specifically specified and codified such that:

When standard arithmetic is in effect most common arithmetic operations will produce results that are predictable, reasonable, and portable. In this context, portable means that the results will be identical from implementation to implementation. (ISO 2002 COBOL Standard, p. 763)

COBOL supports accuracy to 38 significant digits, either side of the decimal point. Additionally, the standard requires, intermediate results to be calculated as if the compiler were using a “decimal floating point” item with 31-digits of precision and 3-digits of exponent. Avoiding such compounding truncations preserves the accuracy of calculations throughout the scope of the calculation.

The standard requires (amongst others):

  • Equivalent methods of expressing certain arithmetic operations produce the same arithmetic result. Thus, ADD X TO Y GIVING Z is calculated identically to COMPUTE Z = X Y
  • Within an execution of a runtime element, arithmetic statements, arithmetic expressions, the SUM clause, and numeric and integer intrinsic functions will return the same arithmetic results, so long as the value and order of the operands or arguments are the same.
  • If any part of an arithmetic expression is implementor-defined, then the remainder of the arithmetic expression is still evaluated according to the rules defined in the standard
  • Maximum error is bounded by very specific rules for each arithmetic function and with specific direction to both most and least significant digit

While some languages have very recently added support for increased accuracy such as Java’s new Big Decimal class, in my view, they do not match COBOL’s simplicity and ease of use. The maturity of COBOL’s standardisation means that its users have lobbied the vendor community (the likes of IBM, Micro Focus and Fujitsu), to produce a level of accuracy, consistency and portability that the other languages could only dream of.

Strategically Thinking

The decision to continue to use COBOL at its core is a pragmatic one by definition. If a system is currently meeting its company’s requirements, then there is no need for costly change. Basic governance should challenge any other decision. Progressing on from that idea, if components of a company’s system do not meet their requirements, conservative governance should demand a modernisation approach, retaining those components that work for it and either replacing or redeveloping those components that do not. Where COBOL fits into the modernisation story is probably fit for a later discussion, but here’s a recent view from IDC:

AppMod.jpg

Hammering the point home

Carpenters have been building for millennia. Modern carpenters have nail guns, electric saws, and planers to build amazing structures very quickly. In their toolbox you will always find a hammer. Hammers have been in those toolboxes since humans first banged a stake in the ground with a rock. COBOL, a tool that still has its use, is a bit like that …

COBOL’s enduring value is here, while you can learn more about its recent 60th anniversary celebrations here. Why not register for the latest product update webinar here.

Labels:

Mainframe
Cobol Analyzer
Visual COBOL
COBOL