Considerations When Moving to .NET COBOL

There are a number of things you need to consider before you start using .NET COBOL in your existing applications. You need to analyze your current application - its structure and build method - and take decisions about how these should change.

Micro Focus Professional Services for Micro Focus products is here to assist you with the transition of your application to .NET COBOL.

See below some of the areas that you need to consider.

Complexity of the original application

The complexity of your application (such as number of programs and interconnection between the programs) and the method used to compile natively play a significant role in how easily you can move to .NET COBOL. The factors include:

  • Number of programs in your application. Your application might include a very large number (e.g in the tens of thousands) of COBOL programs, and they might all compile as .int/.gnt code. When you move to .NET COBOL, you need to compile the programs as , .exe or .dll and then need to decide how to best package the application for .NET COBOL code.
  • Large intertwined programs might have compiled successfully on the mainframe and in native COBOL. These might need to be rewritten to compile and run successfully as .NET COBOL. This is because the underlying model of the generated .NET COBOL code is object-oriented so classes and methods are being generated. In .NET, a stack overflow might occur for applications that use GO TO statements that go outside of a performed section.
  • Applications which make use of the Micro Focus native OO-class libraries cannot be recompiled to .NET COBOL. You would need to rewrite these to use the .NET Framework instead.

Build method of the original native application

Your original native COBOL application might be using batch scripts executed at the command line to compile. The way you compile the application is likely to change meaning you might need to adopt new and improved procedures for compiling your code.

If the batch scripts place any executable files in a certain directory structure, then this might have to change as well.

Programming knowledge and skills for the new technologies

When updating to .NET COBOL, you might need to invest in skills that will help you be successful in maintaining your applications. For example:

  • Cloud-computing for Microsoft Azure requires knowledge of the structure of Visual Studio Azure projects and how to deploy to Azure. See the Visual Studio tutorials.
  • Exposing COBOL application as WCF web services requires knowledge about how to create and deploy the service, and how to create a client. See the Visual Studio tutorials.
  • .NET enables you to deploy your applications to any operating system that the .NET supports.
  • Containers and Docker - requires you to learn about containerization and about developing, deploying and running applications in Docker. See Modern Development Practices.
  • Continuous Integration includes a set of software development practices for teams working on the same application base that includes testing an automation. See Modern Development Practices.

Deployment and licensing

These are handled differently in .NET COBOL code. You need to understand how to package the application and deploy it under .NET.

Database Support

You can use OpenESQL with the SQL(DBMAN=ADO) directive to compile your .NET COBOL applications. Micro Focus tries to maintain as much source code compatibility as possible between the OpenESQL native and managed code run-time systems. Although each run-time system has extensions, limitations, and differences that are imposed by the underlying database APIs and execution environments, the majority of embedded SQL statements such as DECLARE CURSOR, OPEN, FETCH, CLOSE, SELECT, INSERT, UPDATE, DELETE, CONNECT, DISCONNECT, COMMIT and ROLLBACK, are completely compatible and require no change.

The ADO.NET run-time system has extensions that support offline DataSets and DataTables using EXEC ADO statements. It also supports object host variables as well as traditional COBOL host variables.

The following restrictions apply to database support in .NET COBOL code:

  • Oracle does not support .NET COBOL code using Pro*COBOL.

    The workaround is to move it to .NET COBOL code with the OpenESQL SQL directives (DBMAN=ADO TARGETDB=ORACLE PROCOB). See these SQL directives under Database Access for more information.

  • Before moving to OpenESQL, you need to compile with the Pro*COBOL directives MODE=ANSI and FIPS to determine if your code includes non-standard ANSI syntax which is not supported in .NET COBOL code. Also, although some Oracle extensions might be supported by OpenESQL, others might need to be reworked.
  • There is no PL/SQL support in .NET COBOL code, although some PL/SQL statements and blocks may work.
  • Applications that use output parameters from stored procedure calls must use the COBOL directive NOILNATIVE, and object host variables cannot be used for output parameters on stored procedure calls.
  • Pessimistic concurrency with locking is not supported in ADO for databases other than Microsoft SQL Server. The run-time system will instead substitute optimistic concurrency.

Dialog System Applications

.NET COBOL code is a great way to modernize your Dialog System applications through Enterprise Developer for Visual Studio 2022. As a first step, you can import the application in Enterprise Developer and build and run it in the new IDE. Next, you can start modernizing the application gradually. For example, you can replace one Dialog System screen with a Windows Form or wrap a .NET user control as an ActiveX control and use that in Dialog System. Meanwhile, you can keep the rest of the code unchanged. For more details about the range of techniques for modernization, see Modernizing Dialog System Applications.

Library Routines

Certain library routines are only supported in native code. See the Library Routines section of this documentation for details on the routines you can use in .NET COBOL code.

Native and .NET COBOL Code

You can call native code from .NET COBOL code although there are some environments that could prohibit this. For example, it is not possible to call native COBOL from .NET stored procedures or from certain Java application services.

Combining native and .NET COBOL code within the same application could be restricted in some aspects especially when trying to debug the code and deploy it under .NET.

Modernization of the User Interface

Enterprise Developer offers great options for modernizing your application's user interface. You can use Windows Forms or the Windows Presentation Foundation in .NET. Be aware that there might be potential issues depending on the application architecture and how tightly the original user interface is tied to the back-end module.

Object-Oriented Programming

You can still write and use procedural COBOL that compiles and runs in managed environments such as the .NET framework . However, to take full advantage of all features available in a managed environment, and to be able to expose your code to other managed languages, you might need to start using .NET COBOL syntax. For information about writing .NET COBOL code, explore the following resources:

Third-party Software

Examine your existing procedural COBOL code for any third-party APIs that make calls to the operating system. Technology provided by other software vendors might need to be rewritten for use with .NET COBOL code.

Win32 API Routines

The Win32 API routines are not supported in .NET COBOL code. When you move procedural code to .NET COBOL, you need to remove calls to the Win32 API routine and, instead, use an equivalent .NET feature to achieve the desired results.