From COBOL Data-Types to Java/C# Primitive data-types
Where possible
This is a continuation of my earlier blog - asking what would be the desirable characteristics of a COBOL program - rewritten in OO Java or C#. I followed that post with a description of first steps to go from Structured data definitions into an Object-Oriented design.
In this posting, we'll look at what can happen to all the data-items, COBOL redefinitions, COMP variables and etc.
COBOL data structures are hierarchical, contains stuff un-supported in Java and C#: for example: COMP, REDEFINE and GROUP accessor’s, and often the storage and display values are different.
When moving to java - none-of this is supported. Should there be a new representation of ALL data-classes, or can one work with primitive data-types?
We found we get the best result by treating each declaration separately: First let the translator clean-up as much as possible, remove any unused groups, remove any redefines which can be normalized, re-use structures where possible, (e.g. merge WS-INVOICE and LK-INVOICE even if couple of the fields are named differently, or have field/filler mixes ….) and use only the 1 version, Also, you have to Use good design patterns. We translate to a layered Object Oriented design. Data go into (serializable) data-classes (with no business logic), persistent objects go into object-relational form etc, and business logic goes into a separate business-process layer. Try to use java primitive data-types unless it is . So comparison between two numbers become:
If (order.Value == 10) { … }
But comparison between two strings (of equal length) become
If (company.getName().equals(“….”)
Finally, the use esoteric representation of COBOL Variables only as a last step. For example:
If (company.equals( …. )) {
When “equals” is a specialized method on the data-classes. Data-base Access.
It is also worth nothing that if we can remove the GROUP accessors, the operations on Records (e.g MOVE COMPANY to ...), REDEFINES and etc, then it is possible to use primitive data-types instead of using to a customized data-structures,
Weather the data is maintained within VSAM, IBM CICS, IDMS, IMS , UNISYS DMS II, BULL – one can use a “Object-Relational” form for access all of them. Lets take an example. For VSAM we may have something like:
READ NEXT COMPANY
In Unisys DMS-II this would be something like
FETCH COMPANY ...
In IBM CICS this would be:
EXEC CICS READ FILE(“COMPANY”) .
All of the above can be translated into some form of
company.read();
Where similar to “Hibernate” framework in Java - the “company” class takes care of ALL of communication with database.
(I know I have used simple examples here, and there are a lot more complicated cases, but hey, can’t give away all the company IP)