Introduction

Is Zombie COBOL the name of a retro punk band, or a reality check? Contrary to popular belief, COBOL is not dead and it may never die. 

According to a 2022 report commissioned by Micro Focus, there are between 775-850 billion lines of COBOL code in daily use. In 2017, Reuters reported that 43% of banks use COBOL and 95% of ATMS use COBOL.  COBOL is still in use in many federal agencies according to congressional testimony in 2016.

This blog covers the following topics based on my experiences with COBOL:

• Where I have used COBOL
• Why I used to hate COBOL
• Why I now respect COBOL
• Why I wrote this blog
• What is GnuCOBOL
• Using GnuCOBOL on s390x, x8664 and ARM64
• Why I find GnuCOBOL interesting
• The future of COBOL

 

 

Where I have used COBOL

Over the years, I have used COBOL on PCs, Mini-computers, Unix servers, IBM mainframes and most recently in public clouds.

In those envrionments, I have used various different COBOL compilers:

• DEC VAX COBOL
• Ryan McFarland RM/COBOL-85
• IBM COBOL/2
• IBM ILE COBOL
• Microsoft COBOL
• Fujitsu COBOL
• Fujitsu NetCOBOL
• Merant Server Express
• Micro Focus COBOL
• Micro Focus Object COBOL
• Micro Focus Server Express
• Micro Focus Net Express
• Mico Focus Visual COBOL
• GnuCOBOL

 

Why I used to hate COBOL

In 1989, I used Turbo Pascal for DOS on my PC and life was simple. The Turbo Pascal compiler was fast, the IDE was fast and ‘simple to use’, so you could just get on with creating executables and libraries.

 

 

In 1990, I learned COBOL-77 and COBOL-85, having already completed two years of computer science with Pascal, C and C++.  At the time, I had strong views on computer language syntax, code structure, compilers and development environments.  Given this limited / idealistic experience, at the time I thought that COBOL and its development environments were a step backwards.

 

Apart from my ‘What I hated about COBOL-74’ issues, I was also never learned to love JCL, data sets, or TSO. This was all very subjective, but I know what I like and dislike.

 

 

Why I now respect COBOL

The COBOL language has stood the test of time.

In 2022, after 62 years, the global COBOL production code base appears to still be growing.

Apart from life experiences writing and maintaining code [+ a grey beard], the COBOL language has continued to improve.

 

ANSI / ISO COBOL-85 allows things like

• More structured code via things like END-IF, END-PERFORM and nested subprograms
• New keywords for CONTINUE, EVALUATE and INITIALIZE 

 

ANSI / ISO COBOL-2002 allows things like:

• Free-form code, finally breaking free from those punch card input layouts 😉
• User defined functions
• Unicode and locale based processing
• Pointers and allocating/freeing memory
• Object Oriented COBOL

 

ANSI / ISO COBOL-2014 allows things like:

• IEEE 754 data types
• Method overloading

 

However, the reality is the subset of the COBOL standard that your COBOL compiler supports 😉

 

Some lessons learnt

I used to be bothered that COBOL did not allow free form code based only on syntax rather than location + syntax.  Given the lack of standardization for things like code indentadation in C, C++, Java, JavaScript, Python, Go and Rust, the traditional ‘fixed form’ COBOL layout for comments and groups is probably a good thing.

I used to be bothered that COBOL did not support pointers and dynamic memory allocation like C or C++.  Given that COBOL-2002 has supported pointers and dynamic memory allocation for 20 years, I find it amusing that I have never felt the need to use it.

I used to passionately believe that object orientated programming was the one true way to design and write code. I have never felt the urge to write an object oriented COBOL-2002 program.

Maintainable code is more about project scope, good design, structured code, meaningful identifiers & comments than about the choice of language or syntax. You can easily write un-maintable code in Java, JavaScript, C, C++, Python, Rust and Go.

Strongly typed languages like COBOL enable well designed programs to live in production for many decades.  Dynamically typed languages like Python and JavaScript enable rapid development, but most of these programs are not expected to work unchanged in production for many years.

