Consume web services published on internet

2014-08-19
2014-09-08
<< < 1 2 (Page 2 of 2)
  • Tony Girgenti
    Tony Girgenti
    2014-08-27

    Vince,

    If I change "main" to "projectctest", I get the following link error in my Visual Studio compile:
    "error LNK2019: unresolved external symbol _main referenced in function ___tmainCRTStartup"

    Thanks,
    Tony

     
    • Sorry Tony I have run out of steam.

      Any one else help?

      On 27/08/14 16:37, Tony Girgenti wrote:

      Vince,

      If I change "main" to "projectctest", I get the following link error
      in my Visual Studio compile:
      "error LNK2019: unresolved external symbol _main referenced in
      function ___tmainCRTStartup"

      Thanks,
      Tony


       
    • Simon Sobisch
      Simon Sobisch
      2014-08-27

      As you build in VS you have to change the target of the C/C++-project to Dynamic Library (.dll), it's currently set to Application (.exe); do so in project options -> General Property Page -> Project Defaults -> Configuration Type, Check that Target Name is set to projecttest, too.

      In any case: please reload the win binaries, I've updated them as they had a severe mpir-related bug (same is true for win_prerequisites).

      And: I've retested it with the version in the download area, the following works (always add -v as there is a filter in the MSC build that filters too much in r411):

      cobc -x -v callcsl.cob projecttest.obj
      

      if you want to remove warnings or pass linker options to cl.exe add /K mylinkeroption to the options.

      Simon

       

      • Anonymous
        2014-08-28

        Simon,

        I changed the Configuration Type for the program to .dll and it compiled without error.

        I ran this:
        ~
        "cobc -x -v callcsl.cob projectctest.obj"
        ~

        and got these results:

        ~
        C:\OpenCOBOL20\Projects\CallCSLibrary>cobc -x -v callcsl.cob projectctest.obj
        Command line: cobc -x -v callcsl.cob projectctest.obj
        Preprocessing: callcsl.cob -> C:\Users\Tony\AppData\Local\Temp\cob9180_0.cob
        Return status: 0
        Parsing: C:\Users\Tony\AppData\Local\Temp\cob9180_0.cob (callcsl.cob)
        Return status: 0
        Translating: C:\Users\Tony\AppData\Local\Temp\cob9180_0.cob -> C:\Users\Tony\AppData\Local\Temp\cob9180_0.c (callcsl.cob)
        Executing: cl /c /I "C:\OpenCOBOL20\include" /MD
        /Fo"C:\Users\Tony\AppData\Local\Temp\cob9180_0.obj"
        "C:\Users\Tony\AppData\Local\Temp\cob9180_0.c"
        Microsoft (R) C/C++ Optimizing Compiler Version 18.00.21005.1 for x86
        Copyright (C) Microsoft Corporation. All rights reserved.

        cob9180_0.c
        Executing: cl /MD /Fe"callcsl"
        "C:\Users\Tony\AppData\Local\Temp\cob9180_0.obj"
        "projectctest.obj" libcob.lib /link /manifest /LIBPATH:"C:\GNU
        Cobol 2.0\libs" /LIBPATH:"C:\OpenCOBOL20\lib"
        Microsoft (R) C/C++ Optimizing Compiler Version 18.00.21005.1 for x86
        Copyright (C) Microsoft Corporation. All rights reserved.

        Microsoft (R) Incremental Linker Version 12.00.21005.1
        Copyright (C) Microsoft Corporation. All rights reserved.

        /out:callcsl.exe
        /manifest
        "/LIBPATH:C:\GNU Cobol 2.0\libs"
        /LIBPATH:C:\OpenCOBOL20\lib
        C:\Users\Tony\AppData\Local\Temp\cob9180_0.obj
        projectctest.obj
        libcob.lib
        Creating library callcsl.lib and object callcsl.exp
        LINK : warning LNK4098: defaultlib 'MSVCRTD' conflicts with use of other libs; use /NODEFAULTLIB:library
        projectctest.obj : error LNK2011: precompiled object not linked in; image may not run
        callcsl.exe : fatal error LNK1120: 1 unresolved externals
        ~

        I wish I knew more about compiling and linking, but I will try to figure these errors out.

        I am not sure I understand what you mean by this:
        ~
        In any case: please reload the win binaries, I've updated them as they had a severe mpir-related bug (same is true for win_prerequisites).
        ~

        What are "win binaries" and "win_prerequisites"?

        Thanks,
        Tony

         
      • Tony Girgenti
        Tony Girgenti
        2014-08-28

        Simon,

        I changed the Configuration Type for the program to .dll and it compiled without error.

        I ran this:
        "cobc -x -v callcsl.cob projectctest.obj"

        and got these results:

        C:\OpenCOBOL20\Projects\CallCSLibrary>cobc -x -v callcsl.cob projectctest.obj
        Command line:   cobc -x -v callcsl.cob projectctest.obj
        Preprocessing:  callcsl.cob -> C:\Users\Tony\AppData\Local\Temp\cob9180_0.cob
        Return status:  0
        Parsing:        C:\Users\Tony\AppData\Local\Temp\cob9180_0.cob (callcsl.cob)
        Return status:  0
        Translating:    C:\Users\Tony\AppData\Local\Temp\cob9180_0.cob -> C:\Users\Tony\AppData\Local\Temp\cob9180_0.c (callcsl.cob)
        Executing:      cl /c /I "C:\OpenCOBOL20\include" /MD
                        /Fo"C:\Users\Tony\AppData\Local\Temp\cob9180_0.obj"
                        "C:\Users\Tony\AppData\Local\Temp\cob9180_0.c"
        Microsoft (R) C/C++ Optimizing Compiler Version 18.00.21005.1 for x86
        Copyright (C) Microsoft Corporation.  All rights reserved.
        
        cob9180_0.c
        Executing:      cl /MD /Fe"callcsl"
                        "C:\Users\Tony\AppData\Local\Temp\cob9180_0.obj"
                        "projectctest.obj" libcob.lib /link /manifest /LIBPATH:"C:\GNU
                        Cobol 2.0\libs" /LIBPATH:"C:\OpenCOBOL20\lib"
        Microsoft (R) C/C++ Optimizing Compiler Version 18.00.21005.1 for x86
        Copyright (C) Microsoft Corporation.  All rights reserved.
        
        Microsoft (R) Incremental Linker Version 12.00.21005.1
        Copyright (C) Microsoft Corporation.  All rights reserved.
        
        /out:callcsl.exe
        /manifest
        "/LIBPATH:C:\GNU Cobol 2.0\libs"
        /LIBPATH:C:\OpenCOBOL20\lib
        C:\Users\Tony\AppData\Local\Temp\cob9180_0.obj
        projectctest.obj
        libcob.lib
           Creating library callcsl.lib and object callcsl.exp
        LINK : warning LNK4098: defaultlib 'MSVCRTD' conflicts with use of other libs; use /NODEFAULTLIB:library
        projectctest.obj : error LNK2011: precompiled object not linked in; image may not run
        callcsl.exe : fatal error LNK1120: 1 unresolved externals
        

        .

        I wish I knew more about compiling and linking, but I will try to figure these errors out.

        I am not sure I understand what you mean by this:
        >> In any case: please reload the win binaries, I've updated them as they had a severe mpir-related bug (same is true for win_prerequisites). <<

        What are "win binaries" and "win_prerequisites"?

        Thanks,
        Tony

         
        Last edit: Tony Girgenti 2014-08-28
  • Brian Tiffin
    Brian Tiffin
    2014-08-20

    Along with Simon's response firstly to say, any samples allowed in the FAQ, will get added, happily.

    Tony;

    Umm, C# eh? I'd like to point you at Vala ...

    https://wiki.gnome.org/Projects/Vala

    C# (ish) syntax, 100% compatible, and sympatico, with GNU Cobol.

    Vala is "well bound" to everything libc and glib, networking is well covered. It's not .NET, (and Mono works), but the coverage is vast within glib (GNOME) space, and that space is 100% open to CALL.

    https://wiki.gnome.org/Projects/Vala/GIONetworkingSample

    That's a path, but...

    Direct COBOL with CALL, for the win. libCURL in particular. With a FUNCTION-ID interface. ;-)

    Cheers,
    Brian

     
    Last edit: Brian Tiffin 2014-08-20
  • Simon Sobisch
    Simon Sobisch
    2014-08-28

    I don't know where you've got cobc/libcob/cobcrun from. If you use any OC2.0 builds (likely from kiska.net) you should upgrade to a GC2.0 build.

    If you've grabbed the GC2.0 build that was uploaded some days ago from the downloads area (as it seems from the output you've posted) you should reload them as they had a severe problem, I've updated them 18 hours ago.
    These are the "win binaries". "win_prerequisites" are available in the download area, too, and can be used to self-compile GC from svn with VisualStudio. They were updated, too.

    And to not confuse anyone naming the folder not "OpenCOBOL" could help as this implies an old version (you can even use spaces with VC builds, if you unpack the package to "C:\GNU Cobol 2.0" you even don't have to call the set_env batch).

    To the linker error: You can try

    cobc -x -v callcsl.cob projectctest.obj /K /NODEFAULTLIB:MSVCRTD
    

    But I guess the error is resolved/changed when you use a release version of projetctest.obj (seems like it was build with a DEBUG target).

    Simon

     
    • Tony Girgenti
      Tony Girgenti
      2014-08-28

      Simon,

      I resolved the linker errors by changes made to my Visual Studio solution.

      I ran this: "cobc -x -v callcsl.cob projectctest.obj"

      and got this output:
      C:\OpenCOBOL20\Projects\CallCSLibrary>cobc -x -v callcsl.cob projectctest.obj
      Command line: cobc -x -v callcsl.cob projectctest.obj
      Preprocessing: callcsl.cob -> C:\Users\Tony\AppData\Local\Temp\cob6348_0.cob
      Return status: 0
      Parsing: C:\Users\Tony\AppData\Local\Temp\cob6348_0.cob (callcsl.cob)
      Return status: 0
      Translating: C:\Users\Tony\AppData\Local\Temp\cob6348_0.cob -> C:\Users\Tony\AppData\Local\Temp\cob6348_0.c (callcsl.cob)
      Executing: cl /c /I "C:\OpenCOBOL20\include" /MD
      /Fo"C:\Users\Tony\AppData\Local\Temp\cob6348_0.obj"
      "C:\Users\Tony\AppData\Local\Temp\cob6348_0.c"
      Microsoft (R) C/C++ Optimizing Compiler Version 18.00.21005.1 for x86
      Copyright (C) Microsoft Corporation. All rights reserved.

      cob6348_0.c
      Executing: cl /MD /Fe"callcsl"
      "C:\Users\Tony\AppData\Local\Temp\cob6348_0.obj"
      "projectctest.obj" libcob.lib /link /manifest /LIBPATH:"C:\GNU
      Cobol 2.0\libs" /LIBPATH:"C:\OpenCOBOL20\lib"
      Microsoft (R) C/C++ Optimizing Compiler Version 18.00.21005.1 for x86
      Copyright (C) Microsoft Corporation. All rights reserved.

      Microsoft (R) Incremental Linker Version 12.00.21005.1
      Copyright (C) Microsoft Corporation. All rights reserved.

      /out:callcsl.exe
      /manifest
      "/LIBPATH:C:\GNU Cobol 2.0\libs"
      /LIBPATH:C:\OpenCOBOL20\lib
      C:\Users\Tony\AppData\Local\Temp\cob6348_0.obj
      projectctest.obj
      libcob.lib
      Creating library callcsl.lib and object callcsl.exp
      LINK : warning LNK4098: defaultlib 'MSVCRTD' conflicts with use of other libs; use /NODEFAULTLIB:library
      Executing: mt /manifest "callcsl.exe.manifest"
      /outputresource:"callcsl.exe";#1
      Microsoft (R) Manifest Tool version 6.3.9600.16384
      Copyright (c) Microsoft Corporation 2012.
      All rights reserved.

      I executed "CallCSL.exe" and it gave this error:
      [Window Title]
      callcsl.exe

      [Main Instruction]
      callcsl.exe has stopped working

      [Content]
      A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available.

      [Debug] [Close program]

      With this in the command prompt window:

      C:\GNU COBOL 2.0\Projects\CallCSLibrary>callcsl

      Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'CSCalc, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencie
      s. The system cannot find the file specified.
      at MathAdd(Int32 a, Int32 b)
      at _mainCRTStartup()

      I then downloaded this file: gnu-cobol-2.0_nightly_r411_win32_vc11_bin (1).7z and expanded it to the "C:\GNU Cobol 2.0" folder.

      I then ran this: "cobc -x -v callcsl.cob projectctest.obj /K /NODEFAULTLIB:MSVCRTD"

      and received this output:
      C:\GNU COBOL 2.0\Projects\CallCSLibrary>cobc -x -v callcsl.cob projectctest.obj /K /NODEFAULTLIB:MSVCRTD
      Command line: cobc -x -v -K -NODEFAULTLIB:MSVCRTD callcsl.cob projectctest.obj
      Preprocessing: callcsl.cob -> C:\Users\Tony\AppData\Local\Temp\cob7748_0.cob
      Return status: 0
      Parsing: C:\Users\Tony\AppData\Local\Temp\cob7748_0.cob (callcsl.cob)
      Return status: 0
      Translating: C:\Users\Tony\AppData\Local\Temp\cob7748_0.cob -> C:\Users\Tony\AppData\Local\Temp\cob7748_0.c (callcsl.cob)
      Executing: cl /c /I "C:\OpenCOBOL20\include" /MD
      /Fo"C:\Users\Tony\AppData\Local\Temp\cob7748_0.obj"
      "C:\Users\Tony\AppData\Local\Temp\cob7748_0.c"
      Microsoft (R) C/C++ Optimizing Compiler Version 18.00.21005.1 for x86
      Copyright (C) Microsoft Corporation. All rights reserved.

      cob7748_0.c
      Executing: cl /MD /Fe"callcsl"
      "C:\Users\Tony\AppData\Local\Temp\cob7748_0.obj"
      "projectctest.obj" libcob.lib /link /manifest /LIBPATH:"C:\GNU
      Cobol 2.0\libs" /LIBPATH:"C:\OpenCOBOL20\lib"
      Microsoft (R) C/C++ Optimizing Compiler Version 18.00.21005.1 for x86
      Copyright (C) Microsoft Corporation. All rights reserved.

      Microsoft (R) Incremental Linker Version 12.00.21005.1
      Copyright (C) Microsoft Corporation. All rights reserved.

      /out:callcsl.exe
      /manifest
      "/LIBPATH:C:\GNU Cobol 2.0\libs"
      /LIBPATH:C:\OpenCOBOL20\lib
      C:\Users\Tony\AppData\Local\Temp\cob7748_0.obj
      projectctest.obj
      libcob.lib
      Creating library callcsl.lib and object callcsl.exp
      LINK : warning LNK4098: defaultlib 'MSVCRTD' conflicts with use of other libs; use /NODEFAULTLIB:library
      Executing: mt /manifest "callcsl.exe.manifest"
      /outputresource:"callcsl.exe";#1
      Microsoft (R) Manifest Tool version 6.3.9600.16384
      Copyright (c) Microsoft Corporation 2012.
      All rights reserved.

      I ran the "CallCSL.exe" again and got the same error.

      Thanks,
      Tony

       
  • Simon Sobisch
    Simon Sobisch
    2014-08-28

    Hi Tony,

    I've no idea how your solution looks like. Please open the vs solution, do a cleanup (removing all the binaries) and put everything in a zip file for uploading it here. I'll check it afterwards.

    Simon

     
  • Simon Sobisch
    Simon Sobisch
    2014-08-28

    Hi Tony,

    these are the changes I've did

    • downgrade to vc11 (just changing PlatformToolset to vc110 and TargetFrameworkVersion to v4.5, ToolsVersion to 4.0
    • CPPClibrary: changed TargetType to .dll
    • ProjectCTest: set the PrecompiledHeader option for all targets, added CPPCLibrary.lib to Additional Dependencies and ../$(Configuration) to Additional Library Directories
    • created TargetPlatform x86 for CSCalc in ConfigurationManager
    • changed target of the solution to Win32 only
    • changed CallCSL.cob and ProjectTest.CPP as below

    CallCSL.cob

            IDENTIFICATION DIVISION.
            PROGRAM-ID. CallCSL.
            ENVIRONMENT DIVISION.
            DATA DIVISION.
            WORKING-STORAGE SECTION.
             01 VALUE-A USAGE BINARY-LONG value 1.
             01 VALUE-B USAGE BINARY-LONG value 2.
            PROCEDURE DIVISION.
              CALL "ProjectCTest" USING VALUE-A VALUE-B
              END-CALL. 
              STOP RUN.
    

    ProjectTest.CPP

    #include "stdafx.h"
    
    extern __declspec(dllimport) int MathAdd(int a, int b);
    extern __declspec(dllexport) int ProjectCTest(int a, int b); // put this line either here or in stdafx.h, not in both
    
    int ProjectCTest(int a, int b)
    {
        int answer = MathAdd(a, b);
        _tprintf(_T("%d\n"), answer);
        return answer;
    }
    

    This is necessary for the COBOL module to find the C source later.

    I've compiled/run with

    cobc-x -v CallCSL.cob ..\..\CSLibrary\Debug\ProjectCTest.lib
    set PATH=..\..\CSLibrary\Debug;%PATH%
    set COB_LIBRARY_PATH=..\..\CSLibrary\Debug
    CallCSL.exe
    

    The good news: CallCSL will find ProjectCTest and the call will be fine, you only need the PATH to ProjectCTest in environment COB_LIBRARY_PATH and the PATH to the DLLs that are called from there in environment PATH.

    The better news: You don't need the Wrapper ProjectCTest, but can call the CPP wrapper directly (as long as the export "C" is in and you link against it's lib). You either have to set COB_PRELOAD=name_of_cpp_wrapper_without_dll or rename the dll to match the exported name.

    The bad news here: the error is still the same as before and occurs in the loading of the C# module.
    Did you try the "simple" solution that was posted at stackoverflow (without cobc/libcob)? Did this work? If yes: it should work with libcob identical (needing a different signature and type for ProjectCTests as above, but the rest should work). If not I suggest to get this working before by posting the problems at the stackoverflow topic linked before.

    Simon

     
    Last edit: Simon Sobisch 2014-08-28
    • Tony Girgenti
      Tony Girgenti
      2014-08-31

      Simon,

      I did get this to run without a problem using the sample C# program CSCalc. Don't ask me how because I'm not sure I understand how to accomplish all of your bullet points at the beginning of your post. I was able to figure out some of them, but not all.

      I then changed the C# program from CSCalc to the program that I started all this for. That runs also beginning from the COBOL program CallCSL.exe, but it bombs out looking for a web service reference.

      I will work on that, but it did display the form and allowed interaction.

      Thanks for all of your help.

      Tony

       

    • Anonymous
      2014-09-01

      Simon,

      Just to update you, I got all of this to work the way I wanted it to. The COBOL program calls the C/C++/C# mess and executes my C# web service client.

      Now I can concentrate on passing data from the COBOL program to the web service client and back to the COBOL program.

      Thanks,
      Tony

       
    • Tony Girgenti
      Tony Girgenti
      2014-09-01

      Simon,

      Just to update you, I did get this to work the way I wanted it to. The COBOL program calls the C/C++/C# mess and the web service client works.

      Now, I would like to pass data from the COBOL program to the web service client and back again.

      Thanks,
      Tony

       
  • Simon Sobisch
    Simon Sobisch
    2014-09-01

    Sounds good.

    I've never done that but I'd go with PIC X(n) <-> char [n] <-> byte [n] as you have fixed length vars in COBOL most times. Just keep in mind that char isn't the same in .net (as it's a multibyte chararacter) as it's in C/C++.

    I think you'll be able to get this working, just try one step after another :-)

    In the end there will be a good sample in the FAQ, removing the need to do all these tests again :-)

    Simon

     
  • Tony Girgenti
    Tony Girgenti
    2014-09-02

    Simon,

    Knowing what you do about this solution, can you give me a little more detail of how to code this between the three projects.

    Thanks,
    Tony

     
    • Simon Sobisch
      Simon Sobisch
      2014-09-02

      I didn't passed vars in this environment. The passing from COBOL to C/C++ is explained in the wiki (see link on the first page of this discussion), passing data in both directions will be the first step. If you have an additional C++ project pass the data there next, too.

      After this works fine you can do the C++ <-> C# part (I didn't do this before but as this has nothing to do with COBOL or GC in general you should find help at stackoverflow or other places where C# coders meet).

      Simon

       
    • Simon Sobisch
      Simon Sobisch
      2014-09-08

      Just a head-up:
      You can pass char *, too. The only things you have to do

      COBOL --> C
      Use whatever PIC X you want and make sure to place a x'00' at the end of the string you want to pass.
      The cleanest solution is likely to use a c-pointer defined as USAGE POINTER and set it to the address of the working-storage item, pass it via USING c-pointer (or via USING vars, where vars is a group item with multiple char * and other vars if you like).

      C --> COBOL
      Use char * from C and a USAGE POINTER from COBOL, set the address of a LINKAGE or (non-allocated) BASED item to the pointer (see [820849dc#2052/97be/d783])
      a) via return value from C, with added "RETURNING c-pointer" to the CALL (this was done in the sample above as the C function already existed this way)
      b) via USING c-pointer (possible n times, you can use the same pointer vars you may have used in the other direction if you used the "likely cleanest solution" mentioned above).

      add a check for NULL in both COBOL and C and you have optional parameters for passing back and forth.

      Simon

       

      Related

      Discussion: getaddrinfo in GNU COBOL

<< < 1 2 (Page 2 of 2)


Anonymous


Cancel   Add attachments