Considerations When Moving to Managed Code

Database Support

You can use OpenESQL with the SQL(DBMAN=ADO) (in Visual Studio only) and SQL(DBMAN=JDBC) (in Eclipse only) directive to compile your managed applications. Micro Focus tries to maintain as much source code compatibility as possible between the OpenESQL native and manage 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 ADO.NET run-time system had extensions to support offline DataSets and DataTables using EXEC ADO statements. Both the ADO.NET and JDBC run-time systems support object host variables as well as traditional COBOL host variables.

The following restrictions apply to database support in managed code:

• Oracle does not support managed code using Pro*COBOL. The workaround is to move your code to OpenESQL with ODBC first and then move it to managed code with ADO.NET.
• 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 managed code. Also, although some Oracle extensions might be supported by OpenESQL, others might need to be reworked.
• There is no PL/SQL support in managed 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

Managed code is a great way to modernize your Dialog System applications through Visual COBOL. 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, read Modernizing Dialog System Applications in the documentation for Visual COBOL for Visual Studio.

Library Routines

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.

Managed and Native 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.

Modernization of the User Interface

Visual COBOL offers great options for modernizing your application's user interface. You can use the Windows Presentation Foundation in .NET or 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.

Object-Oriented Programming

You can still write and use procedural COBOL that will compile and run in managed environments such as the .NET framework or 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:

• A great way to start with this is the document An Introduction to Object-Oriented Programming for COBOL Developers, available from the Product Documentation section on the Micro Focus SupportLine Web site - click here to download it.
• See the COBOL for .NET or COBOL for JVM examples installed with Visual COBOL.
• You can also find a wealth of resources for .NET programming on Microsoft's MSDN, and Java examples on the Java Web site.

Third Party Software

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.

Win32 API Routines

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.