Tips on migrating Gen COBOL applications to Java

Products

Gen Gen - Host Encyclopedia Gen - Run Time Distributed Gen - Workstation Toolset

Issue/Introduction

This article covers the main topics to be aware of when migrating Gen 8.6 COBOL applications to Java

Resolution

Gen can generate Java code for applications to run as applications under an Application Server on both Windows and *nix platforms using Gen Java runtimes. Supported Java versions and Java Application Servers are located on this doc. page: Gen™ 8.6 > Technical Requirements > Third-Party Software Version

Client/server applications

Servers:

A COBOL Distributed Processing server would become a Gen Enterprise JavaBean i.e. EJB or EJB Web Service (generation as EJB Web service also includes EJB): Working With Enterprise JavaBeans
At generation time any supported DBMS (TD) for Operating System=JVM can be selected i.e.

NOTE: Even if JDBC is not selected for the DBMS (TD) value, the EJB will still use JDBC for the actual database connection.
So if wanting to target the same DB2 database as used in the existing COBOL application the Java code can be simply generated for the same Gen model DBMS (TD) value "DB2 z/OS" and the EJB will connect to it via JDBC.
When Gen applications are migrated from one platform (OS/programming language etc) to another normally any EABs must be rewritten in the programming language of the new platform. Gen now supports Inline Code so the rewrite could also move the external action blocks to inline code. Related article: Gen 8.6 server application migration from COBOL to Java and EABs

Clients:

Gen GUI C clients can also be migrated to Gen Java web client applications of which there are 2 types, the original Web Generation (Working With Web Generation) and later Web View (Work with Web View).
Related article: Migrating Gen GUI client-server applications to the Web
Alternatively the Gen GUI C clients can remain and connect to the EJBs via EJB Web Services. Related article: Recommended connection for Gen C client to Java EJB server

Middleware:

Gen Java web client applications can connect to EJBs using Java RMI or EJB Web Services.
Alternatively existing Gen GUI C clients can remain as is and connect to the EJBs via EJB Web Services. Related article: Recommended connection for Gen C client to Java EJB server.

Batch applications

There is no real "batch" mode for an EJB, specifically there is no analogy to z/OS JES which takes a queued job and begins executing it.
This related article covers an alternative mechanism: Gen Java EJB batch processing targeting J2EE Application Server

Block mode applications

For a block mode application with screens, an extra step is needed to first convert the UI to a client UI for the move either to a "Fat" client or to a "Thin" client + server (Distributed Processing) architecture - see above "Client/server applications" section.
There is a "Transform Screen Design into Window" feature in the Navigation Diagram which can convert the screen for an individual Procedure Step to a Window.
For example the Gen sample model online/block mode Business System CORPORATE_MANAGEMENT.
In Navigation Diagram, use Diagram/Open Window and click on a Procedure Step which does not have a window e.g. MENU, to make the Transform button active and clicking it will show the "Transform Screen Design into Window" option enabled.

If no windows exist at all in the Business System then after using Diagram/Open Window the Transform button will be immediately active and clicking it will show the option "Transform Existing Business System" enabled. See Using the Toolset > Transformation Type Dialog
The next step would be to divide the existing Procedure Step code up to separate what can go into the client (no database access) and the server (database access).

User Exits

There is not a one-to-one match between the z/OS User Exits and the Java User Exits, but there are common types of exits. For example, some of the z/OS user exits are provided to implement security customizations. Likewise, some of the Java user exits are provided to implement security customizations, but the Java user exits would be implementing Java EE security.
Consider what z/OS user exits have been customized and for what purpose. Then determine if similar customizations will be needed in the Java environment.

Gen Encyclopedia

If using a Host Encyclopedia (HE) it can only generate COBOL and unless using partner product GuardIEn that enables remote code generation on the HE (can generate code for non-z/OS platforms including Java), then generation would need to be done on the Workstation Toolset or on a Client/Server Encyclopedia (CSE). The latter would provide centralised Java code generation, like a HE does for COBOL now.