Tips on migrating Gen COBOL applications to .NET (C#)

Products

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

Issue/Introduction

This article covers the main topics to be aware of when migrating Gen 8.6 COBOL applications to .NET (C#).

Resolution

A COBOL Distributed Processing server would become a Gen .NET server that executes as a COM+ application under the control of Microsoft .NET Component Services: Working with .NET Servers
If wanting to target the same DB2 database the C# code can be simply generated for the same Gen model DBMS (TD) as the current COBOL code i.e. "DB2 z/OS". Otherwise if moving to a new DBMS type the relevant Technical Design can be created and used for the DBMS (TD) at generation time.
The .NET server will connect to the target database using the selected Data Source and Provider - see Configuring the Data Source
When Gen applications are migrated from one platform (OS/programming language etc) to another normally any External Action Blocks (EABs) must be rewritten in the programming language of the new platform. Gen now supports Inline Code so the rewrite could also move an EAB to inline code.

Clients:

Gen GUI C clients can also be migrated to Gen .NET web clients which run under the Internet Information Services (IIS) Application Server: Working With ASP .NET
Alternatively the Gen GUI C clients can remain and connect to the .NET servers using .NET Remoting via the Gen C to C# Cooperative Flow

Middleware:

.NET Remoting is the only option (Distributed Processing Server Profiles)

Batch applications

There is no real "batch" mode for a .NET server application, 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: How to generate/run a Gen .NET application in batch

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 .NET 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 .NET user exits are provided to implement security customizations.
Consider what z/OS user exits have been customized and for what purpose. Then determine if similar customizations will be needed in the .NET 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 C#), then generation would need to be done on the Workstation Toolset or on a Client/Server Encyclopedia (CSE). The latter would provide centralised C# code generation, like a HE does for COBOL now.