Skip to main content

I have been able to LOAD a COBOL DLL - using com.microfocus.cobol.RuntimeSystem.cobload(xxx.dll) - from inside of a Spring Application that is running in a JBOSS or WAS Server when using version 3.0 of Visual COBOL or COBOL SERVER runtime in a Windows environment and using OpenJDK 1.8.0_265.

In addition, after the LOAD, I was successfully able to execute the COBOL DLL with a call to com.microfocus.cobo.RuntimeSystem.cobcall("PROGRAM_ENTRYPOINT", params).

I have now upgraded to version 6.0 of VCE and COBOL Server and get the below message on Windows when attempting the LOAD itself - not got to cobcall as yet:

"java.lang.UnsatisfiedLinkError: COBOL Runtime - unsupported JVM"

I am also attempting for the first time, to compile to SO (Unix) and LOAD the same on the App Server (JBOSS) running on Linux where I get the below message (compiled and linked via Dev Hub):

"Application should use "cobjrun" to execute this application instead of the default "java" trigger.

Question: How would you call a DLL or SO file from an Application Server like JBOSS. Would it be any different from what I was successfully able to do with Visual COBOL 3.0. Does the cobol code have to be compiled to JVM COBOL Byte code first as some microfocus documents suggest. How do I do that. How was it working so far for me in VCE 3.0 My current working setup is NOT running under JNI.


#JBOSSApplicationServer
#LoadDLLorSO
#VisualCOBOL

I have been able to LOAD a COBOL DLL - using com.microfocus.cobol.RuntimeSystem.cobload(xxx.dll) - from inside of a Spring Application that is running in a JBOSS or WAS Server when using version 3.0 of Visual COBOL or COBOL SERVER runtime in a Windows environment and using OpenJDK 1.8.0_265.

In addition, after the LOAD, I was successfully able to execute the COBOL DLL with a call to com.microfocus.cobo.RuntimeSystem.cobcall("PROGRAM_ENTRYPOINT", params).

I have now upgraded to version 6.0 of VCE and COBOL Server and get the below message on Windows when attempting the LOAD itself - not got to cobcall as yet:

"java.lang.UnsatisfiedLinkError: COBOL Runtime - unsupported JVM"

I am also attempting for the first time, to compile to SO (Unix) and LOAD the same on the App Server (JBOSS) running on Linux where I get the below message (compiled and linked via Dev Hub):

"Application should use "cobjrun" to execute this application instead of the default "java" trigger.

Question: How would you call a DLL or SO file from an Application Server like JBOSS. Would it be any different from what I was successfully able to do with Visual COBOL 3.0. Does the cobol code have to be compiled to JVM COBOL Byte code first as some microfocus documents suggest. How do I do that. How was it working so far for me in VCE 3.0 My current working setup is NOT running under JNI.


#JBOSSApplicationServer
#LoadDLLorSO
#VisualCOBOL

Hi Dennis,

Since you already have a support incident, 3244794 open for these questions I thought that I would mention that I had been working with Blair McDonald along with our Development group to formulate a reply to your questions in the incident which appear to be the same ones that you pose here. The answer to these questions will remain the same as what we had previously provided.

The method that you are using to call COBOL from Java, RuntimeSystem.cobload/cobcall are for use within a J2SE environment when you are running the application directly under a JVM. If you wish to call COBOL from Java when running under an Application Server environment (J2EE) then this method is not supported.

The recommended methods are either to run with your native COBOL running under Enterprise Server and access it by means of an EJB and Resource Adapter or to compile the COBOL sources to Java byte code in which case the compiled classes can be run directly under the Application Server. The EJB method has been supported since NX/SX 4.0 and the Java byte code method is new to Visual COBOL.

This is covered in the docs in the section Using COBOL and Java Together.

BTW, the J2SE RuntimeSystem.cobload/cobcall methods do use JNI indirectly under the covers.

Terms & ConditionsAccessibility statement