- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- problem with tcpip $qio interface ?
Categories
Company
Local Language
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
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
Community
Resources
Forums
Blogs
- 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
тАО01-10-2011 05:36 AM
тАО01-10-2011 05:36 AM
problem with tcpip $qio interface ?
The machines have 3 NICs, one of them dedicated to cluster traffic.
After setting up the remaining NICs as failover set (lla0) we observe some strange behaviour:
name resolution of nfs, telnetsym and self written software only work with the local host database. Tools like ping are working fine.
Our self written software uses the $qio interface to resolve network names (IO$_ACPCONTROL with INETACP_FUNC$C_GETHOSTBYNAME,..).
A similar configuration running OpenVMS 7.3-2 and TCPIP V5.4 - ECO 7 is working as expected.
Any suggestions?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-10-2011 06:05 AM
тАО01-10-2011 06:05 AM
Re: problem with tcpip $qio interface ?
> self written software only work with the
> local host database. [...]
Which kind of "not work" is this, exactly?
> [...] Tools like ping are working fine.
When you ask them to do what, exactly?
What does nslookup do?
> A similar configuration [...]
With my weak psychic powers, I can't see much
of the configuration of either system.
Actual output from actual commands could be
useful, like, say:
tcpip show name
tcpip show route
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-10-2011 06:44 AM
тАО01-10-2011 06:44 AM
Re: problem with tcpip $qio interface ?
> Which kind of "not work" is this, exactly?
They do not resolve any network name that is not stored in the local host database.
> When you ask them to do what, exactly?
ping mycomputer is working.
ping mycomputer.domain is working.
ftp mycomputer is working.
> What does nslookup do?
nslookup mycomputer is not working.
nslookup mycomputer.domain is working !!!
(default domain and domain path are set correctly).
> Actual output from actual commands could be
> useful, like, say:
> tcpip show name
> tcpip show route
cluster member #1
tcpip show route
DYNAMIC
Type Destination Gateway
AN 0.0.0.0 10.59.81.1
AN 10.59.0.0/16 10.59.50.71
AH 10.59.50.71 10.59.50.71
AH 127.0.0.1 127.0.0.1
tcpip show name
BIND Resolver Parameters
Local domain:
System
State: Started, Enabled
Transport: UDP
Domain:
Retry: 4
Timeout: 2
Servers:
Path:
Process
State: Enabled
Transport:
Domain:
Retry:
Timeout:
Servers:
Path:
cluster member #2
tcpip show route
DYNAMIC
Type Destination Gateway
AN 0.0.0.0 10.59.81.1
AN 10.59.0.0/16 10.59.50.72
AH 10.59.50.70 10.59.50.70
AH 10.59.50.72 10.59.50.72
AH 127.0.0.1 127.0.0.1
(member 2)
tcpip show name
BIND Resolver Parameters
Local domain:
System
State: Started, Enabled
Transport: UDP
Domain:
Retry: 4
Timeout: 2
Servers:
Path:
Process
State: Enabled
Transport:
Domain:
Retry:
Timeout:
Servers:
Path:
> With my weak psychic powers, I can't see much
> of the configuration of either system.
One cluster consists of 2 DS20 running OVMS 8.3 and TCPIP 5.6 ECO 3, the other cluster consists of 2 DS20 running OVMS 7.3-2 and TCPIP 5.4 ECO 7.
All systems (4 DS20) have 3 NICS, one of them dedicated to cluster traffic, the remaining two NICS configured as failover device LLA0.
The cluster with the older version is working fine, the cluster with 8.3 worked until the day we reconfigured the NICs to a failover set.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-10-2011 06:49 AM
тАО01-10-2011 06:49 AM
Re: problem with tcpip $qio interface ?
>tcpip show route
>DYNAMIC
Means that your system expects to receive information from some other system in order to figure out where to send packets that are addresses to some other system. Is this the same on both systems? If not, then change the non-working system to match the working system.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-10-2011 06:51 AM
тАО01-10-2011 06:51 AM
Re: problem with tcpip $qio interface ?
this is a copy/paste error.
Both systems are DYNAMIC.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-10-2011 07:23 AM
тАО01-10-2011 07:23 AM
Re: problem with tcpip $qio interface ?
You might also try changing the non-working system to use the working system for name resolving.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-10-2011 10:18 AM
тАО01-10-2011 10:18 AM
Re: problem with tcpip $qio interface ?
If not TCPDUMP, perhaps trace the actual network using WireShark or similar tool? "Not working" covers a wide variety of potential problems, more data would be (extremely) helpful.
- Bob Gezelter,