Question, it doesn't appear that the precompiler generates the call to the run time using CALL STDCALL literal format. Or CALL ESQLAPI literal where CALL-CONVENTION 64 ESQLAPI would also work.
This might explain why it doesn work with MinGW. Also right now MinGW appears to be having issues with both of the above call conventions.
Just a thought, it might be worth researching.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just got a chance to setup an environment to test GnuCobol (v3.1.2) + MariaDB + MariaDB ODBC Connector + ESQL (esqlOC v 3.0). I have this all running on Ubuntu Server 22.04. My problem is as shown below, module "OCSQL" could not be found. I am using the sample source provided above "esqlOCGetStart1" with database credentials changed to be able to connect to the "test" database.
jack-daniels@devshed:~/cobol/src$ esqlOC esqlOCGetStart1.cbl
esqlOC: ESQL for GnuCOBOL/OpenCOBOL Version 3 (2022.01.03) Build May 19 2022
My preferred way of solving this is to have COB_PRELOAD=libocsql and include its path (or a place where a symlink to it is) to COB_LIBRARY_PATH.
The other option is to link it in during compilation, in this case you'd likely need the no-as-needed option (see the FAQ).
Note: when testing ESQL precompilers I can encourage you to also test with GixSQL (either using its ODBC driver or in this case possibly better, the MySQL one). Using the exact same approach as you had before this would the say GixSQLSomething not found - the solution is the same.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just to share, the "ldconfig -p | grep libcosql" shows that "libocsql.so" is readily available and can be found in the ld cache, correctly defining its location:
It took a couple of minutes getting acquainted with the GnuCobol directory structure and included configuration files.
I think this should be included and mentioned in the "INSTALL" instructions or on the Sample Page of "esqlOCGetStart1"of Esql as an alternative way to set the environment using GnuCobol's included configuration files "runtime.cfg"
It would help a lot of future / interested users looking to utilize Esql or GixSQL.
Very nice!!! 🙂
Thank you so much.
Ron A.
mod edit for some reply-to
Last edit: Brian Tiffin 2022-05-22
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Note: while both esqlOC and GixSQL are "targeted" primarily to GnuCOBOL they also work fine with other compilers.
And sorry that I've forgot the "obvious" most easy option for esqlOC: just symlink lobocesql.so to wherever your binaries are as OCESQL.so - then the CALL will work fine (as long as ldd OCESQL.so does not return an error. No need for any "special" setup or compilation.
For GixSQL it seems you have to add two symlinks for all scenarios - one to GIXSQLConnect.so and one to GIXSQLStartSQL.so; or - one to GixSQL.so and then adding GixSQL to COB_PRE_LOAD - doing so may also be useful for OCESQL as pre-loaded entries are never internally CANCELed.
Last edit: Simon Sobisch 2022-05-22
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for clarifying that I could have just created a symlink. And thank you for your patience as I am an old fart getting back into Cobol where I never really had to deal with installing dependencies, building compilers , pre-processors, and setting up environments before, back then we just wrote code, ran and debugged, to get things going.
I tested the just symlink to where my binaries are, and works as you have indicated. But the cleaner way is as you have suggested. I've created an OCSQL.so symlink in '/usr/local/lib' and revised the 'runtime.cfg' adding OCSQL.so to COB_PRE_LOAD, and everything works and is fine and dandy.
Many thanks again for getting me up and running with a good start on my setup.
Ron A.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I copied and then saved it as Word then saved it as PDF and the parts that scroll are just catenated onto the next line. So all the data appears to be there...
I continue with the conversion from MF to GNU.
Once the data has been passed and trying to keep it updated, it seems that BDB works better than VBISAM.
I'm preparing a full suite of tests.
As I intend to switch to SQL, I have been testing esqlOC, the version is:
esqlOC: ESQL for GnuCOBOL/OpenCOBOL Version 3 (2022.01.15) Build Jan 4 2022.
In the first data passes of a file of 1,423,165 records, it records 1,140,245.
It fails silently and seems to generally leave logs that have special characters.
Does anyone have any clues?
👍
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have tried the same data from MySQL cli and the error Incorrect string value: '\x82s. What...' for column 'descrip' at row xx, it's because the original data is in CP850 latin1 and MySQL doesn't seem to like it.
The problem that worries me is that esqlOC fails silently, which makes me question the reliability of the driver.
Can anyone report experiences on existing precompilers for GNUCOBOL?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Standard EXEC SQL will setup return codes in the variables defined in the SQLCA structure, furthermost SQLCODE. Commonly that's in an SQLCA copybook, but with esqlOC that gets generated into the programs.
You can either manually check SQLCODE or use EXEC SQL WHENEVER to code it at a single place.
You can get more information via SQLSTATE and SQLERRMC (1:SQLERRML) (if it isn't zero).
This also applies to other EXEC SQL preprocessors (including GixSQL, OPEN-COBOL-ESQL, the DB2 preprocessor or pro*cob).
Additional from those standard error handling for EXEC SQL, you can use OCSQL_LOGLEVEL to log communication and errors outside of the application.
If you're interested to know how SQLCODE and SQLSTATE are set, then the beauty of free software applies - just search for those in the esqloc runtime library code.
If you have any suggestions how to adjust them: please do so (but obviously it has to follow standard EXEC SQL practice).
Last edit: Simon Sobisch 2023-12-04
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for your help
I'm going to study the instructions and try esqlOC.
I have downloaded GixSQL but it seems complicated to install since it does not respond to ./configure, make etc and I do not see clear instructions.
You also comment that the errors will be the same in all of them.
I'm going to go deeper because it seems "obvious" that the default configuration should transfer "all" the errors from the D.B. to the user program.
Thanks again
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Values returned in all erroneous records PART-KEY=XXXXXXXXX, SQLSTATE=00000, SQLCODE=+0000000000, SQLERRML+00000, SQLERRML WARNING
In none of the variables you mention does it return values other than zero.
What am I missing?
Thank you
Last edit: Simon Sobisch 2023-12-04
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dear Simon
I'm looking at ocsql2's prnerr function.
I think that simply always returning the value of err to OC_SQLCODE whenever err != 0, would return the error to the program that returned the handler.
Then in the COBOL program you can handle the Error codes according to your convenience.
Why pass some yes and others no?
Why report errors in standard error and variables?
Also, according to the level of OCSQL_LOGLEVEL, it uses 1,9,190,901 as levels that I have not been able to make sense of.
I think it is very difficult to manage from the COBOL program as it is proposed.
Passing the value of err to OC_SQLCODE simplifies everything and leaves the error handling to the COBOL program.
The COBOL programmer is supposed to know what he is doing and when he receives the error he will handle it.
Greetings
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
All errors should be passed - with an appropriate sqlcode.
Why report errors in standard error and variables?
Because that's how EXEC SQL is supposed to work. Ideally: even when switching the EXEC SQL preprocessor and/or database your programs can nearly be used without adjustments needed because of this standard handling.
Also, according to the level of OCSQL_LOGLEVEL, it uses 1,9,190,901 as levels
yes, a lower active level means "print what is higher". prnerr() uses 190 so just set it to this value and run with some sample data, this should show us what's happening.
Note: that function is always called when the DB says "there's a problem" or "there's some information" - so errors and warnings reported by the DB should land there.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Question, it doesn't appear that the precompiler generates the call to the run time using CALL STDCALL literal format. Or CALL ESQLAPI literal where CALL-CONVENTION 64 ESQLAPI would also work.
This might explain why it doesn work with MinGW. Also right now MinGW appears to be having issues with both of the above call conventions.
Just a thought, it might be worth researching.
Hi all,
Just got a chance to setup an environment to test GnuCobol (v3.1.2) + MariaDB + MariaDB ODBC Connector + ESQL (esqlOC v 3.0). I have this all running on Ubuntu Server 22.04. My problem is as shown below, module "OCSQL" could not be found. I am using the sample source provided above "esqlOCGetStart1" with database credentials changed to be able to connect to the "test" database.
jack-daniels@devshed:~/cobol/src$ esqlOC esqlOCGetStart1.cbl
esqlOC: ESQL for GnuCOBOL/OpenCOBOL Version 3 (2022.01.03) Build May 19 2022
jack-daniels@devshed:~/cobol/src$ cobc -fixed -x -o esqlOCGetStart1 esqlOCGetStart1.cob
jack-daniels@devshed:~/cobol/src$ ./esqlOCGetStart1
libcob: error: module 'OCSQL' not found
"libocsql.so" is located in "/usr/local/lib" on my system, and even tried including that path at compile time, with no luck.
I haven't been able to find any similar documentation on a solution.
Any help that would shed some light would be greatly appreciated.
Ron A.
When installed all that, did you then run sudo ldconfig
mod edit to remove some reply-to
Last edit: Brian Tiffin 2022-05-22
I'm pretty sure I did a "ldconfig", just to check:
I did a "ldconfig -p | grep libocsql" to see if the lib was in the cache:
jack-daniels@devshed:~/cobol/src$ ldconfig -p | grep libocsql
libocsql.so.2 (libc6,x86-64) => /usr/local/lib/libocsql.so.2
libocsql.so (libc6,x86-64) => /usr/local/lib/libocsql.so
and it successfully locates it.
Should I be doing something else?
Ron A.
mod edit to remove some reply-to
Last edit: Brian Tiffin 2022-05-22
My preferred way of solving this is to have COB_PRELOAD=libocsql and include its path (or a place where a symlink to it is) to COB_LIBRARY_PATH.
The other option is to link it in during compilation, in this case you'd likely need the no-as-needed option (see the FAQ).
Note: when testing ESQL precompilers I can encourage you to also test with GixSQL (either using its ODBC driver or in this case possibly better, the MySQL one). Using the exact same approach as you had before this would the say GixSQLSomething not found - the solution is the same.
Thank you, I will try your suggestions.
Just to share, the "ldconfig -p | grep libcosql" shows that "libocsql.so" is readily available and can be found in the ld cache, correctly defining its location:
Esql:
jack-daniels@devshed:~/cobol/src$ ldconfig -p | grep libocsql
libocsql.so.2 (libc6,x86-64) => /usr/local/lib/libocsql.so.2
libocsql.so (libc6,x86-64) => /usr/local/lib/libocsql.so
GnuCobol:
jack-daniels@devshed:~/cobol/src$ ldconfig -p | grep libcob
libcob.so.4 (libc6,x86-64) => /usr/local/lib/libcob.so.4
libcob.so (libc6,x86-64) => /usr/local/lib/libcob.so
But I will still try your suggestion in explicitly linking it at compilation.
Thank you.
Ron A.
mod edit to remove some reply-to
Last edit: Brian Tiffin 2022-05-22
Thank you so much! 🙂
It took a couple of minutes getting acquainted with the GnuCobol directory structure and included configuration files.
I think this should be included and mentioned in the "INSTALL" instructions or on the Sample Page of "esqlOCGetStart1"of Esql as an alternative way to set the environment using GnuCobol's included configuration files "runtime.cfg"
It would help a lot of future / interested users looking to utilize Esql or GixSQL.
Very nice!!! 🙂
Thank you so much.
Ron A.
mod edit for some reply-to
Last edit: Brian Tiffin 2022-05-22
@ron5150 What exactly do you suggest to document?
Note: while both esqlOC and GixSQL are "targeted" primarily to GnuCOBOL they also work fine with other compilers.
And sorry that I've forgot the "obvious" most easy option for esqlOC: just symlink lobocesql.so to wherever your binaries are as OCESQL.so - then the
CALLwill work fine (as long asldd OCESQL.sodoes not return an error. No need for any "special" setup or compilation.For GixSQL it seems you have to add two symlinks for all scenarios - one to GIXSQLConnect.so and one to GIXSQLStartSQL.so; or - one to GixSQL.so and then adding GixSQL to
COB_PRE_LOAD- doing so may also be useful for OCESQL as pre-loaded entries are never internallyCANCELed.Last edit: Simon Sobisch 2022-05-22
Hi Simon,
Thank you for clarifying that I could have just created a symlink. And thank you for your patience as I am an old fart getting back into Cobol where I never really had to deal with installing dependencies, building compilers , pre-processors, and setting up environments before, back then we just wrote code, ran and debugged, to get things going.
I tested the just symlink to where my binaries are, and works as you have indicated. But the cleaner way is as you have suggested. I've created an OCSQL.so symlink in '/usr/local/lib' and revised the 'runtime.cfg' adding OCSQL.so to COB_PRE_LOAD, and everything works and is fine and dandy.
Many thanks again for getting me up and running with a good start on my setup.
Ron A.
Hi All!
I am trying to print this whole topic to a PDF file to include the program segments that scroll. Is there a way?
I am starting to work with SQL and wanted to this as a starting point.
Any help would be very much appreciated.
Rich Di Iulio
I copied and then saved it as Word then saved it as PDF and the parts that scroll are just catenated onto the next line. So all the data appears to be there...
Thank you very much Mickey...
I continue with the conversion from MF to GNU.
Once the data has been passed and trying to keep it updated, it seems that BDB works better than VBISAM.
I'm preparing a full suite of tests.
As I intend to switch to SQL, I have been testing esqlOC, the version is:
esqlOC: ESQL for GnuCOBOL/OpenCOBOL Version 3 (2022.01.15) Build Jan 4 2022.
In the first data passes of a file of 1,423,165 records, it records 1,140,245.
It fails silently and seems to generally leave logs that have special characters.
Does anyone have any clues?
I have tried the same data from MySQL cli and the error Incorrect string value: '\x82s. What...' for column 'descrip' at row xx, it's because the original data is in CP850 latin1 and MySQL doesn't seem to like it.
The problem that worries me is that esqlOC fails silently, which makes me question the reliability of the driver.
Can anyone report experiences on existing precompilers for GNUCOBOL?
Standard
EXEC SQLwill setup return codes in the variables defined in theSQLCAstructure, furthermostSQLCODE. Commonly that's in anSQLCAcopybook, but with esqlOC that gets generated into the programs.You can either manually check
SQLCODEor useEXEC SQL WHENEVERto code it at a single place.You can get more information via
SQLSTATEandSQLERRMC (1:SQLERRML)(if it isn't zero).This also applies to other
EXEC SQLpreprocessors (including GixSQL, OPEN-COBOL-ESQL, the DB2 preprocessor or pro*cob).Additional from those standard error handling for
EXEC SQL, you can useOCSQL_LOGLEVELto log communication and errors outside of the application.If you're interested to know how SQLCODE and SQLSTATE are set, then the beauty of free software applies - just search for those in the esqloc runtime library code.
If you have any suggestions how to adjust them: please do so (but obviously it has to follow standard
EXEC SQLpractice).Last edit: Simon Sobisch 2023-12-04
I have seen this post by Simon https://sourceforge.net/p/gnucobol/discussion/help/thread/8ac15a9083/?limit=25#0398/2189/bb4d which clarifies quite a bit about SQL drivers.
What I've looked at from esqlOC it seems that the ODBC layer hides errors from the driver.
According to Simon GixSQL is the best alternative
Thanks for your help
I'm going to study the instructions and try esqlOC.
I have downloaded GixSQL but it seems complicated to install since it does not respond to ./configure, make etc and I do not see clear instructions.
You also comment that the errors will be the same in all of them.
I'm going to go deeper because it seems "obvious" that the default configuration should transfer "all" the errors from the D.B. to the user program.
Thanks again
My tests
OCSQL_LOGLEVEL=999;export OCSQL_LOGLEVELAfter insertion
Values returned in all erroneous records
PART-KEY=XXXXXXXXX, SQLSTATE=00000, SQLCODE=+0000000000, SQLERRML+00000, SQLERRML WARNINGIn none of the variables you mention does it return values other than zero.
What am I missing?
Thank you
Last edit: Simon Sobisch 2023-12-04
Hm, you may reduce your data set to 10 items or so, including at least one "bad" record. This allows you to create a record with
OCSQL_LOGLEVEL=100.Dear Simon
I'm looking at ocsql2's prnerr function.
I think that simply always returning the value of err to OC_SQLCODE whenever err != 0, would return the error to the program that returned the handler.
Then in the COBOL program you can handle the Error codes according to your convenience.
Why pass some yes and others no?
Why report errors in standard error and variables?
Also, according to the level of OCSQL_LOGLEVEL, it uses 1,9,190,901 as levels that I have not been able to make sense of.
I think it is very difficult to manage from the COBOL program as it is proposed.
Passing the value of err to OC_SQLCODE simplifies everything and leaves the error handling to the COBOL program.
The COBOL programmer is supposed to know what he is doing and when he receives the error he will handle it.
Greetings
All errors should be passed - with an appropriate sqlcode.
Because that's how
EXEC SQLis supposed to work. Ideally: even when switching theEXEC SQLpreprocessor and/or database your programs can nearly be used without adjustments needed because of this standard handling.yes, a lower active level means "print what is higher".
prnerr()uses 190 so just set it to this value and run with some sample data, this should show us what's happening.Note: that function is always called when the DB says "there's a problem" or "there's some information" - so errors and warnings reported by the DB should land there.
As to Relational DBMS's which more closely follow the SQL standards, PostGreSQL is probably one of the more compliant Open Source RDBMS's.
IBM's Community Edition of DB2 is free for non commercial use and the included DB2 Precompiler for COBOL works with GNUCOBOL.
Let me know if you are interested in doing some POC testing with DB2. It's available for both Windows x64 and Linux x64.