8 minutes read

COBOL is an old language from 1959, partly based on programming language work by Grace Hopper, with a strong focus on business applications. There are still many COBOL programs running around the globe, mostly in banking, insurance, and governments. Although frequently criticized as a sloppy designed, non-computer-scientific, and a badly structured language in general, COBOL still dominates in many fields that affect our daily lives. For example, when you interact with your bank account there’s almost always some piece of COBOL code quietly working along. When you deal with any kind of “bureaucracy” there’s almost always some complex COBOL-based batch-process that consumes your online documents. When you register a new car, for example, expect some COBOL code to shift numbers around.

However, I’m neither advertising COBOL nor trying to persuade you that we should go back in time and only use procedural programming paradigms to solve our daily problems, far from that. But, knowing COBOL could also be very lucrative as traditional industries usually change very slowly and are ready to pay lots of $$ to folks who can code in it. It’s not a secret that there aren’t that many COBOL developers available for hire, as the older generations retire and inevitably take their knowledge with them. Universities only rarely teach COBOL, because of many reasons (one of them is that COBOL wasn’t designed by computer scientists, so academia simply recognizes it as a “non-compsci language”). So, the shortage is real and the industries I mentioned before won’t convert everything into Java/JVM or .NET/C#, because so many COBOL programs run on mainframes only, which aren’t supported by the so-called modern languages.

The 7zip-file containing the GnuCOBOL environment can be downloaded here.

GnuCOBOL

Although there are several COBOL dialects available most of them are very expensive and not open source. Therefore, we’ll be using GnuCOBOL, a project formerly known as OpenCOBOL. And because the Windows installation is much harder to accomplish than those with Linux & Mac, this article will be focused on Windows only. However, the language itself is OS-independent, so you can use the code examples and compile them under any OS. The sources are hosted at Sourceforge and should be extracted before compilation. There’s also another package with libraries compiled for Windows.: MPIR , ncurses, and VBISAM

I’ve tried to install all of those libraries by following the instructions from project’s Readme, but there were some subtle problems as the libraries seemed to be a bit too old for the current GnuCOBOL sources. My assumption is that they’re for version 1.x only. I’ve also had problems to compile the 64bit version of GnuCOBOL, because the only available version of VBISAM was 32bit. Well, it seemed to me there was only one option left: to compile those libraries manually. But as we all know, compilation of open source libraries under Windows, and especially those from Linux world, often takes many hours of frustration…until one gives up.

So I tried to find their precompiled versions on the net. And after having downloaded several candidates which delivered problematic results (mostly DLL-export problems) I’ve finally found this website that offers several precompiled versions of GnuCOBOL. My next steps were:

build_windows/x64 directory that’s located inside the root of the previously unpacked GnuCOBOL zip-file. I unpacked the lib-files (vbisam, pdcurses, and mpir) from this link intodirectory that’s located inside the root of the previously unpacked GnuCOBOL zip-file.

Then I renamed vbisam.lib into libvbisam.lib , because the Visual Studio project from build_windows/vs2017 expects a library with this name.

The final step was to load the solution file into Visual Studio and build a Release version.

Hint: There’s a chance that you’ll run into a NativeCodeAnalysis error. If this happens, simply open Solution “GnuCOBOL”/Properties per right-click, and change the Code Analysis Settings to C++ Core Check Rules for all projects in the list below.

Then make sure you have selected Release/x64 in the Visual Studio main window.

Now it’s time to build the GnuCOBOL projects in this order.

libsupport libcob cobcrun cobc

The compilation of cobc will take more time than other projects, but in the end you’ll get an output message like this:

Configuration

By default your new COBOL compiler expects to be located under C:\GnuCOBOL. Personally, I don’t like to put my binaries directly under C, so I’ve moved them to C:\bin\GnuCOBOL. However, this can provoke some dire consequences as cobc.exe, the compiler, will still try to reference includes and libraries from the default directory. But before we solve this problem by redefining certain environment variables, we should copy these directories from the source-directory root to C:\bin\GnuCOBOL first:

config

copy

libcob

Then copy all of the include files from build_windows to C:\bin\OpenCOBOL.

Having copied all those files, we can go back to environment settings. Your GnuCOBOL compiler must run within an environment that contains paths to your Visual Studio compiler tool chain. Usually, one could simply execute one of well-known Visual Studio scripts like vcvars64.bat, but luckily, the GnuCOBOL developers have already provided several scripts to instantiate proper environments for compilation. You can find them in the build_windows directory. As long as you execute those scripts to boot Visual Studio environment, everything will run just fine.

The last hurdle is the problem with include & library paths. First, type in cobc.exe –info to get the current information about your compiler’s environment. Below is the output of my local settings, and as you can see there are not only default variables pointing to locations under C:\OpenCOBOL, but also additional variables containing alternative paths. Your goal will be to insert them into your environment as well (of course, if you’re using a different root path, you’ll have to adapt them accordingly).

These are the variables that should be changed:

set COB_CFLAGS=-I “c:\bin\gnucobol\include”

set COB_LDFLAGS=/incremental:no /LIBPATH:”C:\bin\gnucobol\lib”

set COB_CONFIG_DIR=c:\bin\gnucobol\config

set COB_COPY_DIR=c:\bin\gnucobol\copy

Of course it’d be much better to set them permanently. For this, just call the menu System/Envronment Variables, and insert them one by one.

Compiling HelloWorld

Although I’m not aiming to teach COBOL syntax in this article, we should at least be able to compile the traditional HelloWorld program. If for nothing else, then just to show you a few important details that come to light when one starts writing COBOL source codes. For example, COBOL treats spaces & tabs very differently, so expect to run into weird errors. Also, the overall formatting of COBOL sources follows some strict rules, like leaving the first seven fields empty, in every line. This is called the Fixed Format Mode. But you can activate Free Format Mode by appending the -F flag or by inserting >>SOURCE FORMAT FREE in the source code header (don’t forget the correct spacing!).

The leading numbers are optional in modern COBOL versions. You can use spaces instead.

To compile the source we call cobc.exe with these options:

cobc -x hello.cob -o hello.exe -std=cobol85

To get a more detailed output, and potential error messages, you should append -W and -v. Then the output would look like this:

As you can see, GnuCOBOL uses the MSVC compiler & linker as backend to generate executable files. This is the reason we must provide proper MSVC tool chain paths.

Our little hello.cob source was completed successfully. The only thing that’s left is to call it from the console.

Utilizing the Win32 API

With GnuCOBOL we can also compile programs linked with Win32-libraries. In the example below we CALL a public Win32 function MessageBoxA to display text in a message box.

The compilation command contains some new flags:

cobc -x hellow.cob -W -fstatic -l User32

-fstatic enforces static generation of all external calls as static.

-l links the program with the given library (without extension). In our case we had to link with User32.lib because the MessageBox functionality is located in User32.dll.

After the compilation we call our little program with hellow.exe.

Now, the hard part is to learn COBOL. But luckily, there are several easy-to-read docs provided by the GnuCOBOL project itself.

Have fun with COBOL. 🙂