Write a Proxy or Edit the COBOL for .NET Interoperation?

If the COBOL types are incompatible with the managed non-COBOL you want to interoperate with, you can either re-engineer the existing COBOL, or write a proxy COBOL class to act as an interface between the existing COBOL and the non-COBOL.

These two options have the following implications:

• Editing the existing COBOL

  You manipulate the types so that the Linkage section uses compatible types. You might need to re-engineer the COBOL if there is more than one point of EXIT or GOBACK, so that you move data back into the new Linkage Section. Alternatively, you can re-engineer your COBOL as a native OO COBOL class with one or more methods. Be aware that the more methods you use the more re-engineering you have to do.

  You compile your COBOL module to IL, which exposes the module and its entry points as instance methods. Your .NET COBOL code can then use the CobLoad method of the Interop class in the MicroFocus.COBOL.RuntimeServices namespace (included in the Micro Focus Runtime (Interop RuntimeServices) assembly) to get the instance of the program and can then invoke the COBOL methods directly, just like any other methods.

• Writing a proxy COBOL class

  You write a proxy class in .NET COBOL, which adds a thin layer between the existing COBOL and the non-COBOL managed code. This class interfaces between COBOL and the managed application using objects and properties, using the standard COBOL CALL "program" USING… syntax.

  You recompile the existing COBOL to IL (and in many cases there will be only a very few changes, particularly in non-UI COBOL subroutines).

  Your .NET COBOL code can then invoke the proxy class, which in turn invokes the original COBOL.

The advantages of calling the COBOL directly are:

• There might be a slight performance improvement, since there is no proxy layer
• There are fewer modules to maintain
• You don't need to write a proxy class

The advantages of using a proxy class are:

• The same COBOL sources can be used in both managed and traditional applications and so they are usable on other platforms
• The architecture is cleaner and easier to maintain
• You don't need to modify the Linkage section of the original COBOL, or provide code to unpackage the data passed as properties in an object
• If the proxy class implements an interface then standard coding patterns can be applied; that is, the implementation is separated from the definition.