Menu ▾ ▴

CALL verb not working properly?

Help getting started
Paul Raulerson
2015-07-27
2015-07-31

  • Paul Raulerson

    Paul Raulerson - 2015-07-27

    It would seem that if I compile two modules and put them all in the same folder, then CALL works normally.

    If, however, I compile to two or more executables, Call doesn't seem to work at all.

    It returns basically that lib cob: cannot locate the module.

    If you compile to an executable and put the module you want to call in an DYLIB, well, then it complains about not finding an entry point.

    Attached are two super simple files I used to test this.

    Is this the expected behavior in GnuCobol?

    -Paul

     

    Last edit: Simon Sobisch 2015-07-27
    CALL2.cob
    Call1.cob

  • Simon Sobisch

    Simon Sobisch - 2015-07-27

    Perfectly expected!

    Executables are not directly CALLable, as they aren't COBOL modules. If you really need this use CALL 'SYSTEM' USING 'CALL2' END-CALL but you'll start a second COBOL runtime. For normal cases: don't use executables at all but use cobcrun CALL1, if you want an executable do so only for real main programs = programs that are only called by the user not from COBOL.

    It should not be possible to put an executable (which entry point is main()) in an DYLIB. How did you do this (I guess either calling cobc twice or call the C compiler/linker yourself)?

    Simon

     

    Last edit: Simon Sobisch 2015-07-27

  • Paul Raulerson

    Paul Raulerson - 2015-07-27

    That makes sense - I was thinking more along mainframe lines I suppose.

    Yes, I really do want one main executable and every other program in a DYLIB, so that they can be modified if necessary without relinking the main program.

    Turned out that I had a couple problems- the file names apparently have to match the names of the programs, and the COB_LIB_PATH and DYLD-LIBRARY-PATH environment variables must include the folders they reside in.

    So now I can do a CALL CALL2 in the main program and it goes and executes as it should. I can then change and recompile CALL2 and voila! It all works. I think.

    Once setup and working, it is very simple. Getting there though... (sigh)

    Thanks
    -Paul

     

    • Brian Tiffin

      Brian Tiffin - 2015-07-27

      This will get better, Paul (and it's my bad that it isn't out there yet). The gnu-cobol-1.x branch has a modification to cobcrun to accept -M path/module so you'll be able to kick any entry point, from any dynamic shared library. There will always be the "only one main" rule, but it makes cobcrun a very flexible tool.

      Cheers,
      Brian

       

  • Paul Raulerson

    Paul Raulerson - 2015-07-27

    GnuCOBOL and the Documentation for it is great! By any measure, this is a really good compiler. It is obvious that lots of folks have put enormous effort into it. It is really fun to compile COBOL programs nearly instantly, and not have to setup JCL to do it. (grin)

    I have a feeling that GnuCOBOL will supplant almost every other COBOL compiler out there. Same as gcc did for C compilers. ;)

    I was sure tired while trying to figure this out last night, but a little work this morning seems to indicate that the real culprit here is the Oracle precompiler.

    Once a program is precompiled there are, or at least, can be, issues calling programs in dylibs that were not precompiled. On a Mac, this translates into a few seconds wait and the issuance of a BUS ERROR 10, along with a complete abort of the program.

    For example, the RCBIN64B and RCB64BIN freebie programs, that respectively decode and encode BASE64, exhibit just this behavior.

    If both the Dylibs and the Program are compiled without the Oracle Precompiler, they work fine.

    If both the Dylibs and the Program are compiled with the precompiler, they work fine.

    But if one is compiled with the precompiler, and one without, it just won't work. BUS ERROR 10 happens here.

    Though that is not always true. Occasionally, a simple call will work in a "mixed" environment.

    If anyone is interested, I will upload some simple example programs. Else wise, it is just an "anomaly" for me and I can work around it.

    Yours,
    -Paul

     

    Last edit: Paul Raulerson 2015-07-27

    • Vincent (Bryan) Coen

      Vincent (Bryan) Coen - 2015-07-27

      Hi Paul;

      What oracle Client are you using to get the pro*Cobol compiler ?

      What mods are you having to make (on the assumption that Pro*Cobol does
      not come in source form)?

      I assume that it generates code that directly calls the Oracle API
      libraries.

      Vince

      Mod edit: remove some reply-to

       

      Last edit: Brian Tiffin 2015-07-27

      • Paul Raulerson

        Paul Raulerson - 2015-07-30

        HI Vincent - apologies for the slow reply. Sourceforge was just - wierd - there for a little while.

        On the Mac, the InstantClient 64bit libraries at version 11_2. On Linux and Windows, the version number is slighlty higher.

        Pro*COBOL: Release 11.2.0.4.0 - Production on Thu Jul 30 15:57:00 2015

        Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.

        System default option values taken from: /Users/Paul/OracleClient/precomp/admin/pcbcfg.cfg

        No changes at all made to ProCobol - it just works. :)

        Yep, snipped of Cobol below. 

            DISPLAY ' '
       MOVE 'COMP' TO DT01-CODE

  *    EXEC SQL
  *      SELECT DESCR
  *       INTO :DT01-DESCR
  *       FROM DT01
  *       WHERE CODE = :DT01-CODE
  *    END-EXEC
       CALL "SQLADR" USING SQ0001 SQL-STMT
       MOVE 1 TO SQL-ITERS
       MOVE 36 TO SQL-OFFSET
       MOVE 0 TO SQL-OCCURS
       MOVE 1 TO SQL-SELERR
       CALL "SQLADR" USING
           SQLCUD
           SQL-CUD
       CALL "SQLADR" USING
           SQLCA
           SQL-SQLEST
       MOVE 4352 TO SQL-SQLETY
       CALL "SQLADR" USING
           DT01-DESCR
           SQL-SQHSTV(1)
       MOVE 80 TO SQL-SQHSTL(1)
       MOVE 80 TO SQL-SQHSTS(1)
       MOVE 0 TO SQL-SQINDV(1)
       MOVE 0 TO SQL-SQINDS(1)
       MOVE 0 TO SQL-SQHARM(1)
       CALL "SQLADR" USING
           DT01-CODE
           SQL-SQHSTV(2)
       MOVE 4 TO SQL-SQHSTL(2)
       MOVE 4 TO SQL-SQHSTS(2)
       MOVE 0 TO SQL-SQINDV(2)
       MOVE 0 TO SQL-SQINDS(2)
       MOVE 0 TO SQL-SQHARM(2)
       CALL "SQLADR" USING
           SQL-SQHSTV(1)
           SQL-SQPHSV
       CALL "SQLADR" USING
           SQL-SQHSTL(1)
           SQL-SQPHSL
         

        • Vincent (Bryan) Coen

          Vincent (Bryan) Coen - 2015-07-30

          Hi Paul;

          So if I have 11.2 (ex)press installed I can use the latest of instant
          client and I have installed only the basic version?

          Another issue is that the PRO*Cobol docs indicates loads of examples &
          demos along with various copy files etc but the basic instantclient did
          not include them.

          Do I need to install something else for Linux?

          Damn thing giving me a headache already :)

          Vince

          Mod edit: remove some reply-to

           

          Last edit: Brian Tiffin 2015-08-01

          • Paul Raulerson

            Paul Raulerson - 2015-07-31

            Relax Brother! It is probably a lot easier than you might imagine. :)

            First, download all the InstantClient Files. They will be a bunch of ZIP files.
            Second, unzip them all into the same directory.
            Third, from your login account, add in a few Environment Variables:

            ORACLE_HOME -> Top level folder you just unzipped everything into

            PATH = $ORACLE_HOME:$ORACLE_HOME/sdk:/usr/local/bin:$PATH

            COB_LIBRARY_PATH=/usr/local/lib <-- wherever you keep

            LD_LIBRARY_PATH=$ORACLE_HOME:$ORACLE_HOME/sdk:/usr/local/lib:$LD_LIBRARY_PATH

            (Or you can add the paths to your shared library paths under linux and run. Don't forget to run ldconfig! )

            And basically, you are ready to go. There are some cases where things might be missing, message files or whatever. If you run into that, you can get them from Oracle, or just drop me a line and I will send them on to you. If you downloaded InstantClient, you have a right to the mesasge files. Depends upon the version and so forth.)

            sqlplus username/password@databaseserver:1512/SID

            For Cobol, name your file something distinctive, like PROG1.pco.

            Then you should be able to run ProCobol like this:

            procob PROG1.pco --> if all is well, this will produce PROG1.cob

            Then feed it to OpenCobol with a command something like this. (Obvioulsy these are my library locations for devleopement. You will have different ones. This is also from a Mac.)

            cobc -v -O2 -x -L/Users/Paul/OracleClient64 cgi1.cob /usr/local/lib/cobsqlintf.o -lclntsh

            You do have to link cobsqlintf.o into the mix, and include the clntsh library. But that's it. It will find all the shared libraries it needs from the -L.

            When you run it, you must have the $ORACLE_HOME variable set, and I find it needs the COB_LIBRARY_PATH set if you are calling shared library OpenCobol moduels.

            I typed this on the fly, so if I screwed anything up, just let me know.
            -Paul

            P.S. Don't forget to edit the pco files, or whatever you name them, and generate the .cob files. :)

            If you have a lot of trouble, tell me what version of LInux you are using and I'll try to load up a VM over the weekend and help you out.

            Yours,
            -Paul

             

        • Vincent (Bryan) Coen

          Vincent (Bryan) Coen - 2015-07-31

          Hi Paul;

          Need to ask some info etc off list.
          Can you provide with your direct email addr?

          Mine is vbcoen around gmail dot com

          Vince

          Mod edit: remove some reply to

           

          Last edit: Brian Tiffin 2015-08-01

Anonymous
Anonymous

Add attachments
Cancel





MongoDB Logo MongoDB