| 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!
Source Code: DataType.zip
Author: You can reach Rick at
rmalek@fsw.fujitsu.com
|