Overview of Interoperability

Microsoft provides the technology for interoperability between native and managed code. They have published much excellent documentation, which explains the options and gives advice on the strategies you can adopt.

Broadly, there are three techniques for calling between native COBOL and managed code (whether .NET COBOL or other managed languages):

CCW for calling a .NET component or managed code from native COBOL. CCW wraps the managed code in a COM Callable Wrapper, which you can call from native COBOL.
To do this, you register the managed class for COM interop. When you build the project, the class is registered and thereby made available to native COBOL.
RCW for calling native COBOL as a COM object from .NET managed code. RCW wraps the native COBOL in a Run-Time Callable Wrapper, which you can call from managed code.
To do this, first you package the native COBOL as a COM object and register it. Then you add the COM object as a reference in your project. When you build the project, the RCW is generated, thereby exposing the COM class as a managed proxy class.
Platform Invoke for calling native API functions from managed code. Platform Invoke enables you to call any function in any managed language.
To do this, first you first you package the native COBOL as a .dll, with the appropriate entry points. Then you add the .dll and the COBOL run-time system support as a reference in your project. The managed code can now call into your native functions. You must redeclare the function's signature in the managed source code, if you are using a non-COBOL language.

For native COBOL and .NET COBOL to interoperate, you don't need to worry about data type conversion. Native types are understood and converted to the appropriate .NET types when the COBOL is compiled.

However, for native COBOL to interoperate with managed code in other languages, the COBOL must use data types that are compatible with those languages. Often there is not a strict one-to-one correspondence between types in different languages and so you need to manipulate the code to ensure compatibility. For example, for integers (such as PIC S9(9) comp-5), you might use the predefined type binary-long, which corresponds to int in both C# and Java.

COM Support from Micro Focus

COM is a feature of Microsoft Windows which enables one application to load and send messages to any application registered with the operating system as a COM Automation server.

Micro Focus COM support enables you to send messages to COM objects from COBOL programs and classes (where this COBOL is behaving as a COM client). You can also create COM objects, enabling you to manipulate a COBOL class through COM Automation.

The terminology used to describe COM components - servers, classes, clients, and objects - can be confusing. In this documentation, we use these terms as follows:

COM class - COBOL class that you write based on existing COBOL programs
COM server or COM Automation server - an application created using COM classes
COM client - any program that accesses a COM server application
COM object or component - an instance of a COM server application received by a client

COM objects are built using Microsoft's Component Object Model (COM). There are two main differences between COM and a language such as native OO COBOL:

COM does not support inheritance. When you write a new COM class, you can't inherit functionality from any of your existing COM or non-COM classes.
COM does not support class methods and class data.

Microsoft also support a distributed version of COM, which works across a network, called DCOM. DCOM enables you to send messages to an object residing on a different machine.