IBM Information Management System (IMS) - Group home

Good news! 31-bit COBOL can now talk to 64-bit Java in IMS

By CARLOS ALVARADO posted Wed February 16, 2022 12:54 PM

  

Good news! 31-bit COBOL can now talk to 64-bit Java in IMS

Do you need 64-bit Java applications to run in the same environments as 31-bit COBOL applications? If so, IMS has a great new enhancement!

Overview

As you might know, IMS dependent regions have supported interoperability between 31-bit COBOL and 31-bit Java for some time now. IMS customers have been leveraging that support by enhancing their existing COBOL applications to invoke new business logic written in Java.

And the reverse scenario is also true for customers who write new applications in Java and want to leverage their existing business logic written in COBOL.

COBOL and Java interoperability simply means that a Java application can invoke COBOL code, or a COBOL application can invoke Java code. All these applications can run in these IMS dependent regions:  MPR, IFP, BMP, JMP, and JBP.

For example, Java applications run in JMPs and JBPs. COBOL applications run in MPRs, BMPs, and IFPs. If COBOL applications need to make calls to Java code, you can configure MPRs, BMPs, and IFPs to use a Java Virtual Machine (JVM) so that COBOL code can call Java code.

But how does that work? 

To achieve this interoperability, the dependent regions establish a persistent Language Environment (LE) and use that LE to start the JVM. The Java dependent regions also use a similar setup to start the JVM to run the main Java application, which can then call COBOL code.

This is a great way to modernize your IMS applications!

How to enable this IMS enhancement

This new enhancement in IMS takes advantage of new function provided by:

  • The Language Environment (LE)
  • The COBOL compiler
  • The 64-bit IBM Java Software Development Kit (SDK)

That means that a 31-bit COBOL application can now call 64-bit Java code and a 64-bit Java application can now call 31-bit COBOL code.

That's got to be an interesting conversation!

To enable this interoperability support, you can configure the IMS dependent regions to establish a persistent 31-bit LE for running the 31-bit COBOL code and a new 64-bit LE for running the 64-bit Java code in a 64-bit JVM.

The new secondary 64-bit LE is established during dependent region initialization. It's anchored off the 31-bit LE and will remain until the 31-bit LE is terminated.

This image shows the topology of an IMS dependent region enabled with support for 31-bit COBOL and 64-bit Java interoperability. It depicts the primary 31-bit LE enclave for running COBOL code, and the secondary 64-bit LE enclave for running Java code.

To activate this new runtime environment in an IMS dependent region, all you need to do is complete these three steps:

  1. Install the APAR maintenance that provides the support: IMS (APAR PH37140), LE (APARs PH28966 and PH40444), COBOL (APAR PH37101), and Java SDK (V8.0.6.36 (Fix Pack 36)).
  2. Update the dependent region’s JCL to include the startup parameter JVM=3164 and add the SDFSJLIB to the STEPLIB concatenation.
  3. Configure the dependent region to access the latest 64-bit Java SDK (LIBPATH= in DFSJVMEV).

To simplify the configuration of the JVM, the dependent region will automatically include the new required JVM option -XX:+Enable3164Interoperability when it starts the 64-bit JVM.

As you can see, the process to enable the feature in an IMS dependent region is as simple as 1-2-3.

Application program changes

Because there are two different addressing modes in play, some application changes were inevitable, specifically:

  • Changes to COBOL data items
  • Compiling COBOL code

Changes to COBOL data items

For example, in 31-bit COBOL code, the data items that are used to interact with Java Native Interface (JNI) types such as jobject, jclass, jmethodID, etc., must be declared as PIC 9(18) COMP-5 (an 8-byte data item).

Let’s say a data item to hold the reference to a Java class object is currently defined as:

02  MySimpleClass object reference jclass.

Then, its definition must change to:

02  MySimpleClass pic 9(18) comp-5.

You can continue to use the JNIEnvPtr COBOL special register that contains the environment pointer to obtain the address for the JNI environment structure. That part of the application logic remains unchanged.

Compiling COBOL code

The COBOL code must be compiled using the DLL side-deck files libjvm31.x (provided by the Java SDK) and igzxjni2.x (provided by COBOL). These new DLL side-deck files are required so the appropriate code is generated and executed at run time.

And you are done!

Just like that you can have an IMS dependent region configured to run an application interoperating between 31-bit COBOL and 64-bit Java.

Updated March 2022:

Here are the two tutorials I created showcasing 31-bit COBOL and 64-bit Java interoperability in IMS. These two tutorials aim to be a starting point for anyone wanting to mix COBOL and Java, in this new mixed addressing mode, and don’t know where to start. The code samples include commentary to highlight the important portions of code and to give you a better understanding of how things fit together.

This first tutorial, Modernizing an IMS COBOL application with 64-bit Java: a tutorial, is for the scenario where the main IMS application is written in COBOL and it calls a Java method.

The second tutorial, Leveraging COBOL business logic from 64-bit Java: a tutorial, is for the scenario where the main IMS application is written in Java and it calls a native method written in COBOL, which serves as a thin wrapper to then call procedural COBOL.

Let's keep our applications talking!

0 comments
46 views