Calling Managed C# WCF Service from unmanaged GNT

In Visual Cobol 2.2, I have a GNT where I'm trying to replace a call to a COM object with a call to WCF Web Service written in C#.  I have the service installed on the server, but I'm not sure how to code the call.  I've created a WSDL for the service, but when I run "Generate Client From WSDL", I get "error generating console client."

So, my questions are:

1.  Why is my attempt to generate the client from the WSDL failing, and

2.  Is there an example of how to call the WCF service from a GNT?


  • The client generation from WSDL tool cannot handle all WDSL files. It is advisable to test the WSDL using a 3rd party tool like SOAPUI to ensure that it is valid prior to trying to generate a COBOL client for it. If it does import into SOAPUI and you can call the web service correctly then you should open up a support incident with Customer Care and we will review the WSDL file to see why it is failing.

    It is much easier to call a WCF service from a managed .NET client than from a native client. In a .NET COBOL client you can simply add the service reference to your project and then you can instantiate the service and invoke its methods.

    I had covered this in a previous thread in this forum, where you can create a managed .NET COBOL client that calls the WCF service and then register it for COM Interop so you can call this client from native code using the OLE support.

    Please look at the thread here: and here


  • Ah, were that life so easy.

    We're converting a 4,000 program legacy system from NE 5.0 to VC, 95% of which are GNTs, so converting it to Managed code is not an option.

    I'd read over the other threads, and they were not helpful, which is why I opted to post a new message here.  We going to 64-bits, but we have a 32-bit PCL conversion program that is not available as 64-bit.  We have hundreds of report programs, but fortunately they all call one subroutine that invokes the PCL converter.  Rather than buying a new conversion solution or changing several hundred programs, if I can wrap the converter in a WCF service, it can be called from a 64-bit program and called from the afore-mentioned subroutine, so I only need to change one program.  This seemed like the ideal solution, but I'm having trouble finding coding the call to the service in an unmanaged GNT.

    I could compile the entire system as 32-bits, but that kind of defeats the purpose of migrating to a 64-bit server.

    I'll investigate the validity of the WSDL.  Can you please send me an example of how to call a WCF service in unmanaged COBOL?


  • Unmanaged COBOL calling a web service has to be done using the "generate client from WSDL" tool. If you're getting an error in that process, it is likely there is something in the WSDL or interface to the service that is not supported. This is where the calling code would be generated.

    Another alternative would be to create a managed COBOL class that consumes the WCF service. Expose the COBOL class as a COM object (there is a check box in the project property build settings). The GNT could then possibly call the managed class as a COM object.

  • I have attached a zip file containing an example of the second approach that Mike has mentioned. This contains two solutions, WCFCOBOLTest which consists of the WCF Web Service project named WCFCOBOLTest and the .NET client project named WCFCOMTest that consumes it and nativeclient which contains the native COBOL program that will call the managed client as a COM module. The WCFCOMTest project is set to be registered for COMInterop.

    To run this you need to open up WCFCOBOLTest.sln and then click on Debug-->Run without debug to start the Web Service and then open up the nativeclient.sln in a different Visual COBOL session and step through the code. You can also run nativeclient from the command prompt after rebuilding it.
  • This all seems so easy....

    Lesson number one:  When you use the Generate Client from WSDL tool, for it to work the service must be RUNNING.  It took a little pounding to get that through my thick skull.

    Having figured that out, the tool created the client.  However, when I try to compile it, I get a syntax error on the -proxy program, "'.' in source listing or program ID in native code."  I did not change the generated code.  Is there something I need to do to resolve this, or is this a bug in the generator?

    Also, the tool looks like it creates a console app, as the code has lots of "display" and "accept" statements.  I'm looking for something that is callable.  Do I need to set something different in the program properties or when I run the generator so I can build the Client as a GNT?  Or is this just a shortcut way to communicate with the service?  Or is the generated code a template that I need to adapt to my application's needs?

    Sorry to be so dense, but I've been all through the Micro Focus web site and the Web, and I've found very little documented on how to call a web service through unmanaged code,m and what I have found has been very general.  If this were new development, I would certainly have set things up differently, but this is a legacy system and I'm kind of stuck with what I have.

    Any help or examples would be great!


  • The WSDL generation should be independent of whether the service is running or not. The error you are getting appears to indicate that the name of the service in the WSDL is not valid to be a COBOL name and so the compiler is rejecting it. What is the name of the internal web service? You may have to manually change this in your program-id to a valid name.

    The client generator generates two programs for you. The first is the UI program which does ACCEPT/DISPLAY statements to get data for the call and return data from the call. This program then in turn calls the proxy program which accepts the parameters and actually calls the Web Service and then returns the parameters back to the calling UI.

    If you wanted to replace the generated UI with your own then you would just need to call the proxy using the same interface as the generated UI.

    If you wanted something simple where you could just add a reference to the project and then call the methods then you would have to use the managed client approach.