COBOL Spices Up Java

usinesses are establishing a presence in cyberspace as the growth of the world wide web (WWW) ushers in the era of electronic commerce. The myriad possibilities of WWW client machines would in the past present a considerable financial and technological challenge to most corporations as they consider investing in this new vehicle for commerce. The advent of Java and the Java Virtual Machine (VM) makes it relatively easier for companies to undertake this endeavor. The introduction of the Pure Java (TM) initiative by IBM, Sun, and Netscape makes this a more attractive business proposition and imperative as the promise of Write Once, Run Anywhere becomes realizable.

So where does COBOL fit in all of this? Information technology was not invented by Java and the WWW, although it may have been catapulted into the consciousness of many by these new technologies. A lot of corporations depend on so called legacy, mission-critical applications that were, and still are written in COBOL. These businesses run their operations on data created by these COBOL applications. The wholesale conversion of these applications and data to Java is a very daunting task and is not a very judicious use of company resources. Thus, a way of interfacing Java with COBOL is needed.

What is the path to COBOL enlightenment?

The creators of Java recognized the need to interface to non-Java methods and provided for this in the form of native methods. Native methods can be implemented in any non-Java language that supports the C calling conventions. The native methods are packaged in a function library such as dynamic link libraries (DLLs) on OS/2 and Windows 95 and shared libraries on AIX. We will use native methods as our entry point to the business domain knowledge and information that is encapsulated in the COBOL applications and data.

In the next few sections, we will examine in detail the steps needed to interface Java with COBOL. I will summarize the high level tasks here.

1. Create a Java class to define the native method and its interface.
2. Use the javah utility that comes with the Java Development Kit (JDK) to generate the C stub file needed to interface with the COBOL code;
3. Ensure the called COBOL program conforms to the method naming and parameter passing conventions. This can be done either by:
   • Creating a COBOL glue program. This will be called by the C stub program and will call the existing COBOL program
   • Modifying the existing COBOL program
   • Creating a brand new COBOL program.
4. Link the COBOL programs with the C stub to create the dynamic link library or shared library.
5. Use the Java class containing the native method definition in your Java program or applet.

If you are interested in reading more about native methods, please see Tricks of the Java Programming Gurus by Glenn Vanderburg.

How does Java interface with COBOL?

Leveraging existing business knowledge encapsulated within COBOL applications and accessing existing business information stored in COBOL data are two reasons for interfacing your Java application with COBOL. It is often infeasible to modify existing COBOL applications to work with Java applications. It is therefore necessary to create a glue COBOL routine to sit between the C stub routine and the existing COBOL code. For an example of this, please see Java and COBOL by Tony Hassitt, in the November 1996 IBM COBOL Newsletter.

I will illustrate the techniques for interfacing a Java application with COBOL through a COBOL utility routine written to retrieve records from an existing COBOL indexed file. This example was written on a machine running Windows 95, VisualAge for COBOL for OS/2 1.2 Refresh (with support for Windows 95 and NT 3.5.1), VisualAge for C++ for Windows 3.5, and the Java Development Toolkit (JDK) 1.1 Beta 3.

Step 1. Define Java class containing Native method

Listing 1 defines a Java class EmpList with only one method, List_Employees. This method will return an integer value as a result and takes an array of byte data. In Java, an array is always passed by reference. This array, work_record, is actually a buffer that will be used to return a set number of records from a COBOL indexed file. Since a COBOL character is one byte in length as contrasted with a Java unicode character which is two bytes long, we will use a Java byte primitive data type to map to a COBOL character.

The static call to loadLibrary loads a dynamic load library with only the library name specified, in this case emplist. On the Windows 95 platform, this will be resolved to emplist.dll. Java expects the code definition for the native method List_Employees to be contained here.

      class EmpList {
          public native int List_Employees(byte[] work_record);
         static {
              System.loadLibrary("emplist");
          }
       }       
          Listing 1.  EmpList.java

Step 2. Create C stub

