I was recently asked about the direction of COBOL and whether or not I believed the language would continue for very much longer. To say I was taken aback by the question would be a serious understatement! I pointed the person to an article I did last year about COBOL not only being everywhere but what it could do. The article was titled “COBOL: It’s everywhere” and can be found at http://www.c-sharpcorner.com/UploadFile/RSM50/EVRYWHR09032009152715PM/EVRYWHR.aspx . Now maybe I’m being rather naïve, but really why wouldn’t COBOL not only continue but grow and adapt? All one has to do is to take a serious historical perspective of the COBOL language and one can see not only continuous enhancements to the language, but continual expansion of the language. Let’s take a quick historical review of COBOL, shall we?
Yes COBOL is old. It’s over 50 years old already. In most cases it’s been around longer than most of the developers working in a given shop. Just because something is old though doesn’t mean it’s still not useful and serving a purpose. We’ve heard the examples before, “Have a credit card?”, “Use a cell phone?”, “Have a house mortgage?”, “Pay income taxes?”… all and many more examples are being ran by COBOL systems in some point in time. Micro Focus asked a reporter once to live a single day without interacting in some manner, shape or form with COBOL and it couldn’t be done. So it may be old, but it’s also very wide-spread and serving us day in and day out without any recognition. Now let’s look at how COBOL has grown through the years.
Even though COBOL is old, it has not stopped learning. COBOL has gone through a number of revisions. To set the baseline let’s take a brief look at each of the versions of COBOL and identify the key contributions made to the language starting with ANS COBOL 68 (yes that’s 1968).
- ANSI COBOL 1968 In December 1960 a COBOL program was successfully compiled and executed on two different platforms without requiring any code changes. This demonstrated the concept of compatibility to the early pioneers and the need to ensure the language remained consistent across multiple vendors. During the course of the next several years however compatibility suffered. The American National Standard Institute (ANSI) set about the task of re-establishing compatibility. COBOL 68 was the first ‘official’ release of the language.
- ANSI COBOL 1974 This version was considered by many to re-emphasize the need for compatibility. It contained a number of features that were not in the original version.
- ANSI COBOL 1985 Another revision of the original version with new features. One of the most important was the introduction of structured constructs. This included the inclusion of scope-terminators such as ‘END-READ’ and ‘END-IF’ to name two. This release was geared towards standardized coding techniques.
- ANSI COBOL 2002 A significant enhancement of the language was accomplished with the 2002 release of the language. Several of the key concepts introduced included National Language support including support for the Unicode character set, user-defined functions, calling conventions to and from non-COBOL languages, framework support (.NET and Java), floating-point, and XML generation and parsing. One would characterize this release as geared towards interoperability.
Let’s look at the above information in a different perspective. The different versions of the language are presented with the key object each version achieved:
ANSI 1968: Language Standardization
ANSI 1974: Language expansion
ANSI 1985: Technique standardization
ANSI 2002: Interoperability
From this we see a progression of maturity in the language beginning with defining a standard manner in which to communicate, to growing in capabilities and finally to enabling communications with others. A logical progression and growth enabling COBOL to become capable of achieving many more tasks than ever imagined by its creators. But yet the perception exists that COBOL can’t do anything more than add numbers together. But what about the question posed earlier, “Will COBOL be around for very much longer?” Well the NEXT standard has been in development for a while and is due to be released for public comment in August 2010.
The next standards goals are to continue to expand the capabilities of the language while making it able to interact with the other languages of the day. To that end the following are being proposed for inclusion in the standard
— Dynamic-capacity tables
— Function pointers
— Any-length elementary items
— Increased size limit on nonnumeric literals
— Enhanced locale support in functions
— Support for industry standard floating-point formats and arithmetic, including multiple rounding options
— Structured constants
— Enhanced date and time handling
— Parametric polymorphism, also known as method overloading
If you’d like to follow the process of the standard you can visit http://www.cobolstandard.info/j4/ . We as COBOL developers should be aware of the changes being proposed to the language we work with on a daily basis so that we may be able to adapt our techniques to take advantage of the new constructs in our toolbox.
What has to happen though is for the development community world-wide to realize what a valuable asset it has in all this COBOL code floating around the world and what a versatile language COBOL really is. Companies have invested billions of dollars in these systems. They’ve spent years tweaking, tuning, refining the logic to do just what they need. Then someone says “COBOL ain’t cool” and they look at getting rid of it. Why? We can interact with COBOL in ways unheard of before with .NET being a primary example. Let’s wake up and realize the enormous economic investment that has been made of COBOL and instead of trying to replace it, let’s help make it do even more. Look at new platforms for performance gains, look at new frameworks such as .NET for interaction but let COBOL keep doing the job it’s been designed for…making money! Will COBOL be around for another 50 years? Time will tell but with its demonstrated ability to grow, adapt and expand I would bet on it.
Let’s hear what you have to say. Do you code COBOL? Does your company have applications written in COBOL? How are you using it? Are you looking to expand it? Have you or your company considered expanding what COBOL can do to achieve business success?