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=JDBC) 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 (including DECLARE CURSOR, OPEN, FETCH, CLOSE, SELECT, INSERT, UPDATE, DELETE, CONNECT, DISCONNECT, COMMIT and ROLLBACK) are completely compatible and require no change.
The following restrictions apply to database support in managed code:
Certain library routines are only supported in native code. See General Reference > Library Routines in your product documentation for 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.
Enterprise Developer offers great options for modernizing your application's user interface. You can use Java Swing in the JVM. 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 will compile and run in managed environments such as the JVM. However, in order to take a full advantage of all of the features of the managed frameworks and be able to expose your code to other managed languages, you might need to start using managed COBOL syntax. In order to find help with writing managed COBOL, you can explore the following resources:
Examine your existing procedural code for any Third-Party APIs that make operation system calls. 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 the procedural code to managed COBOL, you need to remove the call to the Win32 API routine and, instead, use an equivalent .NET or JVM feature to achieve the desired results.