[Info-vax] Changing SMTP server presented hostname in UCX

[Simon Clubley]

On 2014-09-08, Simon Clubley <clubley at remove_me.eisner.decus.org-Earth.UFP> wrote:
> On 2014-09-08, Paul Sture <nospam at sture.ch> wrote:
>> On 2014-09-08, Simon Clubley
>><clubley at remove_me.eisner.decus.org-Earth.UFP> wrote:
>>>
>>> There's clearly something in the core components section I had missed
>>> so please can you point me to the correct option in TCPIP$CONFIG to
>>> directly change the hostname (not the domain) in the configuration
>>> databases ? Thanks. (Of everything I've done with VMS, I've never
>>> had to actually change the TCP/IP hostname of an existing production
>>> VMS machine.)
>>
>> The hostname (i.e. node name) certainly used to be in the Interfaces
>> section.
>>
>
> I'll have another look at the Interface section tomorrow thanks, but
> I don't remember seeing any option to change just the hostname by
> itself on an existing configuration.
>

Well I decided to try and fix this with the Interface option because
I assumed it would just update a couple of hostname fields as nothing
else was changed. :-(

Fortunately, since I know my way around the UCX CLI it didn't take too
long before TCP/IP was working again properly however.

Like I said yesterday, the Unix approach of using text configuration
files looks very appealing when compared to a half baked interface to
a binary database.

First off, looking once again revealed there was indeed no seperate
hostname update question so I changed just the hostname on the primary
interface while leaving everything else alone.

This resulted in _all_ the aliases for the Alpha been deleted from
the local hosts database. Fortunately, I had made a note of them so
it was easy to recraate them from the UCX CLI.

The next thing I discovered a few minutes later was that the users
couldn't reach devices on various subnets on the local network.

It turns out that the ^&^%^&% TCPIP$CONFIG procedure had deleted all
the manually entered routes from the dynamic database. They were still
in the permanent database however. Fortunately, once again it was
easy enough to put them back into the dynamic database once I realised
what had happened.

==> Yes, that's right. Changing just the hostname (while leaving
everything else alone) caused all the manual routes to various subnets
to be deleted from the dynamic database. I was _NOT_ expecting that.

On Unix, that would be like changing /etc/hosts and getting all your
manual routes deleted as a result of doing so. :-(

Oh, and after all that, it didn't even touch the hostname entered
using "ucx set [config] comm/local" which is the basis of the
*INET_HOST logicals.

Entering "ucx set [config] comm/local="new_name"" manually resulted
in me _now_ been able to set the name I wanted, but it only updated
TCPIP$INET_HOST and left UCX$INET_HOST alone.

> It's also a strange place to put it as the various CLI set/show
> communication options don't qualify the hostname by interface and
> neither does the logical at the heart of this.
>

I hope this little saga helps someone in the future.

If VSI want to sell systems to new non-existing VMS customers, it's
going to have to produce something a lot better than this current
mess. You should not have to shut everything down and reboot the
system just to update the TCP/IP hostname (which is clearly what
the intended usage model here is.)

Simon.

-- 
Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world