|
Jeff,NetServer needs to know it's host and IP address. The problem with IP address is that the system can have many of them, so how does it know which one is the "main" IP address?
So what it does is take your hostname (QDILGARD in your case) and try to perform a DNS lookup to get the IP address. It will then use that as the main IP address for NetServer.
Apparently your DNS was set up to contact Internet DNS servers -- so the lookup would fail (or time out) before getting a result for QDILGARD. Therefore it could not start the NetServer.
Putting QDILGARD in the host table means that it'll always be able to find it's own IP address, even if the network is down. So this is considered a "best practice" to always have the IP address that's connected to the system name be in the host table. Granted, this does mean that there's one more place to change it if the IP address changes... but as long as this (and the DNS server) are the only places, that shouldn't be too cumbersome. A lot better than being down when the Internet is offline!
-SK On 5/14/2015 1:47 PM, Jeff Crosby wrote:
midrange.com
I learned something this morning and thought I would pass it along in case
it helps someone else.
The day started with the internet being down. In doing backup checks I
noticed the BRMS recovery reports had not been copied to a Windows file
server within the domain. Reason is because Netserver was not started.
Tried to reset and start Netserver and got this in QSYSOPR (I stripped out
some portions):
Message ID . . . . . . : CPIB683
Date sent . . . . . . : 05/14/15 Time sent . . . . . . :
07:16:51
Message . . . . : IBM i Support for Windows Network Neighborhood (IBM i
NetServer) was unable to start.
Cause . . . . . : The required IBM i NetServer job QZLSSERVER was unable
to
start because of reason code 13. See the following reason codes and
their
meanings:
13 - The retrieved host IP address of 6.0.0.7 is invalid.
Recovery . . . : Complete recovery for the specified reason code.
13 - Correct the name configured for IBM i NetServer which conflicts with
an existing name on the network, and try the request again.
The Netserver name has not changed since day one so I opened a PMR (by
phone since no internet either!). No idea what the 6.0.0.7 IP address is .
. .
After the internet came back up just for fun I tried starting Netserver
again and it worked. Huh? What does the internet have to do with it?
Rochester called in response to the PMR and she said she could fix that.
In CHGTCPDMN we have 3 DNS servers listed, 1 internal Windows and 2
Comcast. The 2 external have something to do with it. So she had me add
the Netserver name "QDILGARD" to the host table entries on the IBM i so it
would find the IP address for the i there. With or without internet. She
was aware of this behavior but could not answer why. She was curious
herself, said she would ask the developer when he arrived, and report back
to me via the PMR.
I waited until now hoping the PMR would have something of an explanation,
but it still does not. If I get something I will pass it along.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
