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

[Jan-Erik Soderholm]

David Froble wrote 2014-09-10 19:27:
> Simon Clubley wrote:
>> On 2014-09-10, Jan-Erik Soderholm <jan-erik.soderholm at telia.com> wrote:
>>> Simon Clubley wrote 2014-09-10 14:01:
>>>> What I've setup the backup procedures to do every night is to
>>>> have the command procedure dump the queues, entries, and other
>>>> details to text files which then get backed up as part of the
>>>> backup routine.
>>>>
>>>> This gives me a reasonably up to date view of the queue configuration
>>>> in human readable format which can be used to recreate the configuration
>>>> if the queue manager database is corrupted for some reason.
>>>>
>>> Nice, of course. But do you also expect your queues to
>>> be empty (even non-existant) simply becuse a reboot?
>>> That was the question here.
>>>
>>
>> I was thinking more of David's original comment about defining the
>> queues in case of the risk of queue corruption. My approach is a
>> different way of tackling the same concern which doesn't have an
>> impact on the existing queues _and_ also records other information.
>>
>> And no, I don't expect the queues to be empty because of a reboot
>> (unless, possibly, that reboot comes about because of a power
>> failure at just the wrong time or hardware failure. :-))
>>
>>> And anyway, all our queue definitions are in the startup
>>> sequence and everything *would* be created from scratch
>>> if they should disapear for some reason.
>>>
>>
>> Do you also define the forms and queue characteristics at startup ?
>>
>> Simon.
>>
>
> I will change my objection to those who manually configure queues, and do
> not have command files to set up the queues if they become lost or
> corrupt.  Ok?

That is fine. And of course quite different from loosing
all queues and entries at reboot and *always* having
to recreate everything from scratch... :-)

If that is Ok? Of course it is, I was right. :-)

And yes, to interactively create your queues without
having any COM file to redo it, is not what I would do.

Jan-Erik.