Natural/Adabas to Java interface on the same Mainframe LPAR

, , , , ,
1

Hi All,

May I know the steps, including environmental setup required to complete the following PoC tasks.

  1. Java to Natural.
  2. Natural to Java.
  3. Java to Adabas.

Assumptions:

  1. Test those three connections/interface within same Mainframe LPAR (No external environment).
  2. Natural vers 9.2.1.

Thanks,
Kannan A

2

when you say “Java to Natural” and “Natural to Java” what are you trying to do? call services provided in Java from Natural and services provided in Natural to Java?

There is a Java API for calling Adabas, as well as CONNX JDBC that Java can use to access Adabas.

Are you using Java on the mainframe or calling the mainframe from an open systems Java platform?

3

Thanks you for your prompt response. I need to use the Java on Mainframe and there is no external environment like open systems.

4

when you say “Java to Natural” and “Natural to Java” what are you trying to do? call services provided in Java from Natural and services provided in Natural to Java?

If your services are exposed as web services (REST, SOAP), then you can either use EntireX to wrap those services (simplest) or you can consume services in Natural using the REQUEST DOCUMENT statement.

5

This is just a PoC and we are trying find a simple way to communicate between Natural/Adabas and Java. Invoking Natural in Java and Java in Natural to support these requirements. Is there a way to use simple communication than using EntireX/RPC/IDL/CONNX tools? Please advise.

6

If the PoC is looking to do asynchronous communications between mainframe-based Natural/Adabas and distributed Java applications you could consider using a messaging interface (such as IBM MQ) to send and receive messages from either end. EntireX could still factor into that setup to make the interfacing between Natural and MQ work via RPC wrappers although there are other ways to accomplish the same. Having a messaging intermediary can be useful for resilience and scaling dependent on degree of coupling desired and expected usage patterns and requirements.

If you are looking to access Adabas (data) from distributed Java then using middleware to support SQL-based data access could be used. In that setup the assumption is you don’t need to call NATURAL (or have Natural call Java).

With EntireX you could make use of RPC calls and could think of NATURAL/Adabas applications as being similar to remote-procedure calls (or perhaps think of them as database stored procedures if you are looking for the NATURAL code to perform the business logic working off Adabas-based data).

The latter two are more tightly coupled requiring running processes (or triggers to initiate services) etc. All doable of course but needs testing and thinking around monitoring; alerting; error handling and performance tuning dependent on the use-case.

For your PoC I think you need to spell out the intended use-case and requirements you would want to prove out…

7

There are many ways to do this but here are some simple ways:

8

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.