Microfocus Visual Cobol for Eclipse, destination Tomcat 7.0 on RHEL 6.10.

I have tried the tutorial Visual Cobol as SOAP webservice (Book) and it works fine.
I try now to have one of our Cobol to work and it does it partially:

The program itself runs but into it I do a call to an external logging module which is in another directory.

This external module is deployed as .so file and works if I use it from a standard Cobol test program (executable) on the server.

I added the library path LD_LIBRARY_PATH at start of Tomcat and as JAVA_OPTS="-Djava.library.path=/data/mylibrary".

If I do a CALL "coblog" USING... ON EXCEPTION ...return the LD-LIBRAY_PATH, this one seems correct but nevertheless, I get a return code " <faultstring>173 Called program file not found in drive/directory [coblog]</faultstring>".

Can someone point me to where I should look for?

Can "coblog" be compiled to JVM bytecode?

Using a native shared object in tomcat is not recommended by tomcat, because if the native code crashes it will bring down the process.

This module is used by others and the  fact is that appart of coblog, the head module act as a router to other cobol modules (.so) all based on authentication and authorization.
This is a full cobol programs stack which uses Entirex as message broker and we will make it directly accessible by the clients which are communicating with SOAP protocol.
The full way is client <-> (soap) Entirex broker (ACI) <-> cobol stack.

The fact that it can crash if one submodule crash should be handeld by the entry module itself, not by tomcat.

I can't see how the code can handle a crash without using signals and this again prohibited in Java Runtime Environment, as it uses various signals to handle jitting.

Things to remember using native code in tomcat:

•  the native code needs to run in a very small native stack because the code will be executing under the Java Runtime Environment which by default allocates small native stacks per thread.
•  if the native code uses thread primitives it will leak memory due to the fact it is being used in a thread-pool and will not get a thread cleanup
• if the java service causes a class loader to be recycled a memory leak is probable in the native code if it has allocated any memory as it is given no chance to cleanup
  
  The process of enabling native code in tomcat will most certainly require you to change the default java trigger to the cobjrun trigger.
  
  Lastly, there is a distinct possibility you will only be able to the COBOL runtimes JNI support in one web application as no specific support for native code in tomcat is provided.
  
  This is due to JNI only allowing one native code library to be loaded into one classloader at a time.

Thank you for this explanation.

In short, if I well understand, it is not possible to have a cobol as webservice (like book sample) calling other(s) native cobol like an external logging module?

If this is the case, it cannot be used to reach our goal: having one entry point which serves different native cobol backends.

tomcat is a java application server and is best suited to applications that are bytecode based eg: java, kotlin, jvm cobol.  

The only time native code is used in tomcat is for JDBC drivers or bespoke JNI based solution using the tomcat apis.

As I said, it may be possible to reconfigure tomcat to use the cobjrun trigger rather than the java trigger but extra work will be required to get the native code to work in more than one application at a time.   Someone with tomcat/jni/classloader experience might know how to do this but I, unfortunately, don't.

If your goal is to make your COBOL available as a REST or Web Service to be consumed by java, then using Enterprise Server would be something to consider because it is a native code solution.   In this environment reusing your native shared object is not an issue.

https://www.microfocus.com/documentation/enterprise-developer/ed50pu2/ED-VS2019/index.html?t=GUID-58BF06B8-029A-46A0-8AA2-3E9A0A52B162.html