SET CONF SMTP/GATE=ALT

[Phillip Helbig---undress to reply]

If I change this, what, if anything, do I have to do to get it to take
effect?

[Jan-Erik Soderholm]

Phillip Helbig---undress to reply wrote 2012-09-19 13:36:
> If I change this, what, if anything, do I have to do to get it to take
> effect?
>

@sys$startup:tcpip$smtp_shutdown
@sys$startup:tcpip$smtp_startup

As far as I know.

[Phillip Helbig---undress to reply]

In article <k3cbmq$4uj$1...@news.albasani.net>, Jan-Erik Soderholm
<jan-erik....@telia.com> writes:

> @sys$startup:tcpip$smtp_shutdown
> @sys$startup:tcpip$smtp_startup

That is certainly sufficient, but is it necessary? What about

TCPIP> STOP MAIL
TCPIP> START MAIL

(STOP doesn't appear to be documented; START MAIL allegedly starts the
sender.)

[Stephen Hoffman]

To your original question, why are you even asking this? What's your
goal here?

Are you seeking knowledge of the innards of (a particular version of)
TCP/IP Services?

Or to solve a particular problem with a gateway change?

In either case, a quick test (starting and stopping the SMTP server
using the documented means, either just the server or the whole IP
stack) is certainly far faster than having posted a question here and
waiting for the follow ups, which implies that the simple "bounce-IP"
answer isn't the one you're looking for.

As for the other question, I'd use the (undocumented) START and STOP
stuff only if I wanted to see weird issues run-time environment, or at
the direction of HP support, etc. Those (undocumented) commands
generally don't set up the same environment as the provided DCL startup
and shutdown procedures.

It'd be nice if the whole environment were managed more consistently -
either with the TCPIP utility or with the procedure, but not the
current mixture of "both" - but that's not the way the current TCP/IP
Services software works.

