Mainframe Migration

COBOL to Java
Whitepaper
Contents
CONTENTS ....................................................................................................................................... 2
1. INTRODUCTION ............................................................................................................................ 3
1.1. A FIRST LOOK INTO TRANSLATION ...............................................................................................4
2. OBJECT ORIENTED TRANSLATION ............................................................................................. 6
2.1. ARCHITECTURE OVERVIEW ........................................................................................................6
2.1.1. Online/CICS ..................................................................................................................6
2.1.2. Batch ............................................................................................................................7
2.2. BASIC MAPPING .......................................................................................................................7
2.3. DATA ACCESS LAYER................................................................................................................8
2.3.1. Database Access ..........................................................................................................8
2.3.2. Sequential File Access................................................................................................. 10
2.3.3. VSAM File Access ....................................................................................................... 10
2.4. BUSINESS L OGIC LAYER .......................................................................................................... 11
2.4.1. Data Remodeling......................................................................................................... 11
2.4.2. Code Restructuring...................................................................................................... 13
2.5. PRESENTATION LAYER ............................................................................................................ 14
2.6. FRAMEWORK ......................................................................................................................... 16
3. JCL TRANSLATION ..................................................................................................................... 17
3.1. BASIC MAPPING ..................................................................................................................... 17
3.1.1. Filename Translation ................................................................................................... 17
3.1.2. Program Name Translation .......................................................................................... 17
3.1.3. Utilities........................................................................................................................ 17
3.2. CODE SAMPLE ....................................................................................................................... 18
4. MAINTENANCE ........................................................................................................................... 19
4.1. U NDERSTANDING .................................................................................................................... 19
4.2. R E-ARCHITECTING .................................................................................................................. 20
4.3. MONITORING ......................................................................................................................... 20
5. TRANSLATION P ROCESS ........................................................................................................... 22
5.1. THE P ROCESS ....................................................................................................................... 22
5.2. THE P RODUCT ....................................................................................................................... 24
6. SUMMARY................................................................................................................................... 25
1.Introduction
Growing maintenance fees, scarcity of trained developers, expected end-of-life announcements,
cumbersome deployment processes, platform dependencies – these are just a few reasons
companies are migrating from legacy Mainframe COBOL applications to modern Java solutions.
Whether migrating management support systems, operations infrastructure or reporting
applications, the COBOL to Java migration process is usually highly complex, risky, expensive
and time consuming.

CTU (COBOL to Universal), is a product that transforms a Mainframe (MF) based legacy
application from COBOL to Java, producing object oriented Java / C# that can be easily
maintainable and can be efficiently integrated with other Java / C# applications.

CTU support the full environment of MF based COBOL application, including data bases(e.g.,
DB2, IDMS, IMS) and VSAM, TP monitors (e.g., CICS), JCL, utilities (e.g., IDCAMS) and SORT.

CTU is a fully automated solution that captures the entire source base of the application,
automatically migrates it to object oriented Java / C#. The resulting code has the exact
functionality of the migrated application and can easily be tested and implemented in production.

CTU provides the following key benefits:

 Automated migration of legacy mainframe application on their entirety

 Easy to use and automated tool that can be used multiple times
 Resulting code is object oriented, understandable and can be maintained and fully
integrated with other Java / C# applications

CTU provides significant cost savings in hardware and software (no need for emulation software
solution) and positions the IT department for continued growth and success.

This White paper provides a detailed analysis of the methodology used by BluePhoenix to
architect the product and develop it. It provides the reader with deep understanding about the
capabilities of the product and its merits, taking special emphasis on its object oriented translation
methodology.

Copyright ©2012, BluePhoenix Solutions, Inc 3

 1.1.A First Look into Translation
Translating a procedural language like COBOL to object oriented Java presents several
challenges. The translation process was designed with the following requirements in mind:
o The resulted application should work exactly the same as the original application and
produce exactly the same results.
o The resulting application should be maintainable and follow the object oriented concepts
and paradigms: encapsulation, abstraction, modularization, loose coupling, etc..
o The resulting application should perform the same or better than the original one on the
open systems platform.
The following example shows how a simple COBOL application with sequential file processing is
translated to Java.

IDENTIFICATION DIVISION. package com.bphx.ctu.samples.files;

PROGRAM-ID. FILES.
ENVIRONMENT DIVISION. import bphx.ctu.core.*;
INPUT-OUTPUT SECTION. import bphx.ctu.io.*;
FILE-CONTROL. import bphx.ctu.util.*;

