First, I would like to start off saying that I am a programmer not a network administrator. Our network administrator does not find this to be a problem, so I am seeking help. I have always been told when writing programs that connect to servers and other computers to use IP Address and not Host Name. The current problem is on our local network. Sometimes we can not connect to computers by IP Address. If that happens, we can use the Host Name and it works fine. If we restart the computer, connecting by IP Address starts working again. It could be days before it doesn't work or it could be a matter of hours. Or Network Administrator is now requiring us to create our programs that connect to other computers/servers with IP Address, but if that does not work, to try Host Name. Sometimes he even wants us to use two different host names. This does not make any since to me. I though IP Address was a direct route and Host Name went through a translation and used the IP Address anyway. Does anyone know why sometimes IP Address would not work on a Network but the Host Name does? Our network consists of a couple Novell Servers and some AS400 systems.

The IP address of the remote machine may not stay the same. In which case, you wouldn't be able to connect via IP. Life is more painless for those who are brainless.

Just my opinion but your network admin is a bit off. You should be using host names and then ip addresses. Why? Because if using dhcp the ip address associated with a host name will change. This is why dynamic dns exists. DNS is updated by dhcp as to what the host name is that is associated with that assigned ip address. If the admin is doing static ip assignments than his request would indicate a lack of DNS maintenance on his part to me. Host name to ip and ip to host name is a constant conversion process. It is the way human language communicates with machine language and back again. Imagine the power if you knew how to internet search

Some ideas to look at. http://www.examcram2.com/articles/a... http://support.microsoft.com/kb/323388