Unix RPC server connection to EntireX broker on Windows machine

Werner_van_Tonder · April 9, 2024, 8:19pm

Good day

We have issues setting up a EntireX broker on our Unix machine and cannot seem to find an answer on this forum or from Software AG Support and we are having a crisis in that our payments cannot run; thus I’m now opting for a PLAN B

So I had setup a EntireX 10.3 broker on a windows machine and got the etb server up and running as well as the etbnuc and the system says ‘Ready for Communication’

However I now want to start a Natural RPC server that connects to this broker. According to the documentation one has to setup the SRVNODE to ‘IPADDRESS:PORT:TCP’ i.e ‘123.123.123.123:1234:TCP’, but when I startup the server nothing seems to happen. No errors are thrown, but the server is not running.

Has anybody on here attempted this scenario where the EntireX setup basically runs ons a total difference machine/server to what the Natural RPC is running and got it to work?

Thank You
Werner

Douglas_Kelly · April 9, 2024, 8:55pm

Sure. Usual suspects for problems:

firewall ports - make sure the Windows Firewall is configured to allow your port (eg 1234) to be accessed by other servers (inbound rule)
is Natural available on that server - buffer pool, shared memory, permissions to any files (parms, output) involved (check natlog)
authentication (EntireX Security, Natural Security)

Does the EntireX Broker (trace log level 1) show the RPC server reaching it? anything in cmprint/cmprt10? Natural RPC trace (at least level 1) active?

wolfgang.winter · April 9, 2024, 9:16pm

In addition to what Douglas came up with already:

Natural license expired ?

The most important thing definitiely is enabling a NATURAL RPC trace, that’ll tell you right away why it doesn’t come up.

Werner_van_Tonder · April 10, 2024, 5:30am

Hi Douglas

So I did setup the port on the Firewall.

What we have have all the SAG products installed on a Solaris Zone on top of SPARC architecture. So Firmware update was done on the underlying SPARC machine and it was cold started and since then all the software came up accept for the etbnuc which gives us a Segmentation Fault error and dumps the core.
PS: We don’t use SAG security on any of the products - it was done like that over 30 years ago when the stack ran on OPENVMS; thus I got it like that… :-)…so don’t judge me…hehe

We’ve tried several attempts, but to no avail, thus Plan B which I have never done before. So Plan B involves setting up the complete EntireX stack on a windows machine which I already did and setting up the Broker Attribute file mimic what we have on the UNIX machine. PS: I see SMH is not available anymore and Command Central I don’t see on the software download

So the Natural RPC is called in Server mode with the SRVNODE setup as ETB048 in a natparm.

I.e:
natural parm=RPC1WN$DBID udb=$DBID etid=$$ trace=2

So in the documentation for the SRVNODE setup it says one can use ETB000 or one can specify TCP/IP among other things in the format as specified in my post. So my thought process was that it would connect to the TCP/IP…

So trace is set at 1, but it doesn’t show anything…it just shows this:
NATURAL V 6.3.9 PL 0 Software AG 2010
as it does if the EntireX setup is done on Solaris…

I’m not an expert on this…so any export advice would be appreciated…

wolfgang.winter · April 10, 2024, 7:17am

You should never see the Natural version string thrown to a terminal for server mode.

ETB048 in natparm … is it defined in HOSTS and SERVICES, i.e. can NATURAL resolve the host / port ?

Werner_van_Tonder · April 10, 2024, 7:42am

It is defined and it did work if the RPC server and the EntireX service and broker runs one the same machine.

Ok lets ask the question differently.

If you start the broker on a windows machine and you start an RPC Nat server on UNIX; how does the Entire Broker know to send requests to the RPC server on Unix. Is there a setup on EntireX on Windows that you must specify where to find the RPC… Hope I’m asking the question better…

Thanks You

Steen_Kromann · April 10, 2024, 9:38am

Hi, I haven’t been working with EntireX for like 20 years but I guess it is still pretty much the same.
I have worked in environments where the broker ran on mainframe and servers and clients were from everywhere (Windows, Unix, Digital …) so this shouldn’t be a problem.

Some questions that pop my mind:

I wonder what you mean by “the server is not running” - does it stop or just hangs around?
If it hangs around, can you see any connections in a netstat command?
Can you do a telnet to the broker host and port?

Kind regards
Steen

Werner_van_Tonder · April 10, 2024, 10:22am

Good @Steen_Kromann
So the broker server comes up on the Unix machine (etbsrv)
The Admin Server comes up (etbadm)
However the broker (etbnuc) don’t want to start - as soon as you start it it gives a message: Segmentation Fault - core dump and then it exits. We even tried stopping the etbsrv to rule out that and same issue.
So we can telnet to the Admin IP:57707 no problem.

