Menu ▾ ▴

dbpre GNUCOBOL with mysql

Help getting started
Anonymous
2015-06-07
2021-11-28
<< < 1 2 3 4 5 > >> (Page 4 of 5)

  • The_Piper

    The_Piper - 2020-08-22

    I'm working on that free format (-f) too.

     

    • Vincent (Bryan) Coen

      Vincent (Bryan) Coen - 2020-08-22

      On 22/08/2020 01:37, The_Piper wrote:

      I'm working on that free format (-f) too.

      Great that may well save me changing the presql2 (JC compiler) to
      support standard SQL requests soon but will have to at some point as I
      want to make it multi talented.    [  mysql, postgres, db2, oracle, et al ]

      Vince

       

  • The_Piper

    The_Piper - 2020-08-23

    You can do a happy dance, @vcoen, i preprocessed, compiled and ran this program earlier :)

    *> free format
*>*******************************************************************
*>  I D E N T I F I C A T I O N   D I V I S I O N                         
*>*******************************************************************
IDENTIFICATION              DIVISION.
PROGRAM-ID.                 freeform.
AUTHOR.                     THE_PIPER.
DATE-WRITTEN.               TODAY.
*>*******************************************************************
*>  D A T A    D I V I S I O N                                           
*>*******************************************************************
DATA                        DIVISION.
*>*******************************************************************
*>  W O R K I N G   S T O R A G E   S E C T I O N                         
*>*******************************************************************
WORKING-STORAGE SECTION.
*>
*> The needed working storage stuff for the framework
COPY PGCTBBATWSFREE.
*>
*> This will be displayed in the logfile at runtime
01  PGCTB-VERSION                    PIC  X(38) 
*>HISTOR*     VALUE '20120426 1.0 INITIAL RELEASE'.
VALUE '20140521 1.2 CURSORS'.
*>
01  FIELD1.
    05 FIELD1-NUM                      PIC  9(08).
    05 FILLER                          PIC  X(12) VALUE SPACE.
01  FIELD2                           PIC  X(16).
01  FIELD3                           PIC  X(32).
*>
01  T                                PIC  S9(9) COMP.
*>
*> The communication area for the database
EXEC SQL 
     INCLUDE SQLCA  
END-EXEC.

*>*******************************************************************
*>  P R O C E D U R E   D I V I S I O N                                   
*>*******************************************************************
PROCEDURE DIVISION.
*> The framework itself, calling PGCTB-ACTION to run the users coding
EXEC SQL
     INCLUDE PGCTBBATFREE REPLACING 'TTTTNNNB' BY 'freeform'.
END-EXEC.


*>*******************************************************************
*>  P G C T B - A C T I O N   S E C T I O N                               
*>*******************************************************************
PGCTB-ACTION SECTION. 
*>
DISPLAY 'In PGCTB-ACTION.'
*>
*>    EXEC SQL
*>       ROLLBACK
*>       please do not parse this......
*>    END-EXEC
*>
PERFORM DISPLAY-ALL-RECORDS
*>
DISPLAY 'Delete entire table'
*> 
EXEC SQL
        DELETE
        FROM example_table
END-EXEC.
EVALUATE TRUE
   WHEN DB-OK
      CONTINUE
   WHEN OTHER
      PERFORM DB-STATUS
END-EVALUATE
*>
PERFORM DISPLAY-ALL-RECORDS
*>
DISPLAY 'Insert new records'
*> 
PERFORM VARYING T FROM 1 BY 1 UNTIL T > 10
   MOVE T                   TO FIELD1-NUM
   DISPLAY 'Inserting #' T
   EXEC SQL
      INSERT 
      INTO example_table
      (
         FIELD1, 
         FIELD2, 
         FIELD3
      )
      VALUES
      (
        :FIELD1 ,
        'Value2' ,
        'Value3'  
      )
   END-EXEC.
*>       DISPLAY SQLCA-STATEMENT
*>       DISPLAY 'SQLCODE=' SQLCODE
   EVALUATE TRUE
      WHEN DB-OK
         CONTINUE
      WHEN OTHER
         PERFORM DB-STATUS
   END-EVALUATE
