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

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.
Thanks for the tip, I’ll give that a try.
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?
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?