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:
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 Java bytecode, which exposes the module and its entry points as instance methods. Your JVM COBOL code can then get the instance of the program and can then invoke the COBOL methods directly, just like any other methods.
You write a proxy class in JVM 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 Java bytecode (and in many cases there will be only a very few changes, particularly in non-UI COBOL subroutines).
Your JVM COBOL code can then invoke the proxy class, which in turn invokes the original COBOL.
The advantages of calling the COBOL directly are:
The advantages of using a proxy class are: