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 .dll (Windows) or .so (UNIX) 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.
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.
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.