Certain technologies have restrictions or may not be supported in managed code. Before you make the move to managed code, you need to consider the following:
You can use OpenESQL with the SQL(DBMAN=ADO) directive to compile your managed 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 managed code:
Managed code is a great way to modernize your Dialog System applications through Visual COBOL for Visual Studio 2017. As a first step, you can import the application in Visual COBOL 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.
Certain library routines are only supported in native code. See the Library Routines section of this documentation for details on the routines you can used in managed code.
You can call native code from managed 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.
Visual COBOL offers great options for modernizing your application's user interface. You can use 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.
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 managed COBOL syntax. For information about writing managed COBOL code, explore the following resources:
Examine your existing procedural 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 managed code.
The Win32 API routines are not supported in managed code. When you move procedural code to managed COBOL, you need to remove calls to the Win32 API routine and, instead, use an equivalent .NET feature to achieve the desired results.