Up And Running With COBOL

In keeping with the current theme of Mainframe programming, I’ve decided to go one step further and learn COBOL as well.

Being a half century old Mainframe programming language, up to date COBOL information isn’t around every digital corner of the Internet, and coupled with me using CentOS (probably), I’ve had to set up my environment manually.

Grab a copy of GNUCobol and untar it

$ tar xJf gnucobol-3.0-rc1.tar.xz
$ cd gnucobol-3.0-rc1

Standard Linux software compilation process applies here

$ ./configure && make && sudo make install

Provided all the dependencies are satisfied, this should compile with no problems, I had to install two additional packages with yum, but otherwise it took about 30 seconds to compile and install the whole thing.

As you would expect, the default install is /usr/local/bin/cobc, but there was one small hiccup that took some Googling to figure out. After compiling your first COBOL program (coming up next) you will likely get the following error

./hello: error while loading shared libraries: libcob.so.4: cannot open shared object file: No such file or directory

This was annoying. Fortunately, it was easy to fix.

$ sudo vim /etc/ld.so.conf.d/gnu-cobol-3.0.conf
/usr/local/lib

$ sudo ldconfig

I use Visual Studio Code for most of my development work at the moment, and to my surprise, there’s COBOL packages in the marketplace ready to be installed, which help with syntax highlighing and code formatting.

$ touch hello.cob
$ code .

My first COBOL program is the much loved Hello World:

IDENTIFICATION DIVISION.
PROGRAM-ID. HELLO.
PROCEDURE DIVISION.
DISPLAY "Hello World".
STOP RUN.

Make sure this lines up in the correct column (one tab worked)

$ cobc -x hello.cob
$ ./hello
Hello World

4 thoughts on “Up And Running With COBOL

  1. I had the same problem with libcob.so.4 but rather than edit a file I just did this:

    $ ldconfig

    and it updated the library cache and worked fine after that.

  2. I tried running ldconfig and got this:

    /sbin/ldconfig.real: /usr/lib/fieldworks/libicutest.so.54 is not a symbolic link

    /sbin/ldconfig.real: /usr/lib/fieldworks/libiculx.so.54 is not a symbolic link

    /sbin/ldconfig.real: /usr/lib/fieldworks/libicuio.so.54 is not a symbolic link

    /sbin/ldconfig.real: /usr/lib/fieldworks/libicuuc.so.54 is not a symbolic link

    /sbin/ldconfig.real: /usr/lib/fieldworks/libicule.so.54 is not a symbolic link

    /sbin/ldconfig.real: /usr/lib/fieldworks/libicutu.so.54 is not a symbolic link

    /sbin/ldconfig.real: /usr/lib/fieldworks/libicudata.so.54 is not a symbolic link

    /sbin/ldconfig.real: /usr/lib/fieldworks/libicui18n.so.54 is not a symbolic link

    /sbin/ldconfig.real: Can’t create temporary cache file /etc/ld.so.cache~: Permission denied

    What am I missing?

    1. Hi Dan,
      Sorry you’re having issues. Looks like the problem is related to the Fieldworks application, not specifically gnucobol. LibICU is a library for Unicode support, but without knowing more about your environment it’s difficult to suggest a solution. LibICU is in the CentOS yum repositories, so you could try reinstalling, or try reinstalling Fieldworks. Did you run ldconfig as the root user or with sudo?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.