As we don’t have any idea what ‘Segmentation Fault’ means from an EntireX point of view it makes it difficult to diagnose why the broker don’t want to start.
All that we can conclude it might be corrupt files somewhere or something is wrong the memory. We are really only spitballing as none of us is experts on how the product works irrespective of versions.

Hence why I’m trying to start the EntireX stack on a different environment (as a Plan B and also after the crisis to move it of the same installation as the rest to separate services). So currently I’ve managed to start etbsrv, etbcmd and etbnuc on the windows server.
And I’ve manage to connect to it via a Java Process to make sure that I can indeed communicate to the broker at least via the following Java call:
Broker b = new Broker(“146.232.129.160:5048”, “PersonService”);

      System.out.println(  b.getConnInfo() + " " + b.kernelversion());

So now the next step is that I want to make a call to a RPC server (NATURAL RPC, or XML Server, etc) from this broker.

I cannot manage to find a setup variable or attribute that you can tell the Broker where to connect to the RPC server other than this setup in the broker attribute file:
CLASS = RPC, SERVER = SRV1, SERVICE = CALLNAT

So If I do something like this in Java - after creating a Java Client Stub from a Natural Sub-Program:

Xws401n2 xws401n2 = new Xws401n2(new Broker(“146.232.129.160:5048”, “PersonService”), “RPC/SRV1/CALLNAT”);

The broker contains the Broker Server on Windows, and “RPC/SRV1/CALLNAT” I suppose is the “link” to the RPC Natural server…that is what I understand.

Hope this makes sense.

Steen_Kromann · April 10, 2024, 10:40am

Regarding the segmentation error it could probably be something not installed properly, but I would open a Software AG support ticket.

The communication between the broker and the servers are working in the oppesite direction.
You first start the broker, with the services defined in the attribute file, and the you start the servers who the connects to the broker and registers their services.
After registration the server calls the broker and waits for incoming requests from clients.
So the broker doesn’t know anything of the location of the servers.
Hope this clears that part up.

The same should apply for the admin server, which makes me wonder how you can telnet it …?

Holger_von_Thomsen · April 10, 2024, 12:56pm

Hi Werner,

which version of Solaris are you running on your SPARC?
Latest version I know of is 11.4.

Please consider to switch over to other Hardware in the next years, as Oracle Support for Solaris and SPARC is ending in 2035.

Regards,
Holger

Werner_van_Tonder · April 10, 2024, 12:59pm

Oh sorry what I meant was I telnet from Unix machine to the broker IP and port setup to make sure it can be accessed from the UNIX machine.

So ok what you are saying is that the EntireX server on the Windows machine is correct is it is; thus there is no other setups required.

So then it leaves as with the Nat RPC that has to be setup to connect to this EntireX server and once connected, the EntireX server on Windows should pick this ‘connection’

So now my following question where to a specify this connection:
In the NatParm I did this:

In the documentation they state that one has to setup SRVNODE up as follows:

This this correct? I used the 2cnd example as currently with our none working EntireX UNIX setup we used the first option in the list of examples…

Werner_van_Tonder · April 10, 2024, 1:16pm

Hi @Holger_von_Thomsen
We are still on Solaris 10 or The Zone is on 10. Not sure on what operating system the underlying SPARC is on. Ok it seems like the following; sorry I’m not the SYSADMIN…
Solaris 10 Sun SPARC 64
Yes. However the Software AG products on the machine is also very old versions and not sure if these versions will work on the the latest Solaris. Nat is still on 6.3.9…

Management don’t want to spend money on upgrading as we are in the process of migrating our systems on to cloud based packages…or we have already migrated our Financial and Student Systems to Cloud based solutions…or HR system has already been migrated over 10 years ago to Oracle HR.

So we only have 3 systems left; thus it is not feasible to spend the money on upgrading and the risk associated with it.

So in other words we need to keep the lights on with what we have until the rest has also been migrated.

The current SAG stack has been in operation for over 30 years.

Werner_van_Tonder · April 10, 2024, 5:35pm

We managed to get our system up and running. It boiled down to a etb…lic5.so library that basically couldn’t read the license file and thus thrown a segmentation fault. We replaced it with a version from 2011 and we got our systems up and running.

However I still want to get the windows EntireX setup up and running to connect to a RPC server on unix. I think it is just best practice not to keep such an important component installed on each environment with the rest of the software…just my feeling.

Douglas_Kelly · April 10, 2024, 5:50pm

When you put SRVNODE in the Natural Configuration Utility (natparm), leave out the quotes. You can use DNS name for the host (host:port:TCP) portion.

Are you using Natural Security?

Holger_von_Thomsen · April 10, 2024, 6:27pm

Hi Werner,

understood.

Good to see that you are working on it as Solaris 10 is already EOL without support from Oracle.
Hopefully you will have finished your migrations to cloud until support for Solaris and SPARC ends in 2035.

Regards,
Holger