SELECT PROFILES ASSIGN TO PROFILEFILE. public class Files {

SELECT WEDDINGS ASSIGN TO WEDDINGFILE
ORGANIZATION IS SEQUENTIAL. private static final String PROGRAM_ID = "FILES";
DATA DIVISION.
FILE SECTION.

FD PROFILES. public ProfilesTO profilesTO = new ProfilesTO();

01 PROFILES-RECORD. public ProfilesDAO profilesDAO = new ProfilesDAO();
05 NAME PIC X(20).
05 SURNAME PIC X(20).
05 MARITAL-STATUS PIC X(01) VALUE 'M'.
88 MARRIED VALUE 'M'.
88 SINGLE VALUE 'S'.

FD WEDDINGS. public WeddingsTO weddingsTO = new WeddingsTO();

01 WEDDINGS-RECORD. public WeddingsDAO weddingsDAO = new WeddingsDAO();
05 NAME PIC X(20).
05 SURNAME PIC X(20).

WORKING-STORAGE SECTION.
protected boolean endOfFile = false;
01 END-OF-FILE PIC X(01) VALUE 'N'.
88 EOF-Y VALUE 'Y'.
88 EOF-N VALUE 'N'. protected int marriedPeople = 0;
01 MARRIED-PEOPLE PIC 9(5) COMP VALUE '0'.
public void run() {
try {
mainSubroutine();
} catch (ReturnException re) {
// normal termination of the program
}
}

Copyright ©2012, BluePhoenix Solutions, Inc 4

 private void mainSubroutine() {
openFiles();
processFiles();
closeFiles();
}

PROCEDURE DIVISION. private void openFiles() {

0100-OPEN-FILES. // OPEN PROFILES FILE
* OPEN PROFILES FILE profilesDAO.open(OpenMode.READ, "Files");
OPEN INPUT PROFILES. // OPEN WEDDINGS FILE
* OPEN WEDDINGS FILE weddingsDAO.open(OpenMode.WRITE, "Files");
OPEN OUTPUT WEDDINGS. }

0200-PROCESS-FILES. private void processFiles() {

* READ RECORDS FROM PROFILES FILE AND // READ RECORDS FROM PROFILES FILE AND
* WRITE THEM INTO THE WEDDING FILE IF MARRIED // WRITE THEM INTO THE WEDDING FILE IF MARRIED
PERFORM UNTIL EOF-Y while (!endOfFile) {
READ PROFILES profilesTO = profilesDAO.read(profilesTO);
NEXT RECORD if (profilesTO.getRetCode() == FileStatus.EOF) {
AT END SET EOF-Y TO TRUE endOfFile = true;
NOT AT END } else {
IF MARRIED if (profilesTO.maritalStatus.isMarried()) {
PERFORM 0800-WRITE-WEDDING-RECORD writeWeddingRecord();
ADD 1 TO MARRIED-PEOPLE marriedPeople = marriedPeople + 1;
END-IF }
END-PERFORM. }
* DISPLAY NUMBER OF MARRIED PEOPLE }
DISPLAY 'MARRIED PEOPLE:' MARRIED-PEOPLE. // DISPLAY NUMBER OF MARRIED PEOPLE
AdfSystem.trace("MARRIED PEOPLE:", marriedPeople);
}

0700-CLOSE-FILES. private void closeFiles() {

* CLOSE FILES // CLOSE FILES
CLOSE PROFILES. profilesDAO.close();
CLOSE WEDDINGS. weddingsDAO.close();
GOBACK. throw new ReturnException();
}

0800-WRITE-WEDDING-RECORD. private void writeWeddingRecord() {

MOVE CORRESPONDING PROFILES-RECORD TO weddingsTO.setName(profilesTO.getName());
WEDDINGS-RECORD. weddingsTO.setSurname(profilesTO.getSurname());
WRITE WEDDINGS-RECORD. weddingsDAO.write(weddingsTO);
}
}

Translated code is readable and maintainable, following Java standards and object oriented
concepts. COBOL business logic and comments are preserved and employees familiar with the
original legacy application can easily understand the translated one. In this example, the reader
can notice the separation between business logic (the program) and data layer (ProfilesDAO,
ProfilesTO, WeddingsDAO, WeddingsTO).
The next chapters provide more details about the architecture and the set of rules that are the
base of the CTU object oriented translation product.

Copyright ©2012, BluePhoenix Solutions, Inc 5

2.Object Oriented Translation
The BluePhoenix automated code/data migration process re-architects the code into three layers:
a Data Access Layer (files and database access), a Presentation Layer (screens), and a
Business Logic Layer (programs).

2.1.Architecture Overview
2.1.1.Online/CICS
The converted online/CICS application is a 3-tier application, running in an application server with
a thin client in the browser. The general architecture is as follows:

Database Server Application Server Thin client

Data Access Object Layer

(converted from COBOL)

Business Logic Layer

Presentation Layer
JSF, Java Beans
Java classes
Web Browser
(DAO)

Hibernate HTTP(S) HTML

Oracle, DB2
CSS
JavaScript

CTU Framework Support

Each COBOL program will be converted to a Java class providing the same functionality exposed
as a service (Business Logic Layer). All database/files operations from the original COBOL code
are externalized in DAO classes and Hibernate mapping files (the Data Access Layer). The
Presentation Layer is generated by converting the legacy screens to JSF (Java Server Faces).
These layers can be implemented via a number of products in order to provide the robustness
necessary for high volume, high uptime applications. The typical overall high level architecture is
depicted in the following diagram:

Copyright ©2012, BluePhoenix Solutions, Inc 6

 The application can be installed on any operating system where Java runs and on any standard
JavaEE server:
o Operating systems:
o Windows
o Unix / Linux
o z/OS
o Application servers:
o WebSphere
o WebLogic
o Tomcat
o JBoss
o GlassFish

2.1.2.Batch
The converted batch application doesn’t depend on any Java EE APIs, so it can run as a normal
Java application. For running batch applications, BatchSession implementation is used,
keeping information regarding the JCL context.

2.2.Basic Mapping
CTU includes a very strong mapping capability that produces an object oriented model that can
best represent the procedural code.
This mapping component produces code that can be further refined and refactored after the
migration project, to better fit into the overall framework and architecture of the system.
The following table illustrates the basic mapping from the procedural COBOL language to the
object oriented Java (in this case) language:

Procedural Language Object Oriented Language

(COBOL) (Java)
Legacy Program Java class
Paragraph within program Java method
File Data Access Object (DAO)
File Record Definition Data Transfer Object (DTO)

Table Data Access Object (DAO)

Data Transfer Object (DTO)
Copybook Data classes
Working Storage Data fields: class properties
Group items: class methods
Redefines: Java classes
Map Web client (JSF, beans)

In some cases specific COBOL statements can be translated to different Java objects (e.g., Table
to DAO / DTO). CTU includes the logic that enables it to make the right decision and use the
most relevant object which best fits the overall architecture of the full system, taking account such
things as performance and maintainability.

Copyright ©2012, BluePhoenix Solutions, Inc 7

2.3.Data Access Layer
The logic used to handle files and databases is decoupled from the main COBOL structure. To do
this, the DAO/DTO design pattern has been implemented.
Data Access Objects (DAO) assures the communication with external data (files & databases)
and Data Transfer Objects (DTO) are used to transport data between main COBOL program and
external data. All the time DAO is using DTO and only DTO to communicate with the program.

Using this approach the resulted code is much easier to understand, it offers an easy ways to
maintain the code. More than that, DAO and DTO code can be reused for future enhancements
made in Java. Modifications can be made to the DAO implementation without altering other
decoupled modules of the application.

2.3.1.Database Access
For database access, Hibernate is used to facilitate usage of multiple database engines. All used
queries in a DAO are externalized to a Hibernate XML mapping file, further simplifying
maintenance of the queries.
Database DTOs are created from the SQL table definitions.

2.3.1.1.SQL Cloning
CTU also handles cloning at the SQL level. This means that if COBOL code contains more than
one SQL statement of the same type, even in different programs, only one Java method will be
created inside the specific DAO. The DTOs contain all the information related to a specific SQL
table and the DAOs represent a collection of different SQL statements used in COBOL project
related to that SQL table.

2.3.1.2.Code Sample
For the following DDL, CTU creates four artifacts: DAO, TO, Hibernate class definition, Hibernate
queries.
CREATE TABLE ACCOUNT
(ACCOUNT_ID VARCHAR(8) NOT NULL
,SURNAME VARCHAR(20)
,FIRST_NAME VARCHAR(20)
,SOLD INTEGER
,CURRENCY_SIGN VARCHAR(3)
,ACCOUNT_LEVEL CHAR(1)
,BONUS_INTERVAL SMALLINT
,PRIMARY KEY (ACCOUNT_ID)
)

Copyright ©2012, BluePhoenix Solutions, Inc 8

 DTO class: transfer object used in all operations with ACCOUNT DAO.
public class AccountTO {

private DBAccessStatus dBAccessStatus;

private AccountID sql_id = new AccountID();
private int sold;
private char accountLevel;
private short bonusInterval;
private AdfVarchar surname = new AdfVarchar(20);
private AdfVarchar firstName = new AdfVarchar(20);
private AdfVarchar currencySign = new AdfVarchar(3);

... //getters and setters

}

