I am creating new Java functionality which will run on Mainframe ZOS. (Now we can run Java on IBM Mainframe.) we are a big Natural Adabas shop - just wondering when my natural and Java applications will run on the mainframe - do I need to have any middleware to communicate between Java and natural and vice versa? when I checked the documentation it says from natural to call Java we can use JNI - but we need to create some “C” wrapper to access Java. Java to Natural - Via Entire X. These are all very old posts.
Is there any update in the Natural / Adabas products where we can access Java which is running on the mainframe?
Can someone help with the steps to implement - Call Java directly from Natural and vice versa without any middle/ware and any C wrapper.
Thanks in advance - hoping will get a positive response
With EntireX SDK you can generate a “Java Class I/O interface (that’s the new term to replace term Wrapper)”. Use the SDK to extract the IDL from a NATURAL subprogram first then you can generate the IO interface. You will need to run NATURAL RPC server to expose the NATURAL subprogram as a service.
Eugene (Gene) Miklovich
ADABAS/NATURAL Systems Support and DBA
Cell: 916-202-7047
Normal Hours: 8am-4pm E.T.
Please call or text if assistance needed outside these hours.
Thank you for your response; it is greatly appreciated.
Given that both the Natural application and the new Java application are running on the mainframe, do I still need EntireX? I am exploring a solution similar to JNI, which would establish bidirectional communication between Natural and Java. Could you please advise if this solution makes sense?
I was under the impression that EntireX is required only for interfacing external non-mainframe systems with Natural on the mainframe.
This appears to be nearly the same topic as raised by “ak_kannan Kannan_Alagarsamy” - perhaps you could review that discussion.
As there is no direct “call” function between Java and Natural (as Eugene has explained), a middleware of some sort is needed, whether it is passing sequential files back and forth or using a messaging tool like EntireX.
EntireX can either use web services or Java / Natural Wrappers to call to/from Java and Natural. Wrappers allow each tool to use it’s own native objects to communicate with the other platform. Web services have a bit more overhead, but allow more portability - Java calling Natural RPC services exposed as EntireX web services does not need an EntireX runtime, but the Wrappers approach will need an EntireX runtime available.
Thank you, Douglas - I am still trying to make it work using my beating around-bush solution I am not sure whether I will win or lose. This is what I am trying
Natural Program Calling COBOL - This works fine.
COBOL Program Calling Java on z/OS - This also works fine.
COBOL Calling Natural - No issues here.
Java Calling COBOL - This works without any problems.
The problem arises when I try to combine these scenarios:
Natural calls COBOL, and COBOL calls Java: This sequence results in a NAT9974 error (Natural termination forced by abend 4088 RC=03EC), indicating memory exhaustion. Based on my research, this seems related to LE (Language Environment) and RENT-REENTER settings.
Details:
I’m not using any middleware; instead, I use JNI for COBOL to call Java, which works as expected.
The issue seems to be that Natural does not properly wait for COBOL to complete the Java call and return, leading to the error.
I’ve tried adjusting memory regions (0M, 8M, 128M) with no success. I’m considering an alternative approach where JNI calls C, and Natural uses C to invoke Java.
I don’t know who will signal natural that Cobol is calling Java and give some data from Java to natural.
If this solution works - will keep you all posted. if you see any flaw in the solution please advice me
We are not trying to create our middleware using COBOL. Our POC aims to call a Java method from Natural via COBOL without using messaging or middleware.
Here’s what we’re attempting:
We can run Java on z/OS, and COBOL can call Java using JNI on z/OS.
We want to invoke a Natural program that calls a COBOL program, which in turn calls a Java program and returns a result to COBOL and then back to Natural.
Individually, the following work well:
Natural to COBOL: Passing parameters from Natural to COBOL works fine.
COBOL to Java: Passing parameters from COBOL to Java works fine. in this, able to process and return value to COBOL.
However, when executing the complete thread, it fails:
Initially, we encountered a Getmain error due to the Region parameter in the job. We set it to 0, resolving this issue.
We confirmed that Natural can pass parameters to COBOL and COBOL can read these values, (its proven solution).
When COBOL tries to invoke the Java method by passing the parameter received from Natural via the linkage section, it fails, stating it cannot find the Java method / unable to invoke the Java method.
I am unsure why the end-to-end process fails, as individual calls (Natural to COBOL and COBOL to Java) work. Do we need additional parameters at the Natural system level to facilitate this hybrid call? I am testing this in Batch mode.
Do you have any advice on whether this approach will work? I want to keep communication simple between the languages without introducing middleware or messaging components. If my COBOL program can successfully locate and invoke the Java method, the process should complete with the value returned to COBOL and then to Natural.
Do you recommend this solution, and is it worth pursuing this POC?
Software AG does not have any implementation in NAtural to invoke Java Method directly - when Java runs on Mainframe zOS? like what IBM did - using JNI to invoke the Java method from COBOL. or I don’t know whether I am missing something. When all are running on the mainframe - why do we need Entirex or Messaging to invoke and pass the parameter between the languages?
If I am correct, I think we can use JNI with C to communicate between Natural and Java without any middleware.
please let me know if there is any alternative solution when all are on the mainframe. kind of Natural Parms setting or some tweaking is required etc.
Douglas,
Purely by coincidence I have been working on calling Java from ASM/COBOL/higher level languages (e.g. NATURAL) as part of an open mainframe project. I had to provide the following key functionality (not an exhaustive list) to call Java from ASM/COBOL/etc within the same address space:
Simple calling API to send/receive data between ASM/COBOL/etc. and Java
Being able to dynamically load Java classes and call the method specified in the API
Start the JVM once and only once within the job step of the JCL
Capability to work with multi-threaded ASM/COBOL/etc. applications efficiently
Since it’s an ongoing open mainframe project it may be of some use to someone.
Neil.
Interesting! Which product starts the address space? Both Natural and Java like to have their runtime environment, which makes it difficult to keep both around and avoid the startup cost of the runtime on each access of the other’s processes.
Natural and Java both live in the same address space (64 bit so plenty of space). The JVM (JVMPRC16) starts a general purpose Java utility. The general purpose Java utility starts the actual “main” program – which reads/writes all its DD statements as it normally would. Communication then occurs via an API from the “main” ASM/3GL/higher level language (e.g. Natural) to dynamically call the Java class/method specified by the API calls.
I am not sure whether I will win or lose. This is what I am trying