Type Compatibility in Interoperation with Managed Code

For 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.

The Microsoft Common Language Specification (CLS) defines a set of basic language features, including the rules for the common type system. In theory, your COBOL must use CLS-compliant types. However, in practice, you can use .NET types that are not CLS-compliant, providing the non-COBOL language supports them. This is true of many C# types.

Some ISO 2002 (or more precisely ISO/IEC 1989:2002) data types, such as binary-long and float-short are available, and we recommend you use these where appropriate. See COBOL Type Compatibility for details.

The techniques for ensuring data type compatibility include the following:

For integers, you could use the predefined type binary-long, which corresponds to int in both C# and Java.
For display types (PIC X fields), you could use a .NET System.String, a java.lang.String, or a portable string type.
For numeric types (PIC 9 fields), you could use a .NET System.Decimal, or in JVM a com.microfocus.cobol.program.ScaledInteger, and then you move the number out of there to whatever COBOL numerical field it was
For group items, you could use a value type to expose the items in the group.
For occurs types, you could use a .NET System.Collections.ArrayList, or java.util.ArrayList.
For other complex structures that are not CLS-compliant, you could use COBOL classes and value types with properties.
For object pointers, you could use a proxy class.
For example, a program might invoke COBOL and want to pass an object pointer, where the object has properties containing the data to be passed. The called COBOL method has to extract the data required from the object properties and convert it into COBOL types, such as a group item containing PIC X fields. You could use a proxy class with properties to do this. The original COBOL can then handle the data in its traditional form.