by Paul Beach
For those who don’t know Firebird comes with its own SQL pre-compiler called gpre that supports a number of different languages (C, C++, Cobol, Ada, Fortran, Pascal).
Currently I know users who use the default Cobol implementation, and also one user who uses the RM Cobol variation. In the past there have been discussions (on an OpenCobol forum) about getting Firebird’s gpre working.
http://www.opencobol.org/modules/newbb/viewtopic.php?forum=1&topic_id=159
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.