2

I'm currently facing a problem with this team of 4.

Using binaries I downloaded on kiska's site. I'm able to compile cobol to C and run it with cobcrun or compile it to an executable. However I can 't get opencobol to find the postgres commands.

Here is the strat of my cobol script : 

identification division.
program-id. pgcob.
data division.
working-storage section.
01 pgconn usage pointer.
01 pgres usage pointer.
01 resptr usage pointer.
01 resstr pic x(80) based.
01 result usage binary-long.
01 answer pic x(80).

procedure division.
    display "Before connect:" pgconn end-display
    call "PQconnectdb" using
        by reference "dbname = postgres" & x"00"
        by reference "host = 10.37.180.146" & "00"
        returning pgconn
    end-call

...

the call PQconnectdb fail with module ont found : PQconnectdb

I noticed that if i rename the libpq.dll the error message change to can't find entry point. So at least I'm sure it can get my dll.

After digging into the code of the call method of the libcob library. I found it it was possible to pre load some dll using an environment variable COB_PRE_LOAD but sitll no results.

Here is what look the script to compile the cobol : 

call "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\amd64\vcvarsamd64.bat"
set COB_CONFIG_DIR=C:\OpenCobol\config
set COB_COPY_DIR=C:\OpenCobol\Copy
set COB_LIBS=%COB_LIBS% c:\OpenCobol\libpq.lib
set COB_LIBRARY_PATH=C:\OpenCobol\bin
set COB_PRE_LOAD=C:\OpenCobol\libpq.dll
@echo on
cobc -info
cobc -free -o pgcob -L:"C:\OpenCobol" -llibpq.lib test_cobol\postgres.cob
call cobcrun pgcob

I don't see anything missing, I'm using the 64-bit binaries from kiska's site and use the 64-bit cl.exe from Visual Studio, Postgres is a 64 bit version too (checked with dependencyChecker).

I even tryed to compile the generated C from Visual Studio, same result, but I may miss something, I'm pretty rotten in C and never really had to manage DLL or use Visual Studio.

What am I missing ?

Walfrat
  • 5,363
  • 1
  • 16
  • 35

1 Answers1

3

COB_PRE_LOAD doesn't take any path or extension, see the short documentation for the available runtime configurations. I guess

set COB_LIBRARY_PATH=C:\OpenCobol\bin;C:\OpenCobol
set COB_PRE_LOAD=libpq

Will work. You can omit the C:\OpenCobol\bin if you did not placed any additional executables there.

If it doesn't work (even if it does) I'd try to get the C functions resolved at compile time. Either use

CALL STATIC "PQconnectdb" using ...

or an appropriate CALL-CONVENTION or leave the program as-is and use

cobc -free -o pgcob -L"C:\OpenCobol" -llibpq -K PQconnectdb test_cobol\postgres.cob

From cobc --help:

-K generate CALL to <entry> as static

In general: the binaries from kiska.net are quite outdated. I highly suggest getting newer ones from the official download site or ideally build them on your own from source, see the documentation for building GnuCOBOL with VisualStudio.

Simon Sobisch
  • 6,263
  • 1
  • 18
  • 38
  • I missed the documentation in runtime.cfg. I will go for go for CALL STATIC. I know the binaries are outdated but I wanted something that i didn't have to compile on my own because I only doing it currently to evaluate the feasability of some migration between IBM/AIX Cobol to Open Cobol / Postgres. If i remeber well i did recompile some module (don't remeber if it was libcob or something else) but i had to move all declarations at starts of function because VS2008 is compliant to C85 and don't allow declaration in the middle of the function, unless openning an new block. I will try tomorrow. – Walfrat Nov 03 '16 at 19:50
  • The current svn snapshot *must* build and work with VS2005-VS2015, if not: please create a bug report. The svn version has a new important option for IBM COBOL - the warning/compiling with intermediate results (if given `-std=ibm` - but this doesn't [or likely won't in the future] support `CALL STATIC` (which shouldn't be necessary but a nice-to-have)...). In any case: please drop a note at the SF discussion boards about the evaluation, may lead to some additional hints. I suggest waiting for the rc2 (should be available this weekend) and compile from the win.zip. – Simon Sobisch Nov 04 '16 at 07:56
  • thanks for the informations.A last point : in the sample postgres script here : http://docplayer.net/15359615-5-4-does-opencobol-support-any-sql-databases.html. The last part under the comment `this will return garbage` don't return garbage but crash instead. My guess is, it's because of a segfault since the connection is released and since we're not on XP anymore this is expected right ? – Walfrat Nov 04 '16 at 08:48
  • Don't use the outdated information. The "original" and updated version of the FAQ is available at https://sourceforge.net/p/open-cobol/faq/ see [the entry for sql databases](http://open-cobol.sourceforge.net/faq/index.html#does-gnucobol-support-any-sql-databases). And this sample part is wrong - a pointer gets passed `BY VALUE` and "strangely" doesn't change (it cannot). The pointer value is invalid and shouldn't be used at all afterwards, depending on the Postgre-Version and OS this will return garbage or a segfault... – Simon Sobisch Nov 04 '16 at 10:26
  • @Walfrat: rechecked: current svn works with VS2005 and VS2008. The internal testsuite nearly passes completely (I'll do some missing commits but you can rely on the GnuCOBOL 2.0 rc2 version in general). – Simon Sobisch Nov 04 '16 at 14:02
  • I have a problem with VS2008, when i try to perform a 64bit release, there is no libvbisam in the windows_prerequisites_vc11/Win32/x64 folder. Should i copy the one from the 32 bit ? – Walfrat Nov 04 '16 at 14:42
  • Well no problem but SO's chat is blocked here while all the others of SE aren't. So I won't be able to try anything at home where I can access to the chat – Walfrat Nov 04 '16 at 15:53