END-PERFORM   
*>
PERFORM DISPLAY-ALL-RECORDS
*> 
DISPLAY 'Update the first record'
*> 

EXEC SQL
   UPDATE example_table
   SET FIELD1 = 'UpdatedValue1'
   WHERE FIELD1 = '00000001'
END-EXEC.
*> 
DISPLAY 'Update the third record'
*> 

EXEC SQL
   UPDATE example_table
   SET FIELD1 = 'UpdatedValue3'
   WHERE FIELD1 = '00000003'
END-EXEC.
*>    DISPLAY 'SQLCA-STATEMENT=' SQLCA-STATEMENT
*>    DISPLAY 'SQLCODE=' SQLCODE
*>    DISPLAY 'SQLCA-COUNT=' SQLCA-COUNT
EVALUATE TRUE
   WHEN DB-OK
      CONTINUE
   WHEN OTHER
      PERFORM DB-STATUS
END-EVALUATE
*> 
PERFORM DISPLAY-ALL-RECORDS
*> 
DISPLAY 'Ende PGCTB-ACTION.'
*>
.
PGCTB-ACTION-EXIT.
EXIT.

*>*******************************************************************
DISPLAY-ALL-RECORDS SECTION. 
*>
DISPLAY '-----DISPLAY-ALL-RECORDS-------------------'
*> Attention !! Table name is CaSe sensitive!!!!!!!!!!!!!
EXEC SQL
   DECLARE ALLROWS CURSOR FOR
      SELECT FIELD1, FIELD2, FIELD3
      INTO :FIELD1 :FIELD2 :FIELD3
      FROM example_table
END-EXEC.
EVALUATE TRUE
   WHEN DB-OK
      CONTINUE
   WHEN OTHER
      PERFORM DB-STATUS
END-EVALUATE
*>
EXEC SQL
   OPEN ALLROWS
END-EXEC.
EVALUATE TRUE
   WHEN DB-OK
      CONTINUE
   WHEN DB-NOT-FOUND
      CONTINUE
   WHEN OTHER
      PERFORM DB-STATUS
END-EVALUATE

DISPLAY  'FIELD1=' FIELD1 ' FIELD2=' FIELD2 
   ' FIELD3=' FIELD3

PERFORM UNTIL NOT DB-OK
   EXEC SQL
      FETCH ALLROWS
      INTO :FIELD1 :FIELD2 :FIELD3
   END-EXEC.
   EVALUATE TRUE
      WHEN DB-OK
         DISPLAY  'FIELD1=' FIELD1 ' FIELD2=' FIELD2 
                  ' FIELD3=' FIELD3
      WHEN DB-NOT-FOUND
         MOVE SPACE             TO FIELD1
         MOVE SPACE             TO FIELD2
         MOVE SPACE             TO FIELD3
      WHEN OTHER
         PERFORM DB-STATUS
   END-EVALUATE
END-PERFORM
DISPLAY 'SQLCODE=' SQLCODE
SET DB-OK                      TO TRUE
DISPLAY '-------------------------------------------'
*>
EXEC SQL
   CLOSE ALLROWS
END-EXEC.
EVALUATE TRUE
   WHEN DB-OK
      CONTINUE
   WHEN OTHER
      PERFORM DB-STATUS