DAO class: contains all the operations with the ACCOUNT table, from all programs.
public class AccountDAO {

public ScrollableResults sqldemoAcctCur;

public AdfSqlca sqlca = new AdfSqlca();

public static DBAccessStatus deleteByAccountIdRec(AdfVarchar accountId) { ... }

public DBAccessStatus openSqldemoAcctCur() { ... }
public AccountTO fetchSqldemoAcctCur(AccountTO accountTO) { ... }

public static DBAccessStatus updateByAccountIdRec(short bonusInterval, AdfVarchar

accountId) {
AdfSqlca sqlca = new AdfSqlca();
DBAccessStatus dbStatus = new DBAccessStatus();
try {
Session session = HibernateSessionFactory.current().getSession("Account");
Query query =
session.getNamedQuery("com.bphx.ctu.samples.sqldemo.data.dao.AccountDAO.updateByAccountId
Rec");
query.setShort("bonusInterval", bonusInterval);
query.setParameter("accountId", accountId.clone(), AdfTypes.VarCharType());
if (sqlca.collectAffectedRecords(query.executeUpdate()) == 0) {
sqlca.collect(AdfSqlError.NO_UPDATED_RECORDS);
}
dbStatus.setSqlCa(sqlca);
}
catch (HibernateException ex) {
dbStatus.setException(ex);
}
return dbStatus;
}
}

Hibernate class definition for ACCOUNT table.

<hibernate-mapping>
<class name="com.bphx.ctu.samples.sqldemo.data.to.AccountTO" table="ACCOUNT">
<composite-id name="sql_id" class="com.bphx.ctu.samples.sqldemo.data.id.AccountID">
<key-property name="accountId" type="bphx.ctu.lang.hibernate.AdfVarcharType">
<column name="ACCOUNT_ID" length="8"/>
</key-property>
</composite-id>
<property name="sold" type="integer" not-null="false">
<column name="SOLD"/>
</property>
<property name="accountLevel" type="character" not-null="false">
<column name="ACCOUNT_LEVEL"/>
</property>
<property name="bonusInterval" type="short" not-null="false">
<column name="BONUS_INTERVAL"/>
</property>
<property name="surname" type="bphx.ctu.lang.hibernate.AdfVarcharType" not-
null="false">

Copyright ©2012, BluePhoenix Solutions, Inc 9

 <column name="SURNAME" length="20"/>
</property>
<property name="firstName" type="bphx.ctu.lang.hibernate.AdfVarcharType" not-
null="false">
<column name="FIRST_NAME" length="20"/>
</property>
<property name="currencySign" type="bphx.ctu.lang.hibernate.AdfVarcharType" not-
null="false">
<column name="CURRENCY_SIGN" length="3"/>
</property>
</class>
</hibernate-mapping>

Hibernate queries: all the queries for ACCOUNT table will be in a Hibernate mappings file.
<hibernate-mapping>
<sql-query
name="com.bphx.ctu.samples.sqldemo.data.dao.AccountDAO.updateByAccountIdRec ">
<query-param name="bonusInterval" type="short"/>
<query-param name="accountId" type="bphx.ctu.lang.hibernate.AdfVarcharType"/>
<synchronize table="ACCOUNT"/>
update ACCOUNT set
BONUS_INTERVAL = :bonusInterval
where
ACCOUNT_ID = :accountId
</sql-query>
</hibernate-mapping>

2.3.2.Sequential File Access

For sequential file access, DAOs are using framework calls to IFileOperations in order to
emulate the COBOL operations.
Files DTOs are created from COBOL variables associated with each file descriptor.
The same cloning approach as for databases is used for the file access layer.

2.3.3.VSAM File Access

VSAM files are migrated to a relational database model. During conversion process, all VSAM
records are analyzed and the best layout is chosen. For each layout chosen, a DDL is generated.
VSAM DAOs are using Hibernate object relation mapping. The queries from .hbm.xml files are
written in HQL language, further abstracting the database usage.

Copyright ©2012, BluePhoenix Solutions, Inc 10

2.4.Business Logic Layer
Each COBOL program is converted to a Java class. This class encapsulates all working storage
fields and paragraphs, exposed as a service to the main entry point in run() method.
For example:
public class CobolProgram{
protected workingStorageField1;
protected workingStorageField2;
...

public static CobolProgram getInstance() {...}

public CobolProgramTO run(ExecContext execContext, CobolProgramTO cobolProgramTO){...}

public void run(ExecContext execContext, byte[] dynamic_dfhcommarea){...}

public void run(){

//call first paragraph
}

private void paragraph1() {...}

private void paragraph2() {...}
}

2.4.1.Data Remodeling
COBOL data structures are analyzed and remodeled to meet the following requirements:
 Encapsulation
 Reuse
 Readability
 Small memory footprint for better utilization

2.4.1.1.Handling nested data definitions

Deeply nested COBOL records are collapsed to the primary data fields. The information will be
kept only in those fields. When a group access is needed, a method will be generated that knows
how to read and write information from the primary data fields.
01 PERSONAL-INFO. public class PersonalInfo {
05 ACCT-INFO. protected char acctType;
10 ACCT-TYPE PIC X. protected String name;
10 NAME PIC X(30). protected short age;
10 AGE PIC 9(3). protected int acctId;
10 ACCT-ID PIC 9(7). protected long amount;
10 AMOUNT PIC 9(12). protected AdfDecimal travelExpenses;
05 ADDITIONAL-INFO. protected AdfDecimal shoeSize;
10 TRAVEL-EXPENSES PIC 9(6)V9(2). protected double shirtSize;
10 SHOE-SIZE PIC 9(2) COMP-3.
10 SHIRT-SIZE PIC 9(2) COMP-2. //Group methods
public void setAcctInfo(char[] buf) {
//marshalls from char[] to fields
...
}
public char[] getAcctInfo() {
//marshalls from fields to char[]
...
}
}

Copyright ©2012, BluePhoenix Solutions, Inc 11

