Getting OpenCobol on Linux working with Firebird’s Cobol gpre.

Issues

First problem, by default, Firebird only comes with the pre-compiler for C/C++ enabled, so we will need to build our own version of Firebird from the source to include Cobol pre-compiler support:

./configure –with-gpre-cobol
make

The build will succeed, but any attempt to link a program that has been pre-compiled will fail because it can’t find the symbol (+ Firebird 2.1) isc_sqlcode_s, which was added for the RM Cobol build. This is fairly easy to solve, just add the symbol to firebird.vers in builds/posix and rebuild to get an updated libfbclient and libfbembed.

The RM Cobol build also added the following symbols which may also be needed at some time:

isc_embed_dsql_length
isc_event_block_a
isc_sqlcode_s
isc_embed_dsql_fetch_a
isc_event_block_s
isc_baddress
isc_baddress_s

Once the build is successful, you can create a tar file install. In gen:

make –B –f Makefile.install tarfile

Then cd to the directory that was used to create it and run:

install.sh

You can now start writing/compiling your Cobol programs:

gpre –cob –ansi simple.ecbl
cobc –x –v –std=cobol85 –lfbembed simple.cbl –o simple

I used libfbembed because it makes life simpler when trying to work out what’s going on. You can also compile using libfbclient.

However when you try and run any of them, you will get the following error (assuming you have added the right error handling code):

invalid request BLR at offset 0,
unsupported BLR version (expected 4, encountered 0)

(blr_version4 for SQL dialect 1, blr_version5 for SQL dialect 3)

The code will typically be failing in isc_compile_request2 because it cannot verify the blr that corresponds to the SQL statements that are compiled into the program as ISC-1 etc as binary longwords in chunks, unlike the C pre-compiler which takes the blr as a string.

After a lot of debugging in the Firebird code PAR_parse, Par_blr, gen_raw etc it became pretty obvious that there was some kind of alignment issue somewhere. At first I thought it was Firebird, but the blr being generated by gpre was correct and was exactly the same on both 32bit and 64bit O/S’s. Eventually it dawned on me that the problem was not Firebird or gpre but something somewhere in how OpenCobol was reading/interpreting the blr.

Some digging through the OpenCobol configuration files produced the following in their default.conf:

# Value: ‘native’, ‘bigendian’
binary-byteorder: bigendian

I assume this is their default install, but its not going to work on an Intel/AMD Linux system. Changing this to:

# Value: ‘native’, ‘bigendian’
binary-byteorder: native

and recompiling produced a different error:

invalid request BLR at offset 12
BLR syntax error: Expected RecordSetExpr at offset 13, encountered 121

Interesting. Now we are getting somewhere. The blr is now being read, even though its not producing what we want.

More examination of the config file showed the following:

# Value: ‘yes’, ‘no’
binary-truncate: yes

Changing this to:

# Value: ‘yes’, ‘no’
binary-truncate: no

Now produces code that works.

*This paper was written by Paul Beach in August 2013, and is copyright IBPhoenix.