END-EVALUATE
.
DISPLAY-ALL-RECORDS-EXIT.
EXIT.

    but i have no clue if i support every feature of free format, at least dbpre generates coding, which can be compiled with cobc -free without errors and the binary is running and doing what it should do.

    Going finally to work on cobmysqlapi.c tomorrow or so, its just the Windows stuff missing, that shouldnt be a big thing.

     

    • Vincent (Bryan) Coen

      Vincent (Bryan) Coen - 2020-08-23

      On 23/08/2020 01:39, The_Piper wrote:

      You can do a happy dance, @vcoen https://sourceforge.net/u/vcoen/, i
      preprocessed, compiled and ran this program earlier :)

      That look good I will grab it when you have finished.

      I did look at dbpre  and the JC pre-processor when programming my DAL
      (Data Access Layer) units for ACAS and these handle the processing in
      place for read, write, open, close etc for file handling.

      The plus for yours was standard SQL but the JC one has some features
      that as a programmer I found time saving.

      The JC tool does NOT use standard EXEC SQL statements but extended type
      but does simplify some of the elements that are not in the standard SQL
      as near as I can tell.

      Will still like to try it even if I have to add some more functions to
      cover the differences.

      In any event I will need to put in support for reading a $SET SQL XYZ
      cobol source line to work out what process is being requested where xyz
      = MYSQL | MARIA, DB2, POSTGRES, ORACLE   etc.

      After all it is 'mostly' just a case of changing the CALL routines -- 
      famous last words :)

       

  • The_Piper

    The_Piper - 2020-08-24

    In any event I will need to put in support for reading a $SET SQL XYZ
    cobol source line to work out what process is being requested where xyz
    = MYSQL | MARIA, DB2, POSTGRES, ORACLE etc.

    After all it is 'mostly' just a case of changing the CALL routines --
    famous last words :)

    Exactly, you named it. Just change the CALL's* :P

    Technically spoken, its not a problem to add support for DB2, Postgres, ORACLE, whatever.

    But i am not a DB admin who knows how to use all those DB systems, so, if thats a request, i need some help to add support for those DB's to dbpre.

     

    • Simon Sobisch

      Simon Sobisch - 2020-08-24

      Some code will also with SQL often be specially crafted to the sql dialect. This is the reason that Vincent asked for supporting conditional compilation (a plain $IF xyz + $IF xyz = literal / >> IF xyz DEFINED + >> IF xyz = literal should be enough for this). A possible solution may be:

      cobc -i someprog.pco -o someprog.i.pco && \
   dbpre somprog.i.pco -o someprog.cob && \
   cobc someprog.cob

      To allow this to work dbpre would have to:

      • understand free format
      • ignore all lines starting with #
      • possibly uncomment the EXEC SQL lines it has processed in its output

      Ideally it would:

      • parse the lines starting with #line, saving the "current original line" and "current actual line"
      • create a #line itsownoutputname:line when it starts to insert (= after the EXEC SQL)
      • create a #line inputname:line when it is finished

      This would allow the final cobc to show accurate COBOL line numers for any diagnostic.

       

    • Vincent (Bryan) Coen

      Vincent (Bryan) Coen - 2020-08-24

      On 24/08/2020 03:50, The_Piper wrote:

      In any event I will need to put in support for reading a $SET SQL XYZ
cobol source line to work out what process is being requested
where xyz
= MYSQL | MARIA, DB2, POSTGRES, ORACLE etc.