Use the javah utility to generate the C stub needed to map the Java structures to the COBOL program. The following command was used for the example.

javah -classpath C:\jdk11\java\lib\classes.zip;. -stubs EmpList

This will generate the EmpList.c file.

Compile EmpList.c with no modification to produce the emplist.obj file. This will be used when we link the COBOL application to create the DLL. The following command was used for the example.

icc -c /Mc /q+ -IC:\jdk11\java\include -IC:\jdk11\java\include\win32 /Ge- EmpList.c

Step 3. Create COBOL method definition

See Listing 3 for this discussion. The program-id is "EmpList_List_Employees", which is the method name that Java expects. The format is classname_methodname, where in our example the Java class name is EmpList and the native method name is List_Employees. You can also issue the javah command without the -stubs option to generate the C header file; this contains an extern to be used as the program-id.

Every non-static Java method has a this reference which is an implicit parameter to the method; thus, the reference to this in the Procedure Division. It is there as a required place holder, we will do nothing more with it.

Since all Java arrays are passed by references, we need to establish addressability within the COBOL program to the array of byte data. We accomplish this by defining a pointer LS-Emp-Reference and the work area LS-Emp-Record within the Linkage Section. Of these two, LS-Emp-Reference is the only one referenced in the Procedure Division header. We establish addressability with the following SET statement.

Set Address of LS-Emp-Record to LS-Emp-Reference

Note also that LS-Result as defined occupies 4 bytes which maps to a Java int primitive data type. Finally, the program has to be compiled with the PGMNAME(MIXED) option to prevent the program-id from being folded to upper case. For this example, the following command was issued to create the ListEmp.obj file.

cob2 -qentryint(cdecl) -qlib -qnoexit -qnoadata -qthread -c ListEmp.cbl

Since this program will be called by the EmpList C stub, the calling conventions will be cdecl; therefore, we need to tell the compiler to expect this with the entryint(cdecl) option.

Listing 3. ListEmp.cbl

Step 4. Create the Dynamic Link Library (DLL)

This is actually the final step in creating the interface. We packaged everything together and created the DLL that the EmpList.java program requires. The following command was used for the example.

cob2 -dll EmpList.obj ListEmp.obj C:\jdk11\java\lib\javai.lib

Note that aside from EmpList.obj (which must be first) and ListEmp.obj, we also need to link with the Java interpreter library (javai.lib) to form the emplist.dll.

Step 5. Create a Java client program

Now that we have created the emplist.dll, let us get a return on our investment by using it from a Java client program. Listing 4 shows an example of a "batch" Java program and listing 5 shows an example of a Java applet. Note that Java2COBOLApplet.java will only work with JDK 1.1 because it uses the delegation-based event model in AWT that was introduced at the JDK 1.1 level. See figure 1 for a sample of the applet running.

What's Next?

Now that wasn't too hard, was it? It may appear to be tedious, but you can automate this process with a makefile. Listing 6 shows a sample makefile. So what's next? Try the example out yourself. Listing 7 shows the COBOL program used to create the COBOL indexed file from the seed file shown in listing 8. If you use the makefile in Listing 6, you can issue the following command to create the EmpFile.dat file:

nmake seedit

References

[Hassitt] Hassitt, Tony, Java and COBOL, IBM COBOL Newsletter, Issue 5, November 1996.

[Vanderburg] Vanderburg, Glenn, et. al., Tricks of the Java Programming Gurus, Sams.net Publishing, 1996. ISBN 1-57521-102-5.

Enjoy the article? Subscribe to Eye on Objects!

Wilbert Kho is an advisory developer and a member of the Worldwide AD Sales and Technical Support team of IBM. He has a B.S. in Electrical Engineering from the University of the Philippines, an M.S. in Computer Science from Northern Illinois University, and an M.B.A. from the University of Phoenix. He is an adjunct faculty member of the University of Phoenix. Wilbert has been in the IT industry for more than 15 years and has been working with object technology for the past three years.

Home Page