Java Accessing COBOL Working Storage Items

You can configure data items in the working-storage section of your native COBOL program to be accessible to Java programs. The Java program can utilize accessors (get methods) and mutators (put methods), implemented as part of the interoperability, to read and write the COBOL data.

A COBOL library file and a number of Java classes, produced as part of the COBOL compilation process, help form part of the run unit driven by the Java application accessing the data; the generated Java classes are mostly used to map the COBOL data items and Java types, and keep them synchronized.

Firstly, to share the working-storage items, wrap them within a JAVA-SHAREABLE block; for example, grp1 and grp2 below would be accessible to a Java program, but grp3 would not.

       program-id. "demo1".
       ...
       working-storage section.
       >>JAVA-SHAREABLE ON 
       01 grp1.
          03 i1 pic 9(8) comp-5 value 88888889.
          03 i2 pic 9(8) comp-5 value 01234578.
       01 grp2.
          03 i3 occurs 5.
             05 i4 occurs 2 times pic x(4) comp-5.
             05 grp2a.          
                07 i5 pic 9(9) comp-5. 
       >>JAVA-SHAREABLE OFF
       01 grp3.
          03 i6 pic 9(8) comp-5 value 22222229.
          03 i7 pic 9(8) comp-5 value 08765432.    
       ...

To generate the necessary files for the run unit, you compile your COBOL program containing the JAVA-SHAREABLE block(s) to a .so file, additionally using the JAVA-GEN-STRG directive. The presence of the JAVA-SHAREABLE directive produces a <prog-name>ws.java file, which is used to produce the classes that implement the put and get methods used to access the COBOL data; JAVA-GEN-STRG produces a strg.java wrapper class used make the data accessible to Java.

These Java files, along with some other generated files that are not visible to the user, get compiled when you build your main Java application.

Two additional directives, JAVA-OUTPUT-PATH and JAVA-PACKAGE-NAME, also help to expose the COBOL elements to the Java. The value for JAVA-OUTPUT-PATH must be on the CLASSPATH when you build and run your Java code. The JAVA-PACKAGE-NAME value forms the package location, within the output path, that the <prog-name>ws.java and strg.java files are placed. For the Java code access the compiled versions of these files, an excerpt from the Java program may look something like this:

import com.mycompany.demo1.*;
      ...
      int i1 = strg.demo.grp1.i1.get();
      int i2 = strg.demo.grp1.i2.get(); 
      int a1 = strg.demo.grp2.i4[5][2].get();   *> see note
      int a2 = strg.demo.grp2.i3[2].i4[4].get();
      int a3 = strg.demo.grp2.i3[1].grp2a[1].i5.get();
      ...

where the COBOL data in <prog-name>ws.java was compiled with JAVA-PACKAGE-NAME(com.mycompany.demo1). This excerpt also demonstrates the implemented get method being used to retrieve the value of the grp1 items set in COBOL - the strg element of the declaration is instantiating the strg.java wrapper class, which in turn is encapsulating the items from the demo program, as specified in <prog-name>ws.java.

Note: There are two types of format you can use when accessing multi-dimensional arrays: the first format shown above enables you simply supply the subscripts in relation to the top level group, and the second format supplies subscripts for each hierarchical item within the group.

Also, when dealing with tables/arrays between COBOL and Java, be aware that COBOL uses a 1-based indexing system and Java uses a 0-based indexing system; you will need to mitigate for this when working with COBOL tables.

You can also update the COBOL data directly from the Java code, using a put method, and the internal mapping process will update the COBOL item in memory:

...
strg.demo.grp1.i1.put(12345678);
strg.demo.grp2.i3[1].i4[2].put(5555);
...

For a working example of COBOL data being shared and accessed in a Java program, from the command line, see Example 2 - Java Accessing COBOL Working Storage Items. For similar examples from within the IDE, see Java Interoperability within the IDE.

If you are sharing COBOL items from more than one COBOL source program, you need to create the strg.java using the genjava utility (instead of using the JAVA-GEN-STRG directive); see The genjava Utility for more information.

The sharing of COBOL data items becomes particularly useful when used in conjunction with the JAVA CALLABLE method (see Java Calling COBOL Programs), where your Java applications can drive both the COBOL code and COBOL data; see Example 4 - Java Calling COBOL and Accessing Working Storage Items.

Important: COMP and COMP-5 data items shared via JAVA-SHAREABLE need to occupy either two bytes or a multiple of four bytes; therefore, it is advisable to compile with the IBMCOMP directive to ensure this requirement is always met.