This chapter introduces the different ways that Java and COBOL applications can call each other.
There are a number of ways of using COBOL and Java together. You can use the Interface Mapping Toolkit, the wizards and GUI tools to create interfaces to COBOL from Java, or you can hand code the calls using the supplied support libraries. Java itself provides access to other technologies, such as Remote Method Invocation (RMI) and Java Naming and Directory Interface (JNDI) which enable you to distribute objects across different machines.
You can use COBOL and Java together by:
Although Enterprise Server for Windows is required to run legacy programs exposed using the Interface Mapping Toolkit, you can choose to use Enterprise Server for Windows or Application Server for Net Express (or for Server Express) for running the other types of applications that use both COBOL and Java programs.
The Java language defines its own data types, which are different to the ones used in COBOL. The COBOL run-time system automatically converts between COBOL and Java types whenever you call Java from COBOL or COBOL from Java. Where a COBOL data type cannot be translated directly (for example, edited fields), it is translated to a string. Where a COBOL data type cannot be translated directly (for example, edited fields), it is under some circumstances translated to a string. See the chapter Java Data Types
You need a Java run-time system on any machine which is going to execute Java applications. If you are going to develop mixed Java and COBOL applications, you will also need a Java development environment. You can use either the Java Software Development Kit available from Sun, or any Java IDE which is based on either the Sun or Microsoft run-time environments listed below.
Net Express currently supports the following Java run-time systems on Windows:
Before you start writing COBOL and Java programs which interact, you need to set up the following environment variables for the COBOL and Java run-time systems:
If you have COBOL programs which are going to call Java, you must tell the COBOL run-time system which Java run-time system you are using. To do this, set environment variable COBJVM to one of the following:
In addition, if you are using the Sun Java run-time system, add the subdirectory containing the jvm.dll file to your system path. The location of this file depends on which version of the Java Development Kit (JDK) you are using. For example:
Where subdirectory might be client, classic, hotspot or server.
This environment variable enables the COBOL run-time system to locate the jvm.dll file contained in this directory. Do not move jvm.dll to a different location, because it has dependencies on other files shipped as part of the Sun Java run-time system.
If you have Java programs which are going to call COBOL, you need to provide some Java classes which interface to the COBOL run-time system. To do this, ensure that mfcobol.jar is specified by the CLASSPATH environment variable for your Java run-time system. You should also ensure that CLASSPATH specifies the current directory, denoted by a period (.). For example:
set classpath=%classpath%;.;c:\program files\Micro Focus\net express\base\bin\mfcobol.jar
You can also set the Java class path when you run a Java program, using the -classpath switch. For example:
java -classpath ".;c:\program files\Micro Focus\net express\base\bin\mfcobol.jar;%CLASSPATH%" MyClass
Any COBOL program which is going to call Java must be compiled with the following directive:
This does two things:
Any COBOL program which is going to be called from Java using CobolBean.cobcall*() methods methods should be compiled with the DATA-CONTEXT compiler directive. This enables the runtime system to create new application storage areas for each instance of a CobolBean that is created.
When you use the Net Express IDE to create OO COBOL classes for use with Java, the Class Wizard adds the Java wrapper classes for OO COBOL to your Net Express project. The Java classes are compiled by the IDE when you rebuild your project. To set up this support edit mfj.cfg, in your net express\base\bin directory, to contain the full path and filename of your Java compiler.
If your net express\base\bin directory does not contain a copy of mfj.cfg, you will need to create it. Net Express creates mfj.cfg file the first time you compile a Java program in the Net Express IDE, providing that it can find the location of a Java compiler in your PC's registry or on the PATH environment variable.
In addition to specifying the Java compiler to use, you can use mfj.cfg to specify any Java compiler command line arguments. If you edited mfj.cfg to contain the following:
every time you compiled a Java program from the Net Express IDE, Net
Express would use javac.exe in the d:\jdk\bin directory,
All COBOL programs for use with Java must be linked with the multi-threaded run-time system.
On Net Express, click Multi-threaded on the Link tab of the Project Build Settings dialog box. If you are debugging programs, click Settings on the Animate menu, and check Use multi-threaded runtime.
When you call COBOL from Java, the OO COBOL Java support loads one of several cbljvm_*.dll modules to interface to the Java Virtual Machine (JVM). The exact file loaded depends on the JVM you are using, and is selected by querying the name of the JVM the Java program is running under.
If your JVM is not one of those listed as supported, you will get a fatal "Unsupported JVM" error. You can force the loading of a particular JVM by setting a Java system property, called com.microfocus.cobol.cobjvm, to the name of one of the supported JVMs. For example, to load the support for the Sun JVM, contained in cbljvm_sun.dll, set this property to "sun".
You can set this property on the command line that runs your Java program, as follows:
java -Dcom.microfocus.cobol.cobjvm=name class
name is the name of the support module you want to use. For example, to
run Java program myclass with the support for the Sun JVM:
java -Dcom.microfocus.cobol.cobjvm=sun myclass
If you get the "unsupported JVM" error, try the Sun JVM first as many JVMs are rebadged from Sun.
Copyright © 2003 Micro Focus International Limited. All rights reserved.
This document and the proprietary marks and names used herein are protected by international law.