HP3000-L Archives

April 1995, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Jeff Kell <[log in to unmask]>
Reply To:
Jeff Kell <[log in to unmask]>
Date:
Wed, 12 Apr 1995 16:42:53 EDT
Content-Type:
text/plain
Parts/Attachments:
text/plain (32 lines)
On Wed, 12 Apr 1995 07:47:01 CDT R J Kennedy said:
>--We have been having a problem with Oracle's SQLNET program reading
> the RESLVCNF.NET.SYS file.  When the file is there the SQLNET program
> is unable to connect from our Hp/9000 to the Hp/3000 and access Image.
 
Hmmm... really strange unless they're trying to reverse-map you, and that
should fail in either case if it fails with it present.  The primary goal
of RESLVCNF is to enable DNS resolution through an outside server.
 
>   domain  mmm.com
>   nameserver  (IP address of our name server)
 
It might help if the 9000 is defined in HOSTS.NET.SYS.  It sounds very
much like a security-based thing rather than an access problem since the
presence of RESLVCNF increases your connectivity rather than the converse.
 
> My question is:  Is this file related in any way to the entries in
>                  the net directory file in the NMMGR program.
 
Well, no, other than perhaps changing it's order of preference in the
process of resolving a name.  In 4.0, having RESLVCNF caused DNS name
resolution to be performed FIRST, then HOSTS/NSDIR (not sure about the
order there).  I don't know if this was changed in 5.0.
 
>  My thoughts are that it's the information in the file that is causing
>  SQLNET the problems and not the existance of the file.
 
The data should be valid; but it might be upset if your Probe name is not
the same as your DNS name (wild guess there).
 
[\] Jeff Kell, [log in to unmask]

ATOM RSS1 RSS2