Chapter 1: Using Java and COBOL Together

This chapter introduces the different ways that Java and COBOL applications can call each other.

Overview

There are a number of ways of using COBOL and Java together. You can use the Interface Mapping Toolkit, or the GUI tools, such as the Class and Method wizards, 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:

• Mapping a Java interface onto procedural COBOL, using the Interface Mapping Toolkit, thereby exposing COBOL services without changing the COBOL code. The new interface then needs deploying, which involves deploying the generated EJB to J2EE and deploying the COBOL service to an enterprise server. At run time, the EJB running under J2EE calls the COBOL code, which runs under the control of an enterprise server. See the chapter Mapping a Java Interface and Using Resource Adapters.
• Calling procedural COBOL from Java, using the support provided in the com.microfocus.cobol.RuntimeSystem class. This class is extended to provide the CobolBean class. This RuntimeSystem class support also enables you to call Java from procedural COBOL, through the Java Native Interface (JNI). This is ideal for use with Java 2 Standard Edition (J2SE). See the chapter Calling Procedural COBOL from Java.
• Calling Java from OO COBOL, using the Java object domain for OO COBOL. This is ideal for use with Java 2 Standard Edition (J2SE). See the chapter Calling OO COBOL from Java.
• Calling OO COBOL from Java, using the Net Express Class Wizard to createcreating a Java wrapper class that provides a function for each method in the OO COBOL class. This is ideal for use with Java 2 Standard Edition (J2SE). See the chapter Calling Java from OO COBOL.

Although Enterprise Server is required to run legacy programs exposed using the Interface Mapping Toolkit, you can choose to use Micro Focus Server with or without Enterprise Server 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 under some circumstances translated to a string. See the chapter Java Data Types.

Setting Up the Environment for Java and COBOL

You need a Java run-time system on any machine that is going to execute Java applications. If you are going to develop mixed Java and COBOL applications, you also need a Java development environment. You can use either the Java Software Development Kit (SDK) available from Sun, or any Java IDE which is based on either the Sun or Microsoft Java run-time environments. Alternatively you can have a Java Virtual Machine (JVM), which provides both a development environment and a run-time environment.

Your COBOL development system currently supports several Java run-time systems.

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:

• COBJVM

  If you have COBOL programs that 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.

  Use this method to override the default value, for example, if you are developing new applications with a later JVM, while still working with existing applications developed using an earlier JVM.

• PATH

  If you are using the Sun Java run-time system, the jvm.dll file must be available. 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. The location of this file depends on which version of the JDK you are using. To ensure the file is available, add it to the system PATH. For example:

  set path=jdk-install-directory\bin\subdirectory;%path%

  Where subdirectory might be client, classic, hotspot or server.

  If you generate EJBs or Java beans using the Interface Mapping Toolkit, the Java Compiler must be available. To do this, put the bin directory of JDK on the PATH. For example:

  set path=jdk-install-directory\bin;%path%

• CLASSPATH

  If you have Java programs that call COBOL, you need to provide access to the Java classes that interface to the COBOL run-time system. To do this, ensure that mfcobol.jar is specified by the CLASSPATH environment variable. For example:

  set classpath=NX-install-directory\base\bin\mfcobol.jar;%classpath%;.;

  Alternatively, you can set the classpath when you run a Java program, using the -classpath switch. For example:

  java -classpath ".;NX-install-directory\base\bin\mfcobol.jar;%classpath%" MyClass

  If you generate EJBs or Java beans using the Interface Mapping Toolkit, the tools.jar of the JDK must be on the CLASSPATH. For example:

  set classpath=jdk-install-directory\lib\tools.jar;%classpath%;.;

• Shared library path

  The operating system's shared library path must include the directory containing libjava. This is often found in a subdirectory of Java's jre/lib directory, although the name of this directory is specific to each platform. On some platforms, you might need to specify more than one directory for this, for example, an additional directory containing the Java native threading support.

Compiling COBOL Programs that Call Java

Any COBOL program which is going to call Java must be compiled with the following directive:

ooctrl(+p-f) 

This does two things:

• Adds type information to invoke statements, which the COBOL run-time system needs to convert data correctly between the COBOL and Java domains
• Prevents the compiler from folding method names it invokes to lower-case - Java method names are case-sensitive

Compiling COBOL Programs that Are Used from the CobolBean interface

Any COBOL program which is going to be called from Java using CobolBean.cobcall*() methods should be compiled with the DATA-CONTEXT Compiler directive. This enables the run-time system to create new application storage areas for each instance of a CobolBean that is created.

Compiling Java Programs in Net Express

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:

d:\jdk\bin\javac.exe -verbose

every time you compiled a Java program from the Net Express IDE, Net Express would use javac.exe in the d:\jdk\bin directory, specifying the -verbose option.

Linking to the Multi-threaded Run-time System

All COBOL programs for use with Java must be linked to the multi-threaded run-time system.

In 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.

For more information, see your Multi-threaded Programming book.

Copyright © 2006 Micro Focus (IP) Ltd. All rights reserved.