- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: ISG Navigator responds with wrong IP address
Operating System - OpenVMS
1755393
Members
3057
Online
108832
Solutions
Forums
Categories
Company
Local Language
юдл
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
юдл
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Go to solution
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-09-2011 05:31 AM
тАО03-09-2011 05:31 AM
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
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
Solved! Go to Solution.
3 REPLIES 3
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-09-2011 06:03 AM
тАО03-09-2011 06:03 AM
Re: ISG Navigator responds with wrong IP address
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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-09-2011 07:42 AM
тАО03-09-2011 07:42 AM
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-09-2011 03:22 PM
тАО03-09-2011 03:22 PM
Re: ISG Navigator responds with wrong IP address
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
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
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
News and Events
Support
© Copyright 2024 Hewlett Packard Enterprise Development LP