COBOL Translation Toolkit (CORECT)
Technical Architecture Overview
Document Version 1.2

This report outlines the automatic conversion strategies adopted by Software Mining's COBOL Translation Toolkit.
 

The following notes highlight some of the differences in approach to database systems, between COBOL applications and equivalent applications programmed in Java and Borland Delphi which utilize Database Management Systems such as ORACLE.

The following topics are addressed:

All Registered Trademarks Acknowledged

FILE DESCRIPTION (FD) SECTION

The system uses the record descriptions in the FD section of COBOL programs to build an internal model of the record data-definition. The internal model is then utilized to generate record schemas in SQL Data Definition Language which can be imported to any SQL  RDBMS systems.   

In addition to the SQL schemas, a set of java classes are also generated providing the sole means of access to the database records. These classes can effectively be viewed as a layer on top of entity beans within J2EE architecture. The system is also capable of 'beanifying' all such classes for implementation of the final application within EJB framework. The migrated programs will require the inclusion of relevant include files for all the associated records. This topic is further covered in ACCESSING RECORDS.

The toolkit requires that the FD descriptions be provided in detail for every record. This is one of the primary requirements for a successful translation. It is not acceptable for the FD section to contain a FILLER definition, and the actual fields be defined within the working storage section. In such circumstance an additional FD include file is needed to be generated manually - describing the structure of the files. 

CORECT is capable of deducing the full FD description from several programs provided that the sum of the programs contain the total FD description. e.g. from the following descriptions within 2 COBOL programs

Program-1 : ...

FD personnel-file.

01 personnel.

05 id pic 9(5).

05 forename PIC X(10).

05 filler PIC X(20).

...

Program-2 : ...

FD personnel-file.

01 personnel.

05 id pic 9(5).

05 filler PIC X(10).

05 surname PIC X(20).

it can deduce the correct data-definition (written in SQL DDL) :

CREATE TABLE personnel (id INTEGER, forename CHAR(10), surname CHAR(20)).

USE OF DIRECTORIES FOR ORGANISATION OF DATA

Some systems utilize directories to sort data. For example, when the personnel data may be associated with different areas, (US, UK  and France), organized into the 3 data-files:

/personnel/US.dat

/personnel/UK.dat

/personnel/France.dat

For such systems, a facility has been provided to define an additional field (e.g. AREA CHAR(30)) in the target record schema. Subsequently the primary index of the new records will be altered to contain the additional field, and all future search statements on the record will be programmed with reference to the new field.

MULTI-SCHEMA FD SECTION

COBOL files with multiple record (01) entries will be broken down to relevant number of record schemas. For example the file:

will be broken down to 2 record schemas in the target database, namely order-header and order-line schemas.

The indexes associated with the file will be lined up with the new record schemas.

ARRAY (TABLE) HANDLING

COBOL allows definition of fields as single or multi-dimensional arrays. ANSI SQL standard does not provide for arrays at all. All single and multi-dimensional fields will be split into two files. E.g.

Program-1 : ...

FD personnel-file.

01 personnel.

   05 id pic 9(5).

   05 forename PIC X(10).

   05 surname PIC X(20).

   05 address PIC X(20) Occurs 3 times.

will be converted to the following 2 records:

Record : personnel,

fields :

id Integer,

forename char (10),

surname char (20).

Record : personnel_mx

fields:

id Integer,

indx integer,

address char (20).

Whilst on the program side, the first element of address field is still accessed as personel.address[1] - the database wrapper classes will access the variable as:

SELECT personnel_mx WHERE id = personnel.id AND indx = 1;

Conversion of variable arrays, i.e. those defined in COBOL's working storage section, is more straight forward. Java and Delphi both support single and multi dimensional arrays. 

Due to the limitations of most target languages, variable length arrays as defined by COBOL's OCCURS DEPENDING ON type statements require manual adjustment prior to the conversion process.

REDEFINITIONS

Handling redefinition is one of the most difficult tasks achieved by CORECT. Redefinitions are often utilized to meet one of 2 objectives:

• Reduction in memory utilization of the application.
• Use of different data organization to simplify / enhance the programming code.

Redefinitions of data sections is not supported in Java or DELPHI, or within any ANSI SQL databases. The redefinitions are handled by CORECT by reducing the fields to the lowest common denominators, and replacing all subsequent entries to the lowest common denominator. For example in programs with the following data :

01 personnel.

   05 id pic 9(5).

   05 name PIC X(30).

   05 detailed_names REDEFINES name.

   05 forename PIC X(10).

   05 surname PIC X(20).

all references to name will be replaced by forename and surname .

This technique applies to all data sections including the FILE and WORKING STORAGE sections.

If a data entry redefines parts of its structures different - non-compatible forms, i.e. where no assumption can be made to the nature of the lowest common denominator -  then:

• When the purpose was reduction memory utilization - the system can be told to ignore the particular redefinition.
• otherwise - manual intervention is required to clarify the final layout  of the  record structure.

DATE PROCESSING - Year 2000 Compliance.

All date/time function calls will be translated to equivalent target language statements. Furthermore, the data-type of all variables which are explicitly equated to Date/Time functions, will be converted to the relevant target-language Date/Time data-type. E.g - java.sql.Date or java.sql.Timestamp .

The system also provides a facility to change the target  record schemas, hence allowing character variables which have been missed out by the system to be converted to Date or Time data-type. 

Also, as all database access is achieved through object wrappers - further correction to data-types can be also catered for within this layer. Finally, all unresolved date variables will be trapped by strong type-checked compilers provided with JAVA or Delphi.

