2

A quick glance suggests IBM's, Microfocus's and GNU COBOL's offerings for Java and COBOL interop are all different APIs. However, on Wikipedia there is currently the quote that the 2002 spec "Improved interoperability with other programming languages and framework environments such as .NET and Java."

So what is standardized in this regard? (I do not own a copy of the spec, as I'm just getting into COBOL, and am hoping to explore the Java and COBOL interop, currently as a hobby).

bbarker
  • 11,636
  • 9
  • 38
  • 62
  • 1
    There seems to be a vote to close based on the assertion that I'm asking for opinions. I am not - I am asking for what is actually standardized, if anything, related to Java interop in COBOL. For comparison, an opinionated question might be: "what APIs would you recommend for Java interop with COBOL". – bbarker Dec 26 '21 at 03:34
  • 1
    COBOL is a compiled language. IBM COBOL object code has been compatible with other languages that compile to the same object code specifications. I think what the 2002 standard did was add features to COBOL that were common in other languages at the time. The vast majority of commercial COBOL code was coded to the 74 and 85 standards. This is anecdotal experience, but the shops I worked in resisted moving to anything higher than the 85 standards. There was a feeling that COBOL was changing too much and too fast. – Gilbert Le Blanc Dec 26 '21 at 06:10
  • 3
    The 2002 COBOL standard added the `CALL-CONVENTION` directive and the `ENTRY-CONVENTION` clause. The `CALL-CONVENTION` directive is intended to allow calling programs in other languages. The `ENTRY-CONVENTION` clause is to allow other languages to call COBOL. How these are used in any COBOL program depends on the COBOL implementation. Vote to reopen. – Rick Smith Dec 26 '21 at 12:23

1 Answers1

2

There is a clear answer to the question: No.

There were different things added, especially in the 2002 standard, but also in later standards that would allow a standard conforming API for Java interoperability, but the details of interactions with non-COBOL in the standard is always either processor-dependent or implementation-dependent.

What is defined is actually quite much, things coming to mind:

  • ENTRY-CONVENTION and CALL-CONVENTION
  • user-defined functions
  • object-oriented COBOL with classes, objects, methods, factories, ...
  • function and call prototypes
  • defined encoding for NATIONAL and other types

As part of the question may be misleading: GnuCOBOL does not have an API for inter-operating with Java (yet).

If you want to write portable COBOL <-> Java code you can likely use two approaches.

First: use the "C" API offered by Java, the JNI. This will work "quite well" if the COBOL environment can inter-operate with "C" (which is likely true for most implementations).
Have a look for Call c function from Java for details.
Warning: JNI principles should be taken care of, like COBOL called from Java should not STOP RUN (or abend without the chance to catch that on the Java side).

Second: Don't use a direct interface but communicate between COBOL and Java, for example with REST services.

As this also was part of the question: If you want to learn more about what COBOL (as a language, not necessarily supported by "implementor X") then the COBOL standard is a good resource.
In most cases it will be "enough" to just grab whatever the current "draft" of the next COBOL standard is, you can access those at ISO's document page of the COBOL working group [the old versions commonly go away after the standard was published, a new one comes up when the next one is prepared for first public review].

Simon Sobisch
  • 6,263
  • 1
  • 18
  • 38