unresolved reference cob_call_params during compilation with dbpre

Anonymous
2014-05-06
2014-10-24

  • Anonymous
    2014-05-06

    Hi All;
    I have problems during compilation step after precompiling with dbpre (the mysql precompiler).
    I'm working with ubuntu 14.4, opencobol 1.1.
    This is the output of the cobc step:

    mario@ubuntu:~/OC/dbpre$ cobc -x PCTB003B.cob cobmysqlapi.o -L/usr/lib/mysql -lmysqlclient
    cobmysqlapi.o: nella funzione "MySQL_fetch_fields":
    cobmysqlapi.c:(.text+0x7a4): riferimento non definito a "cob_call_params"
    cobmysqlapi.c:(.text+0x7cb): riferimento non definito a "cob_call_params"
    cobmysqlapi.o: nella funzione "MySQL_fetch_row":
    cobmysqlapi.c:(.text+0x841): riferimento non definito a "cob_call_params"
    cobmysqlapi.c:(.text+0x85c): riferimento non definito a "cob_call_params"
    cobmysqlapi.c:(.text+0x882): riferimento non definito a "cob_current_module"
    cobmysqlapi.o: nella funzione "MySQL_fetch_record":
    cobmysqlapi.c:(.text+0x990): riferimento non definito a "cob_call_params"
    cobmysqlapi.c:(.text+0x9ef): riferimento non definito a "cob_call_params"
    cobmysqlapi.c:(.text+0xa62): riferimento non definito a "cob_current_module"
    cobmysqlapi.o: nella funzione "MySQL_init":
    cobmysqlapi.c:(.text+0xc32): riferimento non definito a "cob_call_params"
    collect2: error: ld returned 1 exit status

    Any suggestion?
    Thank you in advance.
    Mario

     
  • Simon Sobisch
    Simon Sobisch
    2014-05-06

    I've never tried that but it should work with OpenCOBOL 1.1 (will likely need a little tweak for GNU Cobol 2.x). What is the output of

    cobc --version
    cobc PCTB003B.cob cobmysqlapi.o -v -L/usr/lib/mysql -lmysqlclient

    Simon

     

    • Anonymous
      2014-05-07

      Thank you for your reply;

      Here the output you required:

      mario@ubuntu:~/OC/dbpre$ cobc --version
      cobc (OpenCOBOL) 2.0.0
      Copyright (C) 2001,2002,2003,2004,2005,2006,2007 Keisuke Nishida
      Copyright (C) 2006-2012 Roger While
      This is free software; see the source for copying conditions. There is NO
      warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
      Built May 06 2014 12:54:44
      Packaged Feb 11 2012 12:36:31 UTC
      C version "4.8.2"

      mario@ubuntu:~/OC/dbpre$ cobc PCTB003B.cob cobmysqlapi.o -v -L/usr/local/lib -L/usr/lib/i386-linux-gnu -lmysqlclient
      Command line: cobc -v -L/usr/local/lib -L/usr/lib/i386-linux-gnu -lmysqlclient PCTB003B.cob cobmysqlapi.o
      Preprocessing: PCTB003B.cob -> /tmp/cob3874_0.cob
      Return status: 0
      Parsing: /tmp/cob3874_0.cob (PCTB003B.cob)
      Return status: 0
      Translating: /tmp/cob3874_0.cob -> /tmp/cob3874_0.c (PCTB003B.cob)
      Executing: gcc -std=gnu99 -I/usr/local/include -pipe -Wno-unused
      -fsigned-char -Wno-pointer-sign -shared -fPIC -DPIC
      -Wl,--export-dynamic -o "PCTB003B.so" "/tmp/cob3874_0.c"
      -L/usr/local/lib -lcob -lm -lgmp -lncurses -ldb -ldl
      -l"mysqlclient" -L"/usr/local/lib" -L"/usr/lib/i386-linux-gnu"
      Return status: 0
      Executing: gcc -std=gnu99 -shared -fPIC -DPIC -Wl,--export-dynamic -o
      "cobmysqlapi.so" "cobmysqlapi.o" -L/usr/local/lib -lcob -lm
      -lgmp -lncurses -ldb -ldl -l"mysqlclient" -L"/usr/local/lib"
      -L"/usr/lib/i386-linux-gnu"
      Return status: 0
      mario@ubuntu:~/OC/dbpre$

       

    • Anonymous
      2014-05-07

      Ok.. the problem was the cobc version...
      I've installed OpenCOBOL 1.1. and now it works.

      thanks for the support
      Mario

       
  • Simon Sobisch
    Simon Sobisch
    2014-05-07

    Despite of

    I'm working with ubuntu 14.4, opencobol 1.1.

    and

    Ok.. the problem was the cobc version...
    I've installed OpenCOBOL 1.1. and now it works.

    cobmysqlapi.c needs only some changes for working with both versions. I've mailed the issue and a possible solution to "the piper", he answered that he will have a look at it.

    Simon

    Edit: if you want to use a 2.x version get the current development version of GNU Cobol via svn (I guess you will do so when cobmysqlapi.c is fixed).

     
    Last edit: Simon Sobisch 2014-05-07
    • Mario Farris
      Mario Farris
      2014-05-08

      Ok, thanks.
      At the moment I will continue my test with OpenCOBOL 1.1.

      Mario

       
  • The_Piper
    The_Piper
    2014-05-07

    Hi there,

    if there is really some interest in dbpre, i am willing to start working on it again and make it working under the next gnu-cobol release.

    There are still features to add, write a proper documentation, IIRC all that cursor stuff could be enhanced and such.

    So, is anyone seriously using dbpre, so it's worth to work on it again?

    Unfortunately until now i got not that much response, so my personal impression is, that no one is interested in dbpre.

    Opinions, comments, suggestions?

    Feel free to post here!

    Piper

     
    • Mario Farris
      Mario Farris
      2014-05-08

      Hi;
      I'm just started to try OpenCOBOL with embedded SQL in order to understand its capabilities for developing - test - learning cobol for mainframe environment.
      So I started to use dbpre (I'm the anonymous that started this threat) and now I'm ready to use it with cobol sources for mainframe.
      I will keep you up2date about results...

      Regards
      Mario

       
    • Mario Farris
      Mario Farris
      2014-05-08

      Hi "Piper"...
      we have precompiled a mainframe source with dbpre and the output is not good;

      here few issue:
      - it don't recognize exec sql commands written on the same row of exec
      - during commenting sql statements it don't recognize the end of sql if the END-EXEC don't have the "." at the end (we have a lot of exec sql inside IF nidificated...); the problem is that dbpre go to comment also cobol business logic!
      - what about declare cursors not defined immediatly before the open and the fetch?

      I think that the idea is very good but dbpre at the moment need to be refined.

      I will be in touch for your upgrades.
      Regards
      Mario

       
  • The_Piper
    The_Piper
    2014-05-08

    Hi Mario,

    thanks for posting these issues, i'll try to work on that this weekend and maybe Monday we can have a new release.

    Cursors can be defined anywhere BEFORE their first use in a program.

    Dbpre collects all definitions of cursors, right now up to 64, and then, when used in a program used that collected definition.

    I think, i will set up a website for dbpre, going to post the link here then.

    There i can link to a forum, so we don't need to spam this one :D

    Piper

     
    • Mario Farris
      Mario Farris
      2014-05-09

      Very good!

      I will be the first tester of new dbpre version!
      Just a suggestion... I think the cobol framework (the external file with params for db connection, the procedure and WS copies) can be useful just for first connection to the DB, included i.e. in a first main batch program; but for the others db access maded i.e. by called subprograms I think that is better to be released from such framework; this can help during installation step of cobol sources written for mainframe environment that will not need to be modified.

      Regards
      Mario

       
      • The_Piper
        The_Piper
        2014-05-09

        Hi Mario,

        you are right, the current framework right now lacks the support for subroutines.

        But such frameworks can be very powerful, i have been using and developing such frameworks for nearly 30 years on mainframes and unix servers.

        For a batch program, the framework will connect and disconnect/rollback to/from the database in the batch program, pass references of that connection in a parameter block to subroutines, so they can use that connection too.

        That parameter block is used too to exchange error codes from subroutine to subroutine and finally back to the main batch program.

        Example:
        The framework will offer a standard handling of database errors, you have to write stuff like this:

        In SUBROUTINE3, the lowest level

        SQL-STATEMENT
        ....
        EVALUATE TRUE
        WHEN DB-OK
        CONTINUE
        WHEN OTHER
        PERFORM DB-STATUS
        END-EVALUATE

        When a DB error except DB-OK occurs, control is passed to the DB-STATUS section, which stores informations in the parameter block of the framework and then does a GOBACK.

        SUBROUTINE2, the one which calls SUBROUTINE3, does this:

        CALL SUBROUTINE3-CALL-ID USING FRAMEWORK-PARAM-BLOCK
        SUBROUTINE3-PARAM-BLOCK
        END-CALL
        EVALUATE TRUE
        WHEN FRAMEWORK-STATUS-OK
        CONTINUE
        WHEN OTHER
        PERFORM FRAMEWORK-STATUS
        END-EVALUATE

        So there are two parameter blocks passed to a subroutine, one for the framework (which has the error code and other stuff), one which contains the data for the subroutine itself.

        DB-STATUS in SUBROUTINE3 sets the FRAMEWORK-ERROR-CODE and does a GOBACK.

        SUBROUTINE2 goes into the WHEN OTHER branch of the EVALUATE statement and goes to FRAMEWORK-STATUS,

        FRAMEWORK-STATUS does a GOBACK again, until we reach the main batch program.

        The batch program then finally does a PERFORM FRAMEWORK-STATUS, where a ROLLBACK is done and an error message is displayed with all informations of the FRAMEWORK-PARAM-BLOCK, which includes the subroutine, who caused the error, the SQL-SEQUENCE of the SQL statement, which caused the error and the database error message like "NO CONNECTION ESTABLISHED", "NO DATA" or whatever.

        Well, that are future plans for dbpre, but i can tell you at least from my experiences over the year that such frameworks really work and are really helpful :)

        Piper

         
  • Bill Woodger
    Bill Woodger
    2014-05-08

    Piper,

    Many Mainframe beginners look to GNU COBOL to "practice" on at home. Many more will if there can be a DB2-like pre-compiler available as well. I think your time and efforts will be appreciated by many.

    Bill

     
    • The_Piper
      The_Piper
      2014-05-08

      Valid point, Bill,

      but dbpre will never be like the DB2 precompiler, just because the DB2 precompiler does syntax checks at compile time and MySql expects the sql statement in a string and does syntax checks at runtime.

      But at least ppl can get a feeling how to program with databases when using dbpre.

      And yes, i am a DB2 and COBOL user on IBM mainframes at work, so dbpre might smell at least a little bit like DB2 stuff :)

      Piper

       


Anonymous


Cancel   Add attachments