There are a number of things you need to consider before you start using JVM 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 is here to assist you with the transition of your application to JVM COBOL.
See below some of the areas that you need to consider.
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 JVM COBOL. The factors include:
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 especially when working with Eclipse.
When updating to JVM COBOL, you might need to invest in skills that will help you be successful in maintaining your applications. For example:
These are handled differently in JVM COBOL code. You need to understand how to package the application and deploy it under JVM.
You can use OpenESQL with the SQL(DBMAN=JDBC) directive to compile your JVM 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 JDBC run-time system supports object host variables as well as traditional COBOL host variables.
The following restrictions apply to database support in JVM COBOL code:
The workaround is to move your code to OpenESQL with ODBC first and then move it to JVM COBOL code with ADO.NET.
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 JVM COBOL code.
You can call native code from JVM COBOL code although there are some environments such as J2EE application servers or web servers that could prohibit this. .
Combining native and JVM COBOL code within the same application could be restricted in some aspects especially when trying to debug the code and deploy it under JVM.
Visual COBOL 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 compiles and runs in managed environments such as the JVM. 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 JVM COBOL syntax. For information about writing JVM COBOL code, explore the following resources:
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 JVM COBOL code.
The Win32 API routines are not supported in JVM COBOL code. When you move procedural code to JVM COBOL, you need to remove calls to the Win32 API routine and, instead, use an equivalent JVM feature to achieve the desired results.