I'm curious if anyone has had success calling the Zen/Btrieve by way of the BTRCALL function using MinGW GnuCOBOL? I'm attempting to move some old Realia and MF COBOL code to GnuCOBOL and running into issues with the link step of cobc (undefined reference to 'BTRCALL'). Both Realia and MF come with their own Btrieve interface modules but since GnuCOBOL doesn't I'm attempting to create a GnuCOBOL equivalent.
What I've done so far is the Btrieve supplied modules that I have available is: gendef wbtrv32.dll dlltool -d wbtrv32.def -D wbtrv32.dll -l libwbtrv32.a
I then compiled my main program that has the calls to BTRV (like Realia and MF do) and compiled the attached Btrieve API program which does the actual call to BTRCALL. Both COBOL program compile without any issues but the link step fails. I've also attached the output from gendef in case that helps.
The command that I'm using to compile is: cobc --static -x -o btsamp.exe btsamp.cob btrapi.cob -lwbtrv32 -L.
Any suggestions as to what I'm doing wrong? Thanks.
That's GCC on Windows, it can directly link in dlls.
What about cobc --static -x -o btsamp.exe btsamp.cob btrapi.cob -Q wbtrv32.dll, or better cobc -K BTRCALL -xv -o btsamp.exe -Q wbtrv32.dll btsamp.cob btrapi.cob?
In any case: there is no reference of a system library BTRV or BTRCALL in Micro Focus or ACUCOBOL-GT docs (the later is commonly more compliant to RM/COBOL) - can you please point to some docs what this is about?
Last edit: Simon Sobisch 2022-08-23
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2022-08-25
Hi Simon. While I didn't find anything specific about BTRCALL in the Micro Focus docs, I did find some info about the BTRV obj at this link: https://www.microfocus.com/documentation/net-express/nx30books/fhbtrv.htm. If one uses the call to BTRV in the obj it in turn gets translated to a call to BTRCALL that's located inside the Btrieve DLL. Hope that helps. Thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2022-08-23
I'm not sure exactly what I did but I finally got my test application to link. Now I just need to fiddle with the calling parameters to BTRCALL to get them to align with what BTRCALL is expecting since the info that I have from Btrieve tends to refer to C and I do mostly do COBOL and not C. I haven't yet figured out how making a CALL BY REFERENCE, BY CONTENT or BY VALUE equates to what C is expecting.
I don't have any Micro Focus docs on this I do have an old Realia COBOL sample application that I'll attach that somewhat explains where the BTRV and BTRCALL come in. In Realia the calling application calls BTRV which. The call to BTRV gets resolved in a Realia supplied realbtrv.obj. About all that realbtrv.obj does validates that 6 parameters were passed to it and remaps the parameters to match what BTRCALL is expecting. BTRCALL gets resolved by the Btrieve supplied wbtrv32.lib or w3btrv7.lib to load the appropriate Btrieve DLL.
The attached realbtrv.c.pseudocode.txt contains a decompiled version of the realbtrv.obj file along with some of my notes. This pseudocode mostly also mostly corresponds to the C version that Btrieve supplies. I don't know about the current releases of Micro Focus (about MF COBOL32 V4.0.32) but at one time they had an equivalent to realbtrv.obj that was called BTRV.OBJ (the BTRV.OBJ in reality has a leading underscore but that turns what I type to italics when I type it here). It appears that both BTR2XFH.OBJ and XFH2BTR.OBJ make their call to Btrieve thru this OBJ.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2022-08-24
You might want to consider using the GnuCOBOL CALLFH COBOL directive.
I use it to vector I-O calls to the Liant File system (I previously vectored call to C-Tree) .
The flow:
There is a copybook XFHFCD3.CPY that is populated by any COBOL I-O statement when the CALLFH compiler directive is in effect..
At entry into the CALLFH module, translate the EXTFH operation code to the equivalent Btrieve operation code, insure that the EXTFH parameter list is massaged to the Btrieve parameter list. Call Btrieve with the above.
The most difficult part was in using the key block definition and key block components
You will need to make sure that the COBOL directive ODOSLIDE is in effect in the CALLFH module.
Return Codes from Btrieve need to be translated to COBOL status codes.
The CALLFH interface eliminates ISAM issues I was having with the standard ISAM file systems supported by GnuCOBOL.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2022-08-25
Thanks. That's on my list of things to try although a working example of how to write something for EXTFH would be very helpful since I've not done that before and haven't run across any examples yet.
My immediate issue is trying to get a pretty much bare bones call to BTRV and BTRCALL working as I have a fair amount of code that makes use of a source code package that Norcom did many years ago (same folks that did Norcom ScreenIO). It's the product for Btrieve was called the Norcom Btrieve Starter Kit. It basically let's you write your COBOL application code in a manner similar to CICS and has one core module that handles all the interaction with Btrieve.
One thing that I plan to try over the next few days is to see if I get any different results using the VS compiled version of GnuCOBOL that's included with Gix-IDE and see if the MS tools behave differently from the MinGW tools. Different C compiler, librarian and linker so who knows.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm curious if anyone has had success calling the Zen/Btrieve by way of the BTRCALL function using MinGW GnuCOBOL? I'm attempting to move some old Realia and MF COBOL code to GnuCOBOL and running into issues with the link step of cobc (undefined reference to 'BTRCALL'). Both Realia and MF come with their own Btrieve interface modules but since GnuCOBOL doesn't I'm attempting to create a GnuCOBOL equivalent.
What I've done so far is the Btrieve supplied modules that I have available is:
gendef wbtrv32.dlldlltool -d wbtrv32.def -D wbtrv32.dll -l libwbtrv32.aI then compiled my main program that has the calls to BTRV (like Realia and MF do) and compiled the attached Btrieve API program which does the actual call to BTRCALL. Both COBOL program compile without any issues but the link step fails. I've also attached the output from gendef in case that helps.
The command that I'm using to compile is:
cobc --static -x -o btsamp.exe btsamp.cob btrapi.cob -lwbtrv32 -L.Any suggestions as to what I'm doing wrong? Thanks.
That's GCC on Windows, it can directly link in dlls.
What about
cobc --static -x -o btsamp.exe btsamp.cob btrapi.cob -Q wbtrv32.dll, or bettercobc -K BTRCALL -xv -o btsamp.exe -Q wbtrv32.dll btsamp.cob btrapi.cob?In any case: there is no reference of a system library
BTRVorBTRCALLin Micro Focus or ACUCOBOL-GT docs (the later is commonly more compliant to RM/COBOL) - can you please point to some docs what this is about?Last edit: Simon Sobisch 2022-08-23
Hi Simon. While I didn't find anything specific about
BTRCALLin the Micro Focus docs, I did find some info about theBTRVobj at this link: https://www.microfocus.com/documentation/net-express/nx30books/fhbtrv.htm. If one uses the call to BTRV in the obj it in turn gets translated to a call toBTRCALLthat's located inside the Btrieve DLL. Hope that helps. Thanks.I'm not sure exactly what I did but I finally got my test application to link. Now I just need to fiddle with the calling parameters to
BTRCALLto get them to align with whatBTRCALLis expecting since the info that I have from Btrieve tends to refer to C and I do mostly do COBOL and not C. I haven't yet figured out how making a CALL BY REFERENCE, BY CONTENT or BY VALUE equates to what C is expecting.I don't have any Micro Focus docs on this I do have an old Realia COBOL sample application that I'll attach that somewhat explains where the
BTRVandBTRCALLcome in. In Realia the calling application callsBTRVwhich. The call toBTRVgets resolved in a Realia supplied realbtrv.obj. About all that realbtrv.obj does validates that 6 parameters were passed to it and remaps the parameters to match whatBTRCALLis expecting.BTRCALLgets resolved by the Btrieve supplied wbtrv32.lib or w3btrv7.lib to load the appropriate Btrieve DLL.The attached realbtrv.c.pseudocode.txt contains a decompiled version of the realbtrv.obj file along with some of my notes. This pseudocode mostly also mostly corresponds to the C version that Btrieve supplies. I don't know about the current releases of Micro Focus (about MF COBOL32 V4.0.32) but at one time they had an equivalent to realbtrv.obj that was called BTRV.OBJ (the BTRV.OBJ in reality has a leading underscore but that turns what I type to italics when I type it here). It appears that both BTR2XFH.OBJ and XFH2BTR.OBJ make their call to Btrieve thru this OBJ.
Hopefully this all makes sense. :)
You might want to consider using the GnuCOBOL CALLFH COBOL directive.
I use it to vector I-O calls to the Liant File system (I previously vectored call to C-Tree) .
The flow:
There is a copybook XFHFCD3.CPY that is populated by any COBOL I-O statement when the CALLFH compiler directive is in effect..
At entry into the CALLFH module, translate the EXTFH operation code to the equivalent Btrieve operation code, insure that the EXTFH parameter list is massaged to the Btrieve parameter list. Call Btrieve with the above.
The most difficult part was in using the key block definition and key block components
You will need to make sure that the COBOL directive ODOSLIDE is in effect in the CALLFH module.
Return Codes from Btrieve need to be translated to COBOL status codes.
The CALLFH interface eliminates ISAM issues I was having with the standard ISAM file systems supported by GnuCOBOL.
Thanks. That's on my list of things to try although a working example of how to write something for EXTFH would be very helpful since I've not done that before and haven't run across any examples yet.
My immediate issue is trying to get a pretty much bare bones call to BTRV and BTRCALL working as I have a fair amount of code that makes use of a source code package that Norcom did many years ago (same folks that did Norcom ScreenIO). It's the product for Btrieve was called the Norcom Btrieve Starter Kit. It basically let's you write your COBOL application code in a manner similar to CICS and has one core module that handles all the interaction with Btrieve.
One thing that I plan to try over the next few days is to see if I get any different results using the VS compiled version of GnuCOBOL that's included with Gix-IDE and see if the MS tools behave differently from the MinGW tools. Different C compiler, librarian and linker so who knows.