Article description 

.NET  has created a new, level playing field for a multitude of programming languages to interact on a scale never before seen. In order to accomplish this feat though several new features had to designed and implemented such as a Common Language Runtime (CLR), and the Microsoft Intermediate Language (MSIL).  The runtime also enforces code robustness by implementing a strict type- and code-verification infrastructure called the common type system (CTS). The CTS ensures that all managed code is self-describing. The various Microsoft and third-party language compilers generate managed code that conforms to the CTS. This means that managed code can consume other managed types and instances, while strictly enforcing type fidelity and type safety.
But COBOL has been around long before the development of the CTS. How can existing COBOL developers and their code base interact with the new CTS? During the development phase of NetCOBOL for .NET Fujitsu Software paid attention to this issue and was able to identify how existing COBOL data types would "marshal" or integrate with the new .NET data types. In most cases the CTS type and the COBOL representation are obvious.

Take for example an integer data type. In COBOL integers are specified as PIC 9 and then have a length designator to quantify the extent of the information they will contain, such as PIC 9(10). In the .NET environment there are two basic integer types, INT16 and INT32. Both represent an integer but of different lengths. An INT16 is a 16-bit signed integer while an INT32 is a 32-bit signed integer. The COBOL representation of these integer types is PIC S9(04) COMP-5 and PIC S9(09) COMP-5, respectively.

One of the more common issues is "What does a PIC X convert to in .NET?"  The obvious answer would be a String data type. This is in fact true, the .NET compiler inserts automatic conversion (called coercions) between the COBOL variables and the CLR strings. What the developer has to be aware of though is when you define a STRING in .NET the length of the string by default is 8192 bytes. You may only require a string to be 10 characters long but when you use a String definition you need to be aware you are getting much more than you bargain for. While this may not be an issue in most cases, when you move that string definition back into an existing COBOL data type of PIC X(10) and there is data beyond the 10th character, it will be lost due to truncation. The developer needs to be aware of issues such as this when intermixing the data types. Users also have to be aware that the COBOL runtime is performing ANSI to Unicode conversions.

The table below gives the NetCOBOL for .NET data type that corresponds to the .NET data types. It also states whether the usage type is VALUE or REFERENCE and gives a brief description of the data type. You can locate the table in the Visual Studio .NET documentation after you have installed the Fujitsu NetCOBOL for .NET compiler. Search the Fujitsu NetCOBOL documentation for "COBOL Representations". It may be a good idea to locate and print this table and keep it handy as a reference.

For additional information, see the table in the topic "Introduction to the .NET Framework Class Library" in the Visual Studio .NET documentation for a mapping of the .NET types to other languages such as Visual Basic and C# - a lot of the .NET Framework documentation uses the Visual Basic and C# data type names when describing an item's type.
 

Category  .NET Type COBOL Equivalent    USAGE Type Description
Integer  Byte USAGE BINARY-CHAR UNSIGNED VALUE 8-bit unsigned integer (*2)
SByte OBJECT REFERENCE
(System.SByte)
(non-CLS compliant type)
VALUE 8-bit signed integer (*2)
Int16 PIC S9(4) USAGE COMP-5 VALUE 16-bit signed integer
Int32 PIC S9(9) USAGE COMP-5 VALUE 32-bit signed integer
Int64 PIC S9(18) USAGE COMP-5 VALUE 64-bit signed integer
UInt16 OBJECT REFERENCE
(System.UInt16)
(non-CLS compliant type)
VALUE 16-bit unsigned integer (*2)
UInt32 OBJECT REFERENCE
(System.UInt32)
(non-CLS compliant type)
VALUE 32-bit unsigned integer (*2)
UInt64 OBJECT REFERENCE
(System.UInt64)
(non-CLS compliant type)
VALUE 64-bit unsigned integer (*2)
Floating-point Single USAGE COMP-1 VALUE Single-precision floating-point value
Double USAGE COMP-2 VALUE Double-precision floating-point value
Logical  Boolean OBJECT REFERENCE
(System.Boolean)
VALUE Dedicated boolean type (True or False) (*2)
Other Char PIC N VALUE Unicode 2-byte character
Decimal OBJECT REFERENCE
(System.Decimal)
VALUE Monetary value (*2)
IntPtr OBJECT REFERENCE
(System.IntPtr)
(non-CLS compliant type)
VALUE struct IntPtr (*2)
UIntPtr OBJECT REFERENCE
(System.UIntPtr)
(non-CLS compliant type)
VALUE struct UIntPtr (*2)
DateTime OBJECT REFERENCE
(System.DateTime)
VALUE Date and time value (*2)
Enum You cannot define an enum in COBOL.However, you can reference enums by including the enum in the REPOSITORY paragraph, and use the syntax:
element-name OF enum-name
VALUE Enumerated integer data type
struct You cannot define a struct in COBOL.However, you can reference struct as an OBJECT REFERENCE. VALUE Group data type
Class Objects Object OBJECT REFERENCE
(System.UIntPtr)
REFERENCE Reference to an object (*2)
String OBJECT REFERENCE
(System.String)
(*1)
REFERENCE Unicode (2-byte) b-string (*2)

*1 The NetCOBOL for .NET compiler defines implicit conversions from alphanumeric and national data types to CLR strings. For alphanumeric data, an additional conversion between UTF-8 and UCS-2 is performed.

*2 As indicated in the third column, the NetCOBOL for .NET compiler treats these items as objects, not as COBOL data.

Wrap-Up

Interacting with the .NET data types from your original COBOL data types may seem a bit frustrating at first. The best method I found to determine how all this fits together is to create a Console solution. Have fields that will be accepted from the console defined in Working Storage using the COBOL data types. Next, define equivalent variables in Working Storage using .NET data definitions. Move the variables from the COBOL data types to the .NET defined variables. Experiment with different PIC configurations to see how each interacts with the .NET data types. The attached project provides a template for you to experiment with.

Happy Coding!

Next Recommended Readings