TCP/IP v5.1-4 and name resolver problem

[Aaron Sakovich]

I've got a VMS 7.3 system running TCP/IP v5.1-4 (dated, I know, but we've plans to upgrade -- just not yet.)

The bind resolver (NB: resolver, NOT server) has been working for several weeks, but I'm afraid someone has tweaked something without my knowledge (too many sys admins -- I'll deal with that problem later). In subsequent analysis, it looks like the communications domain was changed; setting it back to the proper value, to match the value in the name config, and I can no longer do name resolution, best typified by trying to run nslookup, which results in "*** Can't initialize resolver."

For example, if I now TCPIP STOP NAME, followed by TCPIP START NAME, and TCPIP SHOW NAME, I see "Local domain: *Mismatch*". If I then TCPIP SET COMM/DOMAIN="mypreferred.domain"/LOCAL=myhost, I no longer get the *Mismatch*. I do a TCPIP SET NAME/ENABLE/SYSTEM and all looks well from the config side.

However, issuing any TCPIP SHOW HOST results in a %TCPIP-W-NORECORD, -RMS-E-RNF pair of errors. Running nslookup returns the aforementioned "*** Can't initialize resolver."

What am I missing? Is there a dangling logical? A config parameter I've forgotten? Please don't tell me to reboot...

Regards & TIA,
Aaron

[Ian Miller.]

Try
TCP SET NAME/SYS/DOMAIN="mypreferred.domain"

[Martin P.J. Zinser]

Hello Aaron,

most probably the easiest is to go
through tcpip$configure.com and setup the
domain and nameservice in there.

Greetings, Martin

[Aaron Sakovich]

Hi Ian & Martin,

Already tried both of those items, but just to be sure, I did them again. No joy -- I still see the RNF.

There appears to be a mismatch between the bind resolver setup and the communications settings. The logical UCX$INET_DOMAIN points to the wrong domain, and the logical SYS$NET_SERVICES_3 points to the old FQDN.

I thought the usage of the UCX$INET_DOMAIN would have been deprecated, but regardless, what's the BEST way for me to go about 1) changing these settings on the live system and ensuring it gets set for all pertinent processes and 2) ensuring it is set properly for subsequent reboots?

Thanks,
Aaron

[Martin P.J. Zinser]

Hello Aaron,

you might want to check

http://forums1.itrc.hp.com/service/forums/bizsupport/questionanswer.do?threadId=533729

which sounds very similar to your situation.

Unfortunatly it seems in that case the problem was "resolved" by a reboot...

One more suggestion: can you try to redefine the logicals up to the next reboot manually?
If you do, check the mode of the logical. I would expect /sys/exec , but make sure with a show logical /full before you change anything.

Greetings, Martin