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. Alternatively you can use the GUI tools in Net Express, such as the Class and Method Wizards, and then publish your work to your target UNIX system. 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 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.
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 that interact, you need to add the Java support to the COBOL environment. You do this by running the cobsje script as follows:
.$COBDIR/bin/cobsje [-n|-v][-J java_home]
Where the options are:
-n | Do not change the environment settings but display what they are set to. |
-v | Verbose mode: apply the changes and display the new settings. |
-J | Specifies the full path to the J2SE installation and sets the JAVA_HOME environment variable accordingly. |
java_home | The full path of where Java is installed. If you do not specify a path, the value of the environment variable $JAVA_HOME is used. |
The script sets up the environment as follows. It:
Any COBOL program which is going to call Java must be compiled with the following directive:
ooctrl"+p-f"
This does two things:
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.
The easiest (and recommended) way of writing COBOL and Java components is to develop your applications on Net Express, then to publish the result to your target UNIX system. Working in this way enables you to take advantage of Net Express features such as the Class Wizard and Method Wizard, which greatly simplify the process of creating COBOL classes. This book assumes that you are developing your COBOL and Java applications on Net Express using the Class and Method Wizards, then publishing the results to your UNIX system.
For more information on Net Express, see the section Net Express and Server Express in the Introduction chapter in your Getting Started.
The Java/COBOL application launcher is used to launch a Java application from a COBOL run-time environment. You should use the Java/COBOL application launcher instead of your usual Java application launcher as it sets up your environment to correctly manage both the COBOL run-time system and the Java Virtual Machine.
The Java/COBOL application launcher is cobjrun and it is the trigger for cobjrun32 and cobjrun64.
The command to invoke the Java/COBOL application launcher can take one of two formats:
cobjrun [options] class [arguments]
or:
cobjrun -jar [options] jarfile [arguments]
where the parameters are:
options | The options you would normally specify to your Java application launcher. |
class | The name of the class to be invoked. If the Java/COBOL application launcher cannot find a Java class of this name, it tries to find a COBOL program of the same name. If a COBOL program is found, it is executed. |
arguments | The arguments to pass to the main function. |
-jar | Specifies that a program from a JAR file is to be executed. |
jarfile | The name of the Java archive (.jar) file to be invoked. |
Notes:
public static void main(String args[])
If you are planning to deploy OO COBOL Enterprise JavaBeans (EJBs) to WebSphere on the AIX platform, you might need to set the COBMAINSTACK environment variable. You set COBMAINSTACK only if you are running the OO COBOL code under Micro Focus Server. You do not need to set it if you create EJBs using the Interface Mapping Toolkit and are running the COBOL code under Enterprise Server.
You set COBMAINSTACK because WebSphere requires a large amount of stack space during the process of starting the EJB server. The default size on AIX is too low for both COBOL and the WebSphere application server to exist. Setting it too low will cause problems, and setting it too high it might use too much resources. You should set it to at least 256Kb. For example, set it as follows:
COBMAINSTACK=256 export COBMAINSTACK
For full details on COBMAINSTACK, see the appendix Environment Variables in your User's Guide.
All COBOL programs for use with Java must be linked to the multi-threaded run-time system.
To do this, use the -t cob flag. For more information, see the section Create Multi-threading Program in the chapter Descriptions of cob Flags in your User's Guide. For more information on multi-threading, see your Multi-threaded Programming book.