Apart from environmental things (like operating systems, editors, compilers and linkers), one of the strengths of COBOL is that it is simple to learn and a great fit for batch processing and online transaction proessing.

 

 

Why I wrote this blog

I never planned to write this blog:

• I was just testing Oracle 19c Pro*COBOL on Linux (x8664, ARM64 and s390x) and something un-expected happened
• While waiting to get my Micro Focus Visual COBOL license, I decided to try GnuCOBOL
  • GnuCOBOL is not a supported COBOL compiler for Oracle Pro*COBOL [but it works]
  • GnuCOBOL is not a supported COBOL compiler for anything, it is open source software
    • If you ask nicely on the forum or log a ticket, the GnuCOBOL community may implement your feature of fix bugs
  • It is always pleasant when you expect something to be difficult and it just works
    • I got the same funcional results with GnuCOBOL 3.1.2 as I did with Micro Focus Visual 6.0 COBOL
• Mirco Focus Visual COBOL 6.0 is the supported COBOL compiler for the Oracle 19c Pro*COBOL pre-compiler for Linux
• Micro Focus has great COBOL compilers which I have used in the past on Windows, Solaris, HP-UX and Linux

 

I had a revelation – using GnuCOBOL 3.1.2 on Linux [s390x, x8664 and ARM64] with Vim or VS Code was like using Turbo Pascal back in the day:

• Really fast compiler
• Simple & fast code editors
• Your programs run really fast
• You are able to do things your way rather than how the editor + compiler + linker want you to do things

 

So I decided to write this blog as I found that using GnuCOBOL with Vim and VS code on many different platforms was a pleasure rather than a chore.

 

 

What is GnuCOBOL

• I have used the Gnu Compiler Collection [gcc] for well over twenty years [mostly C and C++]
• The Gnu compiler collection has language specific front ends [eg C, C++, Objective-C, Fortran, Ada, Go and D] for parsing and semantic analysis and a common backend for optimization and code generation
• This meant that I trusted the functionality, quality and performance of the Gnu family of compilers

I thought that I would try GnuCOBOL as it is free, just to see what it was like:

• GnuCOBOL has been in development for 20 years. It started with OpenCOBOL in 2002 and became a Gnu project in 2013
• GnuCOBOL supports many popular COBOL compiler dialects
• GnuCOBOL implements many features of COBOL-74, COBOL-85, COBOL-2002, COBOL-2014 and COBOL-202x
• GnuCOBOL does not claim NIST conformance, but it worked for all the NIST and Oracle Pro*COBOL tests that I tried
• GnuCOBOL also includes a report writer and screen section
• GnoCOBOL supports source level debugging
• GnuCOBOL depends on the Gnu C compiler tool chain [gcc] that I am familiar with
• GnuCOBOL supports many operating systems

 

 

Using GnuCOBOL on s390x, x8664 and ARM64

• I wanted to test GnuCOBOL on an IBM mainframe, four flavors of Linux, four public clouds and on some local Linux machines
• The following is a subset of all of the above GnuCOBOL operating systems, but testing takes time and you need to start somewhere

I started with IBM LinuxONE on an IBM mainframe, so I needed to be able to create s390x Linux COBOL executables and shared libraries.

A quick Google seach gave the following suggestion for using GnuCOBOL on IBM LinuxONE with Red Hat Enterprise Linux 8:

 

The above commands downloaded some Linux packages, built GnuCOBOL from source, ran some tests and installed the compiler on the mainframe in less than five minutes!

 

Time to try a trivial Hello World program with GnuCOBOL on IBM LinuxONE

 

The above screen shot shows

• The source code to hello.cob using COBOL-2002
• Building an executable program using free format COBOL and lower case syntax
• Running the hello program
• That the hello program is built as an IBM s390x executable with MSB [most significant bit – for internal number storage]

You can choose the compiler dialect, eg COBOL-85, mvs-strict, or COBOL-2002 like the above hello.cob program.

 

I repeated the above [with package manager tweaks from the Google search] and it just worked on:

