JAVA-SHAREABLE

Use the JAVA-SHAREABLE ON and JAVA-SHAREABLE OFF directives to bracket one or more WORKING-STORAGE data items to indicate that they are to be made read/write accessible from Java™ applications interoperating with this COBOL program.

Note: In order for a Java method to access a COBOL program's WORKING-STORAGE, the COBOL program must be part of the run unit associated with the COBOL/Java application, and the program must also have been invoked at least once, either directly by a Java method or indirectly by another COBOL program that is callable from Java, so that its WORKING-STORAGE is initialized before the Java method tries to access it.

Format

Read syntax diagramSkip visual syntax diagram >>JAVA-SHAREABLE ONOFF

General rules

The JAVA-SHAREABLE directive must be specified in the DATA DIVISION and is only relevant for data items defined in the WORKING-STORAGE SECTION and only for data items that are Java-compatible. See Mapping between COBOL and Java data types for non-OO COBOL/Java interoperability for details. Otherwise, the data item is ignored.

If JAVA-SHAREABLE ON/OFF appears in the middle of a group definition, it will take effect starting with the next 01/77 level data item and will apply to that item and its subordinates if any, and will also apply to any subsequently defined data items until the end of the data division is encountered.

Because the mechanism for sharing data between COBOL and Java involves external data items in COBOL, data items that are Java-shareable should have a unique name across the entire COBOL part of the application; otherwise, there's a possibility for a name collision. The name of Java-shareable data items must also be 26 characters or less.

The generated stub programs and Java interface classes are written to a z/OS UNIX directory that is specified by the JAVAIOP(OUTPATH(zos-unix-directory)) compiler option. If that option is not in effect, the default output location is the current directory if the compiler is being run from the cob2 utility; otherwise, the output location is the home directory of the userid under which the compiler is running.

Building COBOL stub programs and Java interface classes

  • The WORKING-STORAGE initialization stub program, along with any other COBOL stub programs generated by the compiler for the application, must be compiled into an application DLL using the cjbuild tool, which will also build any generated Java interface classes. For details, see Building and running non-OO applications that interoperate with Java in Enterprise COBOL Programming Guide. This application DLL will be loaded into the JVM at run time when Java makes a call to COBOL. If the output location of the DLL is specified as a data set to cjbuild, then that data set must be in your STEPLIB at run time. If the output location of the DLL is specified as a z/OS UNIX directory, then JVM property java.library.path should be set to that directory, which can be done by adding -Djava.library.path=<path> to the "java" command used to execute the Java application.

Accessing COBOL WORKING-STORAGE items from Java

The Java strg class used for accessing a program's WORKING-STORAGE items from Java is considered to be part of a package. The package name can be specified using the --pkgname option of the cjbuild utility when it is invoked to build the native method DLL for an interoperable application. If the name is not specified, it defaults to enterprise.COBOL.

The strg class consists of a 2-level hierarchy of classes and objects that can be used to access COBOL WORKING-STORAGE items. In particular, strg contains one nested class per each COBOL program that is part of your interoperable application, and for each such class, there is one object per 01/77-level WORKING-STORAGE item that is accessible from Java.

The name of the Java object corresponding to the COBOL data item contains only uppercase letters. This is true even if the data item is defined in your COBOL program with some lowercase letters. This is due to the fact that COBOL is a case insensitive language.

For example, if you have two COBOL programs in your application, PROG1 and PROG2, and PROG1 has shareable WORKING-STORAGE item DATA1, and PROG2 has shareable WORKING-STORAGE item DATA2, where DATA1 and DATA2 are both defined with picture string PIC S9(9) COMP-5, then DATA1 and DATA2 can be accessed from your Java application as follows:
import enterprise.COBOL.*;
:
int data1 = enterprise.COBOL.strg.PROG1.DATA1.get();
enterprise.COBOL.strg.PROG1.DATA1.put(24);

int data2 = enterprise.COBOL.strg.PROG2.DATA2.get();
enterprise.COBOL.strg.PROG2.DATA2.put(12);
  • Accessing groups

    If a Java-shareable WORKING-STORAGE item is a group, then the corresponding Java accessor class has a structure that mimics the structure of the COBOL group.

    For example, consider a COBOL program PROG1 with the following COBOL group G1 in WORKING-STORAGE:
    >>JAVA-SHAREABLE ON
    01 G1.
      03 N1 PIC S9(9) COMP-5.
      03 G1SUB.
        05 S1 PIC X(20).
    >>JAVA-SHAREABLE OFF
    A Java program can access the items in group G1 as follows:
    import enterprise.COBOL.*;
    :
    int n1 = enterprise.COBOL.strg.PROG1.G1.N1.get(); 
    String s2 = enterprise.COBOL.strg.PROG1.G1.G1SUB.S1.get();
  • Accessing tables

    To access an element of a table, the corresponding Java array variable must be indexed.

    For example, consider the following COBOL program PROG1 with the following COBOL table:
    >>JAVA-SHAREABLE ON
    01 LIST.
       03 NUM PIC S9(9) COMP-5 OCCURS 10 TIMES.
    >>JAVA-SHAREABLE OFF
    Java code can access elements of table NUM as follows:
    import enterprise.COBOL.*; : 
    int n1 = enterprise.COBOL.PROG1.LIST.NUM[0].get(); 
    // get value of NUM(1)
    enterprise.COBOL.strg.PROG1.LIST.NUM[0].put(12); 
    // Set NUM(1) to 12