After all it is 'mostly' just a case of changing the CALL routines --
famous last words :)

      Exactly, you named it. /Just/ change the CALL's* :P

      Technically spoken, its not a problem to add support for DB2,
      Postgres, ORACLE, whatever.

      But i am not a DB admin who knows how to use all those DB systems, so,
      if thats a request, i need some help to add support for those DB's to
      dbpre.

      No, I will do these on a as time and health permits basis.

      Vince

       

  • The_Piper

    The_Piper - 2020-08-26

    Clean compile for my modified cobmysqlapi.c both under Windows and Linux.

    At least some progress and success :)

    Testing it soon, today it's too late at night.

     
    👍
    1

  • The_Piper

    The_Piper - 2020-08-26

    Okay, it seems to work, at least under Linux.
    My version of cobmysqlapi is here (before i'll upload it to SF):
    pipsearch.ddns.net/cobmysqlapi.c

    But unter Windows i have a problem to compile the cob file with cobc.
    I get this error message:

    C:\Users\George\C\dbpre-code-r19\dbpre-code-r19>cpctb004b
    C:\Users\George\C\dbpre-code-r19\dbpre-code-r19>dbpre PCTB004B -ts=3 -I./
    setting option tabstop=3
    copybookpath=>.<
    dbpre V 0.4 2020-08-22
    ======================
    0 Errors.
    C:\Users\George\C\dbpre-code-r19\dbpre-code-r19>REM cobc -x PCTB004B.cob cobmysqlapi.o -L"C:\Program Files\MySQL\MySQL Server 8.0\lib" -lmysql
    C:\Users\George\C\dbpre-code-r19\dbpre-code-r19>cobc -x PCTB004B.cob cobmysqlapi.o -L"C:\Program Files\MySQL\MySQL Server 8.0\lib" -lmysqlclient

    C:\GnuCobol-3.1\bin/ld.exe: C:\Program Files\MySQL\MySQL Server 8.0\lib/mysqlclient.lib(libssl-1_1-x64.dll): Recognised but unhandled machine type (0x8664) in Import Library Format archive

    cobmysqlapi.o:cobmysqlapi.c:(.text+0x52d): undefined reference to mysql_errno@4' cobmysqlapi.o:cobmysqlapi.c:(.text+0x559): undefined reference tomysql_error@4'
    cobmysqlapi.o:cobmysqlapi.c:(.text+0x587): undefined reference to mysql_errno@4' cobmysqlapi.o:cobmysqlapi.c:(.text+0x5b4): undefined reference tomysql_error@4'
    ...

    Any clues what that might be?

     

    Last edit: The_Piper 2020-08-26

    • Vincent (Bryan) Coen

      Vincent (Bryan) Coen - 2020-08-27

      Found your message and saved the .c file so will look at it over the
      next day ot so and will try and use it to build one of my DAL modules.

      Vince
      .

      On 27/08/2020 00:11, The_Piper wrote:

      Okay, it seems to work, at least under Linux.
      My version of cobmysqlapi is here (before i'll upload it to SF):
      pipsearch.ddns.net/cobmysqlapi.c

      But unter Windows i have a problem to compile the cob file with cobc.
      I get this error message:

      C:\Users\George\C\dbpre-code-r19\dbpre-code-r19>cpctb004b
      C:\Users\George\C\dbpre-code-r19\dbpre-code-r19>dbpre PCTB004B -ts=3 -I./
      setting option tabstop=3
      copybookpath=>.<
      dbpre V 0.4 2020-08-22
      ======================
      0 Errors.
      C:\Users\George\C\dbpre-code-r19\dbpre-code-r19>REM cobc -x
      PCTB004B.cob cobmysqlapi.o -L"C:\Program Files\MySQL\MySQL Server
      8.0\lib" -lmysql
      C:\Users\George\C\dbpre-code-r19\dbpre-code-r19>cobc -x PCTB004B.cob
      cobmysqlapi.o -L"C:\Program Files\MySQL\MySQL Server 8.0\lib"
      -lmysqlclient
      C:\GnuCobol-3.1\bin/ld.exe: C:\Program Files\MySQL\MySQL Server
      8.0\lib/mysqlclient.lib(libssl-1_1-x64.dll): Recognised but unhandled
      machine type (0x8664) in Import Library Format archive
      cobmysqlapi.o:cobmysqlapi.c:(.text+0x52d): undefined reference to
      |mysql_errno@4' cobmysqlapi.o:cobmysqlapi.c:(.text+0x559): undefined
      reference to|mysql_error@4'
      cobmysqlapi.o:cobmysqlapi.c:(.text+0x587): undefined reference to
      |mysql_errno@4' cobmysqlapi.o:cobmysqlapi.c:(.text+0x5b4): undefined
      reference to|mysql_error@4'
      ...

      Any clues what that might be?

       

    • Vincent (Bryan) Coen

      Vincent (Bryan) Coen - 2020-12-16

      Hi;

      Sorry have not got back to you as I am having issues building with
      connection-c sources and GnuCobol.

      Will have yet another try over the end of year period and see if I can
      get any further as I am not going out any where .

      There again that has been at a minimum for the last nine months.

      Vincent

      On 27/08/2020 00:11, The_Piper wrote:

      Okay, it seems to work, at least under Linux.
      My version of cobmysqlapi is here (before i'll upload it to SF):
      pipsearch.ddns.net/cobmysqlapi.c

      But unter Windows i have a problem to compile the cob file with cobc.
      I get this error message:

      C:\Users\George\C\dbpre-code-r19\dbpre-code-r19>cpctb004b
      C:\Users\George\C\dbpre-code-r19\dbpre-code-r19>dbpre PCTB004B -ts=3 -I./
      setting option tabstop=3
      copybookpath=>.<
      dbpre V 0.4 2020-08-22
      ======================
      0 Errors.
      C:\Users\George\C\dbpre-code-r19\dbpre-code-r19>REM cobc -x
      PCTB004B.cob cobmysqlapi.o -L"C:\Program Files\MySQL\MySQL Server
      8.0\lib" -lmysql
      C:\Users\George\C\dbpre-code-r19\dbpre-code-r19>cobc -x PCTB004B.cob
      cobmysqlapi.o -L"C:\Program Files\MySQL\MySQL Server 8.0\lib"
      -lmysqlclient
      C:\GnuCobol-3.1\bin/ld.exe: C:\Program Files\MySQL\MySQL Server
      8.0\lib/mysqlclient.lib(libssl-1_1-x64.dll): Recognised but unhandled
      machine type (0x8664) in Import Library Format archive
      cobmysqlapi.o:cobmysqlapi.c:(.text+0x52d): undefined reference to
      |mysql_errno@4' cobmysqlapi.o:cobmysqlapi.c:(.text+0x559): undefined
      reference to|mysql_error@4'
      cobmysqlapi.o:cobmysqlapi.c:(.text+0x587): undefined reference to
      |mysql_errno@4' cobmysqlapi.o:cobmysqlapi.c:(.text+0x5b4): undefined
      reference to|mysql_error@4'
      ...

      Any clues what that might be?

       

  • The_Piper

    The_Piper - 2020-08-28

    Thanks Vince,

    I guess, it will work with your stuff.

    I am working right now on a new distribution, all files stored in separate directories like src, examples, doc and such and writing a users guide.pdf/odt.

    I am going to post here a link to a zip file with all that stuff i want to release to sourceforge soon, so you, @vcoen and @Alan can test it (and maybe do some proof reading of the users guide).

     

  • The_Piper

    The_Piper - 2020-09-06

    Okay, here is the promised zip file with my latest changes and documentation.

    http://pipsearch.ddns.net/dbpre_0.4.zip

    The documentation still needs some updates, but dbpre supports now free format and cobmysqlapi.c is updated.

     

    Last edit: The_Piper 2020-09-06

  • Vincent (Bryan) Coen

    Vincent (Bryan) Coen - 2020-09-06

    Got the updates and will test shortly but after Wednesday as have to go to Hospital for a procedure on Wed with prep Tuesday so unlikely to feel up to it.

     

  • The_Piper

    The_Piper - 2020-09-07

    Thanks Vince, no hurry, and all the best and fingers crossed for your stay at the hospital!

     

    • Vincent (Bryan) Coen

      Vincent (Bryan) Coen - 2020-09-07

      On 07/09/2020 02:54, The_Piper wrote:

      Thanks Vince, no hurry, and all the best and fingers crossed for your
      stay at the hospital!

      As there is three version of dbpre all marked as 0.4  I will reversion
      this one as v1.2 along with the API file cobmysqlapi39.c

      Like wise the various build scripts will end with '.sh'  to indicate
      that they are scripts.

      On the previous version there is two sets of example programs - have to
      remind myself of what the second is doing :)

      Vince

       

  • The_Piper

    The_Piper - 2020-11-03

    Somehow i am stuck with that stuff and Windows...

    I have installed GnuCobol+gcc for Windows 10 from Arnolds page.

    I have installed MySQL.

    I can compile dbpre with gcc.

    I can compile cobmysqlapi.c with gcc and get an object file.

    I can preprocess scb files with dbpre.

    But when i compile the preprocessed COBOL source code with cobc i get this from ld.exe:

    Recognized but unhandled machine type (0x8664) in Import Library format archive

    I compile it this way:

    dbpre PCTB003B -ts=3 -I..\copybooks

    cobc -x PCTB003B.cob cobmysqlapi.o -L"C:\Programme\MySQL\MySQL Server 8.0\lib" -lmysqlclient -I..\copybooks

    Any ideas what the problem might be?
    A missing option for cobc maybe to specify the machine type?

     

    Last edit: The_Piper 2020-11-03

    • Simon Sobisch

      Simon Sobisch - 2020-11-03

      Any ideas what the problem might be?
      A missing option for cobc maybe to specify the machine type?

      That's nothing about cobc but the linker. It sees a x86_64 import library an you likely have used Arnold's 32bit MinGW build. Either use the MSYS2 64bit based one (or install MSYS2 and within via pacman -S gnucobol GnuCOBOL) or use a 32bit version of the MySQL client (server can stay 64bit and you possibly already have the 32bit client somewhere, too).

       

      • The_Piper

        The_Piper - 2020-11-04

        Thanks @sf-mensch,

        thats it obviously, scrolling down on Arnolds page helps to find a 64 bit version...

        Going to try that later, watching the US elections right now on TV :P

         

        Last edit: The_Piper 2020-11-04

    • James K. Lowden

      James K. Lowden - 2020-11-03

      As Simon says, the error message means the linker found a library it needs but can't use. The compiled code is 32-bit, but the library (probably the MySQL client library) is 64-bit.

      To confirm, run dumpbin /headers on the library. You can use verbose linking to show which libraries are being used. I think you'll see machine type 8664 on the library, but not on your .OBJ file.

      By the way, though, what is "dbpre" in this context? I wonder why you're going down this particular route. I have successfully tested the ocsql preprocessor against several DBMS systems. I tested under Linux, but it's a natural fit on Windows because it uses ODBC. I didn't test MySQL, but I did test MariaDB.

      If you encounter difficulties getting ocsql working on Windows, I'll do what I can to help out. I see no reason it shouldn't work, and lots of reasons it should, even if it doesn't.

       

      • Simon Sobisch

        Simon Sobisch - 2020-11-03

        I think the main point of using dbpre is "one thing [ODBC] left out between the application code and the database".
        Plus some environments may use dbpre already and changing to GnuCOBOL without changing (and retesting) the DB part again looks most reasonable in this case.

        ODBC gives a lot of benefits but sometimes they may not apply to the given scenario.

        And yes: I'd still like to see MySQL handled via esql-oc (and LMDB, I've heard there is an odbc driver for it).

         

        • James K. Lowden

          James K. Lowden - 2020-11-03

          So, I guess this dbpre, on SourceForge. ISTR that Oracle has a product by the same name.

          I'm still cursious why the OP is using it. I grant there may be good reasons. But I would never recommend a MySQL solution, much less a MySQL-only solution. That's why I asked.

           

          • The_Piper

            The_Piper - 2020-11-04

            @jklowden
            Yes, thats the dbpre i/we are talking about.

            Alan Honeyman and another person want to use it under Windows, thats the reason why i am trying to get it working under Windows.

            Edit: I just googled for dbpre and only found my project at sourceforge on the first page. Maybe i should sue Oracle for using my name for a precompiler, might be a nice source of income XD

             

            Last edit: The_Piper 2020-11-04

  • thomas

    thomas - 2020-11-03

    Looks like you are running on Linux but are using the Windows libraries or vice versa.

    Please see stackoverflow

     

  • Vincent (Bryan) Coen

    Vincent (Bryan) Coen - 2021-11-16

    Is the Aug 2020 version still the latest and if not where can I get the latest ?

     
<< < 1 2 3 4 5 > >> (Page 4 of 5)

Anonymous
Anonymous

Add attachments
Cancel