• SUSE Enterprise Linux 15 SP3 on IBM LinuxONE [s390x]
• Ubuntu 20.04 on IBM LinuxONE [s390x]
• Ubuntu 20.04 on AWS [x8664 and ARM64]
• Ubuntu 20.04 on Azure [x8664]
• Oracle Linux 8.5 on Oracle Cloud [x8664 and ARM64]
• Oracle Linux 8.4 on a local machine [x8664]

 

Using the free Vim and VS Code editors with GnuCOBOL

My Linux Vim editor provided color coded systax highlighting for COBOL:

 

I installed several different COBOL specific extensions on VS Code:

• The free IBM Z Open Editor extension
• The free Micro Focus COBOL extension
• The free Broadcom COBOL language support extension
• The free Broadcom COBOL Control Flow extension
• The free Broadcom Code4z extension
• The free COBOL Essentials extension by Jim Nolan

 

VS Code is a very popular, free, generic code editor for Windows, macOS & Linux with extensions for almost all computer languages and tools.

 

 

Next Steps

• My functional tests for Oracle 19c Pro*COBOL all worked using GnuCOBOL 3.1.2 and the Oracle 19c Instant Client
• I plan to do performance and stress tests

 

 

 

Why I find GnuCOBOL interesting

GnuCOBOL enables the following:

• Young developers to learn COBOL for free using the tools that they are familiar with [eg Linux, Vim or VS Code, with gcc or Clang LLVM]
  • I learnt COBOL on free / slow / hamstrung COBOL compilers on PCs and even slower DEC VAX mini computers
    • It was not a good first impression for COBOL
  • GnuCOBOL is free, fast and has no built in limits, unlike most other free COBOL compilers
    • Using GnuCOBOL with VS Code on Linux is pretty good
• Testing COBOL programs for many different COBOL dialects
  • cobol85, cobol2002 or cobol2014
  • mvs or mvs-strict
  • ibm or ibm-strict
  • mf or mf-strict
  • rm or rm-strict
  • bs2000 or bs2000-strick
  • xopen
  • default
• Testing COBOL programs on different operating systems
  • Linux s390x [on IBM LinuxONE or Linux for zOS]
  • Linux x8664 [in your data center, AWS, Azure or Oracle Cloud]
  • Linux ARM64 [in your data center, AWS, Azure or Oracle Cloud]
  • IBM zOS
  • IBM System i
  • Microsoft Windows
  • Apple macOS
• Potentially used as a production COBOL compiler
  • Some companies use GnuCOBOL in production
  • For COBOL applications ported to Linux, GnuCOBOL is a credible compiler
  • For COBOL applications on a mainframe, is a free compiler worth the cost / risk ?
• Simple integration with C programs and libraries
• A compiler that is ‘future proof’
  • By separating the COBOL compiler into a frontend + backend
    • The frontend does syntax and semantic analysis, and then translates valid COBOL into C code
      • This allows GnuCOBOL to focus on supporting COBOL standards and dialects independent of the target architecture and operating system
    • The backend uses the existing / mature gcc or Clang LLVM tool chains for compilation, linking and [feedback directed] optimization
      • gcc and Clang LLVM will continue to support more architectures, operating system and optimizations
      • You can easily see the generted C code, assembly code or object files
      • You can easily generate shared libraries
      • You can easily link many COBOL and C object files
      • You can use gdb for source debugging
      • You can use VS Code for remote source code debugging
      • You can use valgrind to check for runtime issues

 

 

The future of COBOL

• Technically, COBOL may get to live forever as COBOL has such a huge installed code base + IBM keep improving their mainframes [eg z16 with zOS, LinuxONE and the Telum processor]
• While COBOL as a language may never die, old COBOL programmers do retire and will eventually die
• To be able to maintain and extend the existing COBOL code base, younger developers need to want to learn COBOL
  • Being able to use IBM mainframes for free on the IBM LinuxONE Community Cloud is a good first step
  • Having great free COBOL compilers and editors that young developers are familiar with are also necessary
  • Maybe GnuCOBOL + Vim or VS Code are those great free tools?

 

 

Disclaimer: These are my personal thoughts and do not represent Oracle’s official viewpoint in any way, shape, or form.