SCREEN SECTION

COBOL compilers provide different means for displaying data on screen.  Some provide facilities for defining screens within a 'Screen Section' or similar approaches (equivalant to a static screen desciption). screens may also be dynamically defined within the 'Procedural Section' of an application.

Both approaches are translated to screen descriptions with predefined elements. I.e. A Java class is generated containing the screen elements placed at positions equivalent to the original COBOL application.

In the translation, the main part of the program containing the business logic, variable definitions, and etc are translated to a separate class inheriting from the original screen class.

The generated screens are formatted in such way to allow them to be edited at design time using popular IDEs such as Borland JBuilder, Symantec Visual Cafe - as well as Borland Delphi or Kylix products. 

For java server applications, an equivalent  HTML is also generated containing same components as the Java class.

Migration from Java applets/applications to HTML/Servlet application can be achieved simply by accessing different sets of libraries.

The character based screens of COBOL applications can be broken down to the following minimal set of GUI components of Java or Delphi :

Note that all edit boxes are disabled (do not allow user updates) unless/until the original program issues an ACCEPT type statement.

Where possible, screen items are grouped together within panels - so that users can move between the Edit or List Boxes using the mouse or the tab keys. Generally the layout and behavior of the screens closely resembles the original application.

All screens will also contain an 'OK' Button defaulting to ENTER or RETURN key mapping of the original program.

Function keys (or PF Keys) for some systems are supported for Java Applets/Applications, and Delphi applications. Java servlet applications require additional designs.

REPORT SECTION

Generally there are two methods by which COBOL programs generate reports.

The first is by definition of the file within the FD section and its assignment to printer or an output file. The report is then generated using the COBOL WRITE statement. An equivalant approach has been undertaken within CORECT.

The second method is by through the REPORT SECTION entry as defined by COBOL 85 standards. Such reports - typically contain positioning information - are translated to an equivalent form using supplied reporting libraries. 

DECLARATION SECTION

The declaration sections are often utilized as error handling routine for opening / closing file records. In DBMS systems, the DBMS is responsible for handling such events and many declarations may be ignored.

Other uses of declaration sections will be catered for.

ACCESSING RECORDS

When a COBOL program READs a record, the information in the record will be kept in the memory, and will not be written to the file until a WRITE or REWRITE statement.

For data integrity reasons, migrated programs will read the record into a pre-prepared classes / object wrapper record buffer after each READ statement is encountered.

E.g. the following COBOL statements for reading the personnel record :

will be converted to Delphi equivalent of :

Personel personnel ; // Define an instance of object wrapper 

personnel.id = 123;

personnel.findByKey1(">");  // where id => 123 will be implemented interally

personnel.next();           // read the next record into object wrapper 

personnel.surname = ws_surname; 

personnel.write();         // Write data from object wrapper to Database

In this approach all the SQL code for accessing an record is held outside main program logic - within one class. 

The advantages of this approach is that the data-access layer can be modified independently of the program logic. This can be done to gain many advantages: 

• the SQL to be optimized, or brought out of the object and implemented as stored procedures. 
• the data-access classes can be rewritten to obtain information from another source. For example, the back may be kept in COBOL, and accessed via CORBA.
• The data access layer can be re-implemented as J2EE entity beans. 

Procedural Code COBOL vs Event Driven Java / Delphi

CORECT does not attempt to in re-write  procedural code as event driven. Such conversion cannot be successfully achieved without some level of manual intervention. For example, once a COBOL program comes across a statement expecting user input from screen, the program waits at the data-entry (ACCEPT var1 FROM ...) point until user presses the RETURN key. A similar behavior is simulated in the generated Java / Delphi programs. 

However, If there is a business or technical justifications to change a particular program to event driven model - most of such calls can be manually modified to take such form. 

Also, during further enhancements of  a particular program - both models can be used without any downside. 

EMBEDDED SQL

Java and  Delphi support database access through SQL statements. However, there are some differences.

The following is a summary of migration rules CORECT will utilise:

• Host Variables: Supported through definition of normal variables;

• Null indicators: Java - In data-access layer - all fields are implemented as primitive Object types, e.g. 'Integer' and not 'int'.  In delphi IsNull method will be used to determine values. 
• SQL Prepare - Execute Statements: Direct Equivalents in Java and DELPHI.
• Transaction Processing: Supported in all programming languages.
• SQLCode include file and file-handling. COBOL's use of SQLCODE include file to determine the result of last operations is not supported by either of these programming languages. Software Mining provides additional libraries which can work with a predefined SQLCode class. 

CORECT will attempt to parse all the SQL statements to remove and substitute Host-variables and null-variables access with the appropriate method provided in the target language. When complex statement which cannot be handled by the parser are encountered, they will be rewritten without any modifications.

Embedded CICS

BMS screens are translated to Java / HTML or Delphi similar to handling of Screen Section definitions.

CORECT can read a range of CICS statements - and translate them into calls made to Software Mining java-libraries. These libraries can rely on IBM Java-CICS gateway or simplified in house libraries.

Generated Application Architecture.

A COBOL Program typically utilizes a main module and a number of COPY Files. The copy files provide means of sharing File Descriptions, Working Storage (internal variable) structures and definitions and other definitions. The copy files can also be used in conjunction with the main program module - similar to a library file.

The program module often has references to screens and reports, and need to define the data-files that it needs to access.

The following diagram illustrates the overall structure of a typical Cobol module.

During the translation of the above program into Java - several classes are created. The following diagram illustrates the overall classes created during the translation of the above program.