 2.4.1.2.Handling copybooks
Each copybook that contains only data will be translated to a class. Copybook classes are reused
as a single class across the entire application.

2.4.1.3.Data cloning
When a new COBOL program is developed and uses same data structures as an old program s,
the developer has two ways to use the existing information related to data information.
First and the most clever way is to move the data definition from the old COBOL program into a
copybook and use the copybook both in old and new COBOL programs.
But most of COBOL developers are just copying the COBOL data definitions in the new program.
Complex COBOL systems can have a lot of these kinds of structures defined again and again in
many programs.
CTU can easily handle both situations and detects data clones. Only one Java class is created
and is used in all places.

2.4.1.4.Handling primitive types

All data types are translated to native Java types. The only exception is decimal type, which is
translated to the CTU Framework class AdfDecimal in order to keep the maintainability of the
resulting code and to assure the same functionality of the converted application.
The following table shows how some COBOL data types are translated to Java:

PIC 9 - PIC 9(4) short

PIC 9(5) - PIC 9(9) int

PIC 9(10) - PIC 9(18) long

PIC X char

PIC X(2) - PIC X(n) java.lang.String

Numeric-edited java.lang.String

Alpha-numeric-edited java.lang.String

9(n)V9(m) bphx.ctu.lang.datatype.AdfDecimal

USAGE IS PACKED-DECIMAL bphx.ctu.lang.datatype.AdfDecimal

USAGE IS COMP-2 double

USAGE IS INDEX int

Copyright ©2012, BluePhoenix Solutions, Inc 12

 2.4.1.5.Handling 88 level – An example of in-depth smart translation
Depending on the usage of an elementary COBOL item which contains 88 level conditions the
structures can have dual translation. They can be converted to Java boolean or to classes.

GRP88 PIC X(1) VALUE 'Y'. boolean / class (depending on the usage)
88 Y VALUE 'Y'.
88 N VALUE 'N'.

GRP88 PIC 9(2). class (enumeration)

88 PERSONAL VALUE 5 THRU 55.
88 COMMERCIAL VALUE 99.
88 OTHER-DATA VALUE 100.

88 levels with multiple values are translated to an enum like class.

88 levels with only two values that can signify a boolean value (Y/N, YES/NO, TRUE/FALSE)
are translated to boolean or to an enum like class, depending on the usage in the programs.
The legacy application is static analyzed and if and only if the usage of that field contains only
approved values, then a Java native boolean type is used for translation.

2.4.2.Code Restructuring
Each paragraph becomes a private method in the Java program class. Program structure and
comments are preserved during conversion, simplifying maintenance.
During code restructuring, program flow is normalized and GO TOs are removed.

2.4.2.1.Program normalization
Program normalization is a code transformation that replaces GO TOs and fall through behavior
with a statically determined code. The transformation involves minimal changes to the program
structure, and it’s not changing the original conditional statements or constructs.
As an example, let’s see how a simple processing loop is transformed:
P1.
PERFORM READ-INPUT THRU PROCESSING-END UNTIL EOF.
STOP RUN.

READ-INPUT.
DISPLAY "READING INPUT FILE"
* AT END, SKIP PROCESSING
IF EOF
GO TO PROCESSING-END.

PROCESSING.
* DO SOME PROCESSING
DISPLAY "PROCESSING".

PROCESSING-END.
DISPLAY "DONE".

For each “perform range” (e.g. statements like PERFORM READ-INPUT THRU PROCESSING-
END), a method (rngReadInput) is built that will subsequently call the paragraphs that are in the
flow order within the original program. This way, the fall through is ensured. Other perform

Copyright ©2012, BluePhoenix Solutions, Inc 13

 statements will use the same method (if the context doesn’t have a different set of perform
mines).
private void rngReadInput() {
String retcode;
retcode = readInput();
if (!retcode.equals("PROCESSING-END") ){
processing();
}
processingEnd();
}

The GO TO statements within the paragraphs are transformed to return "paragraph_name"

(return "PROCESSING-END"), and the flow is rebuilt within the calling “perform range” method.
The implicit GO TOs within the subroutine are normalized by building helper control structures:
o While loops for forward or before in the program order GO TOs
o If guarded blocks for backward or after in the program order GO TOs

private String readInput() {

ABOSystem.trace("READING INPUT FILE");
if (eof) {
return "PROCESSING-END";
}
return "";
}
In order to simplify the resulting code, the EXIT type paragraphs and the dead code paragraphs
(both flow and data) are removed.

2.5.Presentation Layer
To maintain the same user experience, BMS Maps are migrated to equivalent web pages. In all
cases, the actual data fed into each new web interface is the same as the data fed into the legacy
screen. When the application screen display logic is executed, the resulting HTML web page
produced mimics the original 3270 screen as closely as possible. The actual screen layouts are
maintained, so users of the application do not have to be retrained.
Legacy screens are automatically converted to standard JSF (Java Server Faces) in order to be
easily deployable in any application server. Each screen is converted into the following
components:
o JSF Facelet (XHTML UI representation) – the View
o Managed Data Bean – the Model (data fields/attributes)
o Static text labels property file (separating content from layout)
As stated, the converted code will preserve the look and feel of the original application. In order to
achieve this, the generated JSF defaults to using fixed-width fonts and absolute positioning of
fields and text labels. The web application will have the same navigational features as the original
one.
PF Keys and return keys are fully supported using JavaScript event handling routines. In addition,
navigation using arrow keys is also supported allowing the user to move from one field to another
just like in the original application (without involving mouse operations or TAB key – although
these are available as well).

Copyright ©2012, BluePhoenix Solutions, Inc 14