(It'd also be nice if the SMTP mail server acquired more modern
features as it's rather archaic by current standards, but I digress.)

AFAIK, using the (undocumented) START and STOP commands directly can
derail at least a couple of the servers. I don't know off-hand if
it'll hork the SMTP server, though I'm not inclined to test its
efficacy. But do feel free to see if an undocumented command has
undocumented side-effects, and provide some undocumentation for folks.


--
Pure Personal Opinion | HoffmanLabs LLC

[Phillip Helbig---undress to reply]

In article <k3cfhi$jhk$1...@dont-email.me>, Stephen Hoffman

<seao...@hoffmanlabs.invalid> writes:

> >> @sys$startup:tcpip$smtp_shutdown
> >> @sys$startup:tcpip$smtp_startup
> >
> > That is certainly sufficient, but is it necessary? What about
> >
> > TCPIP> STOP MAIL
> > TCPIP> START MAIL
> >
> > (STOP doesn't appear to be documented; START MAIL allegedly starts the
> > sender.)
>
> To your original question, why are you even asking this? What's your
> goal here?
>
> Are you seeking knowledge of the innards of (a particular version of)
> TCP/IP Services?
>
> Or to solve a particular problem with a gateway change?

Primarily the latter (i.e. changing the gateway), but why not use this
to learn something as well (such as why HELP mentions START MAIL but not
STOP MAIL).

> In either case, a quick test (starting and stopping the SMTP server
> using the documented means, either just the server or the whole IP
> stack) is certainly far faster than having posted a question here and
> waiting for the follow ups, which implies that the simple "bounce-IP"
> answer isn't the one you're looking for.

Since various displays run over TCPIP, I don't want to stop the whole
stack. Stopping and starting STMP as suggested would certainly work,
but I'm wondering if it is perhaps overkill.

> As for the other question, I'd use the (undocumented) START and STOP
> stuff only if I wanted to see weird issues run-time environment, or at
> the direction of HP support, etc. Those (undocumented) commands
> generally don't set up the same environment as the provided DCL startup
> and shutdown procedures.

START is documented:

START

MAIL

Manually starts the SMTP sender queues (not the receiver
[server]).

Related commands: SHOW MAIL, ENABLE SERVICE SMTP, SHOW
CONFIGURATION SMTP

Format

START MAIL




Additional information available:

Restrictions Examples

START MAIL Subtopic?
START Subtopic?
Topic?
TCPIP> sh vers

HP TCP/IP Services for OpenVMS Alpha Version V5.4 - ECO 7
on a Digital AlphaStation 500/500 running OpenVMS V7.3-2

> It'd be nice if the whole environment were managed more consistently -
> either with the TCPIP utility or with the procedure, but not the
> current mixture of "both" - but that's not the way the current TCP/IP
> Services software works.

Indeed!

> (It'd also be nice if the SMTP mail server acquired more modern
> features as it's rather archaic by current standards, but I digress.)

Indeed!

[Phillip Helbig---undress to reply]

In article <k3cg1n$c8j$1...@online.de>, hel...@astro.multiCLOTHESvax.de

(Phillip Helbig---undress to reply) writes:

> > Are you seeking knowledge of the innards of (a particular version of)
> > TCP/IP Services?
> >
> > Or to solve a particular problem with a gateway change?
>
> Primarily the latter (i.e. changing the gateway), but why not use this
> to learn something as well (such as why HELP mentions START MAIL but not
> STOP MAIL).

Of course, conceivably it could be a dynamic parameter and not require
restarting anything at all. (The "CONFIGURATION" indicates something
else, i.e. this usually refers to changing the "permanent" on-disk
configuration, as opposed to the one in memory, but this might not be
entirely consistent; with SMTP, there is no SET, only SET CONFIG.)

[Stephen Hoffman]

On 2012-09-19 13:07:03 +0000, Phillip Helbig---undress to reply said:

>
> Primarily the latter (i.e. changing the gateway), but why not use this
> to learn something as well (such as why HELP mentions START MAIL but not
> STOP MAIL).

Yeah; the HP TCP/IP Services engineer I discussed those with (some
years ago) was not fond of it. He specifically told me that it doesn't
(didn't) work reliably. That the procedures were the recommended path
for stopping and starting component servers.

> Since various displays run over TCPIP, I don't want to stop the whole
> stack. Stopping and starting STMP as suggested would certainly work,
> but I'm wondering if it is perhaps overkill.

Entirely local option, obviously.

I don't usually have interactive logins on the servers that I deal
with, other than (occasionally) from the management folks. And the
management folks can generally "eat reboot" (with advanced notice), per
local practices. (More on why follows...)

Consider creating procedures that allow you to quickly restore sessions
and save off and restore command buffers (RECALL /OUTPUT, etc), using
certificates and/or XDM or whatever automation, if that might help
reduce your hesitation around the effort involved with restarts and
reboots.

In the bigger (and more robust) server environments, they're expressly
configured and applications programmed to allow server restarts.

As I've mentioned in other postings, I don't see long uptimes as a
valuable nor a laudable goal. I see it more as a symptom of a
potential problem. Evidence that the configuration can't easily or
quickly or transparently restart, or that the configuration might not
even restart correctly, or that the configuration is down-revision.
Being able to restart with minimal disruption is far more valuable than
uptime, in my experience.

> START is documented

AFAIK, it doesn't necessarily work reliably. See if it's listed
anywhere as a recommended procedure for (for instance) restarting SMTP.
AFAIK, it isn't. But this is certainly fodder for HP decide, though
I'm presuming you don't have support for these boxes.

[Paul Sture]

In article <k3cg1n$c8j$1...@online.de>,
hel...@astro.multiCLOTHESvax.de (Phillip Helbig---undress to reply)

wrote:

> Since various displays run over TCPIP, I don't want to stop the whole
> stack. Stopping and starting STMP as suggested would certainly work,
> but I'm wondering if it is perhaps overkill.

Why not use TCPIP$CONFIG.COM to stop and start SMTP?

No VMS instances up at the moment (don't ask), but IIRC TCP$CONFIG calls
other command procedures with names like TCPIP$START_SMTP.COM and
TCPIP$STOP_SMTP.COM.

--
Paul Sture

[Phillip Helbig---undress to reply]

In article <k3chjk$lm$1...@dont-email.me>, Stephen Hoffman

<seao...@hoffmanlabs.invalid> writes:

> As I've mentioned in other postings, I don't see long uptimes as a
> valuable nor a laudable goal. I see it more as a symptom of a
> potential problem. Evidence that the configuration can't easily or
> quickly or transparently restart, or that the configuration might not
> even restart correctly, or that the configuration is down-revision.
> Being able to restart with minimal disruption is far more valuable than
> uptime, in my experience.

Back in March, I experienced the only planned power outage (and only the
third altogether) I've ever experienced in Germany. I was in Italy at
the time and my wife had sent me an email saying it was coming. I could
have logged in and shut things down cleanly, but I decided to use it as
a test. So, the power went off and there was a VERY HARD reboot, but
everything came back up OK.

My reason to avoid a reboot (or even shutting down TCPIP) is that while
it always works, it's nice to learn if there is a faster way, which
might be necessary sometime.

[Stephen Hoffman]

On 2012-09-19 15:29:24 +0000, Phillip Helbig---undress to reply said:

> So, the power went off and there was a VERY HARD reboot, but everything
> came back up OK.

And do get yourself a less-interruptable power supply, or risk frying
that antique-grade gear you're so fond of.

[JF Mezei]

The mail queue is a symbiont. There isn't much way to communicate to
it. So whenever you change the config, you need to stop it and restart
it so that it will read the new updated config.

[Stephen Hoffman]

Well, no.

There was probably no perceived value in adding in these communications
capabilities — including the coding and testing and documentation and
support efforts – as compared with other priorities. If anybody even
gave this configuration reload a second thought, and that's far from
certain. In terms of actually communicating with a symbiont, that part
is trivial. Well, it's trivial in as much as any similar IPC coding on
OpenVMS is trivial.

[Phillip Helbig---undress to reply]

In article <k3cppi$npl$1...@dont-email.me>, Stephen Hoffman

<seao...@hoffmanlabs.invalid> writes:

> On 2012-09-19 15:29:24 +0000, Phillip Helbig---undress to reply said:
>
> > So, the power went off and there was a VERY HARD reboot, but everything
> > came back up OK.
>
> And do get yourself a less-interruptable power supply, or risk frying
> that antique-grade gear you're so fond of.

Probably a good idea. I don't know what the actual power consumption
is, perhaps a kW at peak times. Is it worth measuring it with some
induction device? How accurate is that? How much would a UPS cost?

Fond of the gear? Beggars can't be choosers. I wouldn't mind running
Itanium blades, but they aren't yet cheaply available (as far as I
know). However, I do confess a fondness for the older gear, as it was
built well, running for years or decades.