ISG Navigator responds with wrong IP address

[Jeremy Begg]

Hi,

I've been helping a customer with a VMS upgrade on a rather old system. They were running OpenVMS VAX V6.2 with UCX V4.2 and ISG Navigator V1.6.

Last weekend I upgraded their "test" system to VMS V7.3 with TCP/IP Services V5.3-ECO4 but did not upgrade ISG Navigator. (It's long out of support.)

Since the upgrade, client PCs have no longer been able to use ISG Navigator. Examining the logs I see a crucial difference.

The pre-upgrade IRPCD.LOG file contains lines like these:

[1] Login: __server__ (192.160.20.2:1027, 27-Oct-10 11:18:47)
[1] Register Server PID 137/MACSTEST at 192.160.20.2:1026:tcp:691502758 for
MACS-TEST (Client#691502758)

Since the upgrade there has been a subtle but important change:

[1] Login: __server__ (127.0.0.1:49157, 04-Mar-11 18:01:24)
[1] Register Server PID 136/MACSTEST at 127.0.0.1:49156:tcp:509836966 for
MACS-TEST (Client#509836966)

It seems that before the upgrade the server process (running on the VAX) responded to the client PC with the VAX's IP address and port number; after the ugprade the server's IP address is given as 127.0.0.1. My guess is that the client then tries to connect to 127.0.0.1 (i.e. itself) and of course fails to find the server.

I've been looking through the ISG Navigator configuration files but can't see anywhere where it's possible to configure the server's IP address.

Has anyone encountered this problem before?

Thanks,
Jeremy Begg

[Hoff]

The ISG folks changed their name to Attunity a decade or so back, so (if you haven't already tried this) consider widening your search and have a look at the Attunity products.

Also have a look at upgrading the middleware here to something a little more current and to something with support. IIRC, the "ISG Navigator stuff is now the "Attunity Connect" stuff. See if they have an upgrade available.

If you want to try to reverse-engineering any settings that might be available for this stuff within the tools (and if that approach is permissible within your environment) then aim Hein's strings tools at the binaries and see what turns up.

...I'll assume that this VAX is an emulation, and that you've looked at either moving the whole show over to an Itanium box running OpenVMS I64 V8.3-1H1 or so, and at porting off of VMS. If not, there's more to look at here than just moving forward to V7.3.

[Duncan Morris · Accepted solution]

Jeremy,

I am not familiar with that ancient ISG version, but the following page references using irpcd to register a new address/port for the server

http://www.attunity.com/forums/openvms-data-access/attunity-connect-daemon-irpcd-failing-start-120.html

You might be able to use the -l option in your startup.

Have a look to see if any options show up with irpcd --h

irpcd --h

Form1 - Starting the daemon
irpcd [-n] [-b] [-v] [-d] [-e][-l daemon-location [r]] [-u username] [-p password]
start [configuration-daemon-name]

Form2 - Managing the daemon
irpcd [-l daemon_location] [-u username] [-p password]
command [arguments]

Commands: (not case sensitive, uppercase letters denote the command verbs)

APPLIST [app-name or app-mask]
RELOADINI
RESETLOG
SHUTDOWN [{ABORT|OPERATOR} ["why..."]]
STATUS [workspace-name]
REFRESH [workspace_name ]
KILL [workspace_name ]
TEST
ENABLE [workspace_name]
DISABLE [workspace_name]

Form3 - Registering the daemon service (Microsoft Windows only)
irpcd -s [un]register [[-n] [-v] [-l daemon-location [r]]
[-u username] [-p password] [-a service-name]
start [configuration-daemon-name]]


Duncan

[Jeremy Begg]

Duncan, thanks for those instructions!
I changed the startup procedure to specify the local host address using

$ IRPCD -l'f$trnlnm("TCPIP$INET_HOSTADDR")' START

and it's now working.

Thanks!
Jeremy Begg