 While the migrated screens retain the same screen layout and functionality, the resulting
generated web pages can be structured to take advantage of the more graphic web interface,
such as by customizing style sheets (CSS).

Before conversion

After conversion

Copyright ©2012, BluePhoenix Solutions, Inc 15

2.6.Framework
The migrated Java also references an included framework library. BluePhoenix provides a
framework library to handle common functions that existed in the COBOL language but should
not be directly translatable to the Java / C# language.
The framework has two layers:
 Core layer: contains core concepts and utilities
o Logging: CTU uses SL4J logging library to log all framework events. The amount
of information is configurable
o Configuration: reads from ctu.properties configuration file. Support settings for:
marshalling, locations, implementations (TSQueue, TDQueue, display),
database, Hibernate
o Hibernate and SQL: helpers for database access
o Data types: support data types that don't have equivalent in Java (E.g.:
bphx.ctu.lang.datatypes.AdfDecimal)
o Marshalling: reads and writes byte/char buffers from CTU data types. Support for
EBCDIC to ASCII encoding. Support COBOL REDEFINES
o Sessions: bphx.ctu.core.Session is a core concept of CTU framework,
that keeps the context of the application per thread. Most notable specializations
are: bphx.ctu.batch.BatchSession for batch/JCL running, and
bphx.ctu.tp.TSSession for CICS transaction processing

 Translation layer: emulation of COBOL functionalities

o COBOL: translation of COBOL functions to equivalent Java functions
o Batch: support for JCL, batch session and DD Cards
o Files: support for sequential files
o VSAM: support for VSAM to relational database runtime
o Transaction Processing: support CICS command API, TDQueues, TSQueues,
TP session
o Screens: JSF implementation of screens
The framework can be licensed in source code format and can be further customized and
extended by the client as required.

Copyright ©2012, BluePhoenix Solutions, Inc 16

3.JCL Translation
The aim of the UJM (Universal JCL Migrator) (a part of CTU) is to translate JCL to Java, with the
following guidelines:
1. A one-to-one translation
 Each JOB gets translated to a Java class
 Each PROC gets translated to a Java class
2. The scripts logic is preserved
3. Resulted code is readable and maintainable

3.1.Basic Mapping
Each job class inherits from JobScript and each Proc from ProcScript. These classes
constitute a runtime framework.
Each step becomes an inner class implementation of one of the following:
 ProgStep

 ClassStep
 ProcStep

 Each DD card becomes a call to a setDDCard method or a dataCard method.

o Among other features, setDDCard provided support for GDG files, &&temp files,
DUMMY, SYSOUT= files
o Record length and record format is supported, by the use of meta-data files that
contain record formatting information. These are created for DISP=NEW files and
created/copied/deleted as required by the runtime framework and utility
replacement classes.

3.1.1.Filename Translation
A typical Mainframe DSNAME has the format aa.bb.cc.dd
A typical Unix filename has the format /aa/bb/cc.dd and windows filename has the format
C:\aa\bb\cc.dd
However it is not always practical to simply change all periods to slashes , nor is it always
practical to change all filenames in exactly the same manner.
To solve this issue, UJM supports a powerful rule based filename translation algorithm, allowing
different filename translation rules to be applied to different DSN patterns.
In the code sample below the DSNs AA.AA and BB.BB have been modified by a rule that adds
the ../files/ prefix.

3.1.2.Program Name Translation

UJM uses Program name translation rules that can modify the name of a called program, and
determine if it is called by a ClassStep or a ProgStep. In the code sample below, a call to the
program IKJEFT01 is translated to a call to DbaseRunner (BluePhoenix's equivalent of
IKJEFT01) and it is called via a ClassStep.

3.1.3.Utilities
rd
UJM's runtime framework is supplemented by implementations of the most common IBM and 3
party utilities, such as IKJEFT01, IDCAMS, IEBGENR, IEBCOPY, etc.

Copyright ©2012, BluePhoenix Solutions, Inc 17

 UJM provides its own SORT utility that can be used as a substitute of the Mainframe SORT utility
to great effect.

3.2.Code Sample
The following input file:
//SAMPLE JOB i(ACT),'BPHX'
//*
//OPEN EXEC PGM=ECHO,PARM='SAMPLE CODE'
//SYSOUT DD SYSOUT='*'
//CALLP EXEC P1,ABC=DEF
//DD1 DD DSN=AA.AA,DISP=NEW,DCB=(LRECL=80,RECFM=FB)
//DD2 DD *
Example of multi-line
inline data
//IKJEFT EXEC PGM=IKJEFT01
//SYSTSIN DD DSN=BB.BB,DISP=OLD

Is translated as follows:
import com.bphx.runtime.jcl.*;

public class SAMPLE extends JobScript {

public void runProcess() {
OPEN.run();
CALLP.run();
IKJEFT.run();
}

public ProgStep OPEN = new ProgStep(this, "OPEN") {

public void defineStep() {
setDDCard("name=SYSOUT", "sysout='*'");
perform("ECHO", "SAMPLE CODE");
}
};

public ProcStep CALLP = new ProcStep(this, "CALLP") {

public void defineStep() {
setDDCard("name=DD1", "dsn=../files/AA.AA", "dispStatus=NEW",
"lrecl=80", "recfm=FB");
dataCard("DD2", "Example of multi-line", "inline data");
perform("P1", "ABC=DEF");
}
};

public ClassStep IKJEFT = new ClassStep(this, "IKJEFT") {

public void defineStep() {
setDDCard("name=SYSTSIN", "dsn=../files/BB.BB", "dispStatus=OLD");
perform("DBaseRunner");
}
};
}

Copyright ©2012, BluePhoenix Solutions, Inc 18

4.Maintenance
4.1.Understanding

It is very easy for an employee familiar with the old legacy application to understand the new
translated application source. Readability and maintainability is one of the main capabilities of
BluePhoenix’s Java / C# conversion. The following main goals apply for the migration:
 The general structure of the program is preserved and you can easily navigate from
legacy code to new code
 Original comments are preserved throughout the translated code
 All code is formatted following Java coding conventions
 The code is object oriented (examples):
o Three separated layers: Data, Business, Presentation.
o Use of Java primitive types (int, char, String) enhances the readability of the
code.
o Data records are translated to a class. Similar data records are detected, and
only one class is generated for them.
o Copybook classes are reused as a single class throughout the application when
possible.
o Transfer between programs is done using the TransferObject pattern.
o Data access layer is separated. For each program, SQL statements are moved
to separate classes, Data Access Object. Programs are moving data to DAOs
using a TransferObject.
o Program flow is normalized.
o Each COBOL program is a service, exposing only main entry point. All working
storage fields are private to the program class.
o Design of the statement translation leverages, as much as possible, from the
existing J2SE library.
 The application is modularized
o Each application module is translated to a Java package.
o Each module package has a standard structure (For example):

app.module.copy: copybooks classe

app.module.data: DAOs, TOs
app.module.ws: enums, occurs, redefines, working storage record classes
app.module: program classes

Copyright ©2012, BluePhoenix Solutions, Inc 19

4.2.Re-architecting
The CTU modernization approach focuses on a pragmatic layering of the original application and
full code conversion, rather than totally re-architecting the application.
This pragmatic approach has two major benefits:
 Risk free, fast migration to a new platform and higher ROI.
The CTU proven solution 100% automates the migration process which translates into
equivalent functionality (including transfer of existing bugs, if there are any in the old
code) to the current system.
 Test the new system against the legacy application
Existing inventory components will be processed through the CTU migration toolset,
converted to operate in the new technology environment and then thoroughly tested to
prove “functional equivalency.” This means that although the application now operates in
newer, proven technologies, it produces equivalent results when presented with equal
inputs in terms of data, control inputs, and user keystrokes.
After the conversion is done, two major achievements are realized:
 The resulted application is already maintainable and object oriented, separated in three
layers: Data, Business and Presentation:
o Data layer is separated
o Data structures are true Java structures, using native Java types
o Each COBOL program is a service
o Each map is a JSF screen
o Each application module is a package
 The resulting application has a working set of tests verifying the original functionality
Further re-architecting the application from this point is possible using standard Java re-factory
tools. This process will benefit from the tests already done, significantly lowering re-architecting
risks.

4.3.Monitoring
As a post translation service, CTU includes a web application to help manage sites running
converted JCLs.
Main features of Site Management Console (SMC):
 File browser
 Initiator management
 Lock monitor
 Log Files and Log File Viewer
 Log cleaner
 Configuration file management
 User/Group management

Copyright ©2012, BluePhoenix Solutions, Inc 20

 With Initiator manager you can control the run of translated JCL jobs:
 Define Initiators
 Run/pause/shutdown Initiators
 Submit Jobs to Initiators
 View/Manage queued Jobs

Copyright ©2012, BluePhoenix Solutions, Inc 21

5.Translation Process
In order to facilitate modernization of the customer legacy applications, BluePhoenix has
developed an end-to-end migration methodology including tools, procedures and the CTU
Product offering to implement the migration of Mainframe based Legacy application to Java / C#.

5.1.The Process
The methodology related to the migration project provided by BluePhoenix includes the following
phases:

Global
Assessment
Ensures all assets are inventoried, and a
Detailed detailed plan is formed for migration
Analysis

Database
Remodeling
Parallel migration activities
Data divided into Work Packets,
Migration using BluePhoenix
automated conversion tools
Code / JCL Conversion
by Work Packets

Pre-Delivery
Testing
Regression Testing

Reconversion of
Refresh changed components

Acceptance
Deployment
Test

Global Assessment
The Global Assessment phase includes the automated inventory analysis of the customer to
establish a definitive project inventory, and to populate a repository of components to be migrated
to the target environment. This activity will be conducted using the BluePhoenix toolset and
includes analysis of the entire inventory to confirm the inventory sizing.
Detailed Analysis
Detailed Analysis includes analysis of the in-scope application inventory, data model mapping,
and the documentation of all design decisions related to the platform migration, such as
architecture decisions, current BluePhoenix toolset options, coding styles supported in toolset,
database layer/connections and error handling. If customer desires other options for conversion,
requiring enhancing the conversion toolset, the request will be analyzed during this phase.
The agreed upon data modeling rules determined during this phase will be used to automatically
create an optimized relational SQL data model to capture all explicit and implicit VSAM/IDMS/IMS
data.
This phase also includes discussing and reviewing how to deliver the transformed code in Work
Packets, and the overall system test strategy.

Copyright ©2012, BluePhoenix Solutions, Inc 22

 Data Migration
This phase includes all the tasks required for data migration of the source application database
(such as DB2, VSAM, IMS, IDMS) to the target application database (such as DB2 UDB, Oracle,
SQL Server and more).
Data Migration involves the automated generation of programs and processes for unloading,
transformation, validation and loading of data from the source database to the target database.
Code Conversion
The use of the CTU automated migration product allows many benefits over the alternative of
rewriting the application and losing most of the past investment. This cost -effective solution
significantly decreases the risk, cost, and time involved, and enables current developers to
continue maintaining and enhancing the migrated application.
Refresh
The refresh phase is comprised of conversion of all the program source components that were
changed in the production system after conversion of the initial code base (baseline code for
conversion).
The purpose of the Refresh is to minimize the freeze period for code changes on the source
environment during the project life cycle.

Copyright ©2012, BluePhoenix Solutions, Inc 23

5.2.The Product
CTU (COBOL To Universal) is an automated migration tool, that provides an end-to-end solution
for all your COBOL migration needs – analyzing the source code, identifying external resource
use, and finally, creating a target application ready for acceptance test s. It uses existing
application assets as a basis for application modernization, making the transition from procedural
to object oriented architecture easy and achievable.
Conversion of the COBOL code to Java will be done with CTU in three stages:
 Recover (Analysis) - Analysis of all the input code for missing items or problems,
providing the input to the next stage for translation
 Refactor (Transformation) – Generation of the BluePhoenix OOR intermediate language
based on output from the analysis stage.
 Regenerate (Code Generation) – Conversion of the BluePhoenix OOR intermediate
language to Java.

Copyright ©2012, BluePhoenix Solutions, Inc 24

6.Summary

The CTU Product solution offering is a state of the art automates solution for the migrati on of
COBOL based Mainframe applications to new open systems environments running Java or C#.
This cost-effective CTU solution significantly decreases the risk and time involved, and enables
current developers to continue maintaining and enhancing the migrated application.

Legacy COBOL based applications are now becoming a risk to your business. Moving the
COBOL applications to another platform only prolongs this situation, since the application will still
have the same functionality and problems and run in an emulated environment. For example, you
would still need to pay third-party vendors for compilers and runtime environments. Appending
Web services and Web clients to your existing systems only increases the complexity of your
existing architecture. The best solution is to migrate away from the legacy COBOL to Java or C#
using CTU.
With BluePhoenix’s CTU modernization solution, the migrated code can serve as a client/server
application or a Web-based application, according to the company’s business requirements and
needs. Migration to the new environment utilizing an automated process retains business logic
and application flow, keeping the same functionality. The migrated application follows object
oriented principles like encapsulation, abstraction, modularization and loose coupling.
The generated code is readable and maintainable, while the runtime performance is the same or
better than the original application.
BluePhoenix’s CTU migration and modernization products and services provide an end-to-end
solution for all your COBOL migration needs—analyzing the source code, identifying external
resource use, modeling and migrating the data and finally, creating a target application based on
open standards ready for acceptance tests. BluePhoenix expert teams perform all required
design phases and architecture decisions in accordance with your company’s specific business
needs.

Copyright ©2012, BluePhoenix Solutions, Inc 25