HP OpenVMS TCPIP SMTP gives error after change of node name

[RobertsonEricW]

All,

I went through the node rename items described at http://labs.hoffmanlabs.com/node/589
(original node name of IQDEV1, new node name of DEMO1) and ended up
with everything working as expected except for the TCP/IP SMTP
service. The situation seems a little schizophrenic because the TCPIP
configuration seems to recognize it is now operating on the node with
the new name, but when you attempt to start the service it issues an
error and attempts to use a queue name with the old node name. Anyone
got any ideas on why this might be? What follows is what I think is
necessary to know. But if some other information would be useful, let
me know and I will happily provide it.

Thanks in advance for any wisdom,

Eric

$ TCPIP SHOW VERSION

HP TCP/IP Services for OpenVMS Alpha Version V5.7 - ECO 3
on an AlphaServer ES45 Model 2 running OpenVMS V8.3

$ TCPIP SHOW CONFIG SMTP

SMTP Configuration

Options
Initial interval: 0 00:30:00.00 Address_max: 16
NOEIGHT_BIT
Retry interval: 0 01:00:00.00 Hop_count_max: 16
NORELAY
Maximum interval: 3 00:00:00.00
TOP_HEADERS

Timeout Initial Mail Receipt Data
Terminate
Send: 5 5 5 3
10
Receive: 5

Alternate gateway: not defined
General gateway: not defined

Substitute domain: not defined
Zone: not defined

Postmaster: TCPIP$SMTP
Log file: SYS$SPECIFIC:[TCPIP$SMTP]TCPIP$SMTP_LOGFILE.LOG

Generic queue Queues Participating nodes

TCPIP$SMTP_DEMO1_00 1 DEMO1
$ @SYS$STARTUP:TCPIP$SMTP_STARTUP.COM
%TCPIP-I-INFO, image SYS$SHARE:TCPIP$SMTP_MAILSHR.EXE installed
%TCPIP-I-INFO, image SYS$SYSTEM:TCPIP$SMTP_RECEIVER.EXE installed
%TCPIP-I-INFO, logical names created
Initializing TCPIP$SMTP_IQDEV1_00 queue got status %SYSTEM-F-BADPARAM,
bad parameter value
%SYSTEM-F-BADPARAM, bad parameter value
%TCPIP-I-INFO, service queues started
%TCPIP-I-INFO, service enabled
%TCPIP-S-STARTDONE, TCPIP$SMTP startup completed
$

[Stephen Hoffman]

On 2012-10-30 14:21:23 +0000, RobertsonEricW said:

> All,
>
> I went through the node rename items described at
> http://labs.hoffmanlabs.com/node/589
> (original node name of IQDEV1, new node name of DEMO1) and ended up
> with everything working as expected except for the TCP/IP SMTP
> service. The situation seems a little schizophrenic because the TCPIP
> configuration seems to recognize it is now operating on the node with
> the new name, but when you attempt to start the service it issues an
> error and attempts to use a queue name with the old node name. Anyone
> got any ideas on why this might be? What follows is what I think is
> necessary to know. But if some other information would be useful, let
> me know and I will happily provide it.

...

As for the queues, disable the SMTP server via the TCPIP$CONFIG menus,
and then enable it and restart it, and see if you get a new set of SMTP
server queues created. If not, you could manually recreate the SMTP
queues, matching the settings of the old SMTP queues. I just checked
a test box that I'd renamed, and I still have the old queues hanging
around; off to delete those. IIRC, I stopped and disabled and
re-enabled and restarted most of the TCP/IP Services servers as part of
the rename.

If that works, let me know and I'll update the article.

This whole networking area of OpenVMS clearly wasn't ever actually
designed, and it's become an aggregation of hacks stretching back
decades. ...Though resolving this mess would have required the source
code equivalents of a flame thrower and a grenade launcher as part of
the requisite "design renovations".

FWIW and IIRC from the release notes, there have been changes to SMTP
in a recent ECO; they went to a Unix-style configuration file for some
features, rather than integrating the updates into the database. Check
the files and see if they've picked up a host name. While not related
to the queues, also check for host names in the TCPIP configuration
files.

--
Pure Personal Opinion | HoffmanLabs LLC

[RobertsonEricW]

Yes, I too went through the entire TCP/IP configuration using SYS$MANAGER:TCPIP$CONFIG.COM and still had this problem. The interesting thing is that I have renamed nodes before but don't remember having this problem. However, there may have been a subtle difference in how I went about renaming the node this time around as compared to the last time I did it.

Your suspicion regarding the UNIX-like configuration file may be correct. I found the file SYS$SYSDEVICE:[SYS0.TCPIP$SMTP]TCPIP$SMTP.CONF had an entry:

Queue-Name : TCPIP$SMTP_IQDEV1_00

within it. After changing this entry to read:

Queue-Name : TCPIP$SMTP_DEMO1_00

and saving it, I was able to restart the SMTP service without incident and the expected queues once again appeared in the system's list of queues.

However, before you go to the trouble of changing the article, I will once again rename the node paying more close attention to the procedure I used last time to see if I obtain a better result.

Thanks again for your help.

Eric

[Stephen Hoffman]

On 2012-10-30 16:46:31 +0000, RobertsonEricW said:

> Yes, I too went through the entire TCP/IP configuration using
> SYS$MANAGER:TCPIP$CONFIG.COM and still had this problem. The
> interesting thing is that I have renamed nodes before but don't
> remember having this problem. However, there may have been a subtle
> difference in how I went about renaming the node this time around as
> compared to the last time I did it.
>
> Your suspicion regarding the UNIX-like configuration file may be
> correct. I found the file
> SYS$SYSDEVICE:[SYS0.TCPIP$SMTP]TCPIP$SMTP.CONF had an entry:
>
> Queue-Name : TCPIP$SMTP_IQDEV1_00
>
> within it. After changing this entry to read:
>
> Queue-Name : TCPIP$SMTP_DEMO1_00
>
> and saving it, I was able to restart the SMTP service without incident
> and the expected queues once again appeared in the system's list of
> queues.

> ...

That seems a {limitation? misfeature? bug? undocumented feature?} of
TCP/IP Services. Whether that queue name string should (optionally?)
see a %s substitution with the host name string, or is something that
reconfiguring TCP/IP Services should fix, should get documented as an
extra step when changing the host name; whatever the chosen resolution.
But it seems, well, broken.

[Rich Jordan]

On Oct 30, 11:46 am, RobertsonEricW <robertsoner...@netzero.net>
wrote:

You have been bit by the same thing that got me. TCPIP V5.7 is
TOTALLY different.

The TCPIP SET CONFIG SMTP command (and SHOW CONFIG SMTP), most of the
TCPIP$SMTP* logicals, and the SMTP.CONFIG file method of SMTP
management were all replaced in TCPIP V5.7 with the TCPIP$SMTP.CONF
file you noted above.

The release notes are the only docs I've found about this change; none
of the main TCPIP manuals have been updated (at least online at the HP
website) so they still show the SET CONFIG SMTP and old config files
as the way to go.

When a system is upgraded from V5.6 to V5.7 the generic and execution
queue names get changed (they still incorporate the nodename) and new
ones get created with those names, but the OLD queue names do NOT go
away. You'll have stopped/dead queues hanging around until and unless
you clean them up. The upgrade is supposed to transfer part of the
config from the old method/files to the new TCPIP$SMTP.CONF file.

Coincidentally both V8.4 systems I have access to (both upgraded from
VMS V8.3 and TCPIP V5.6) also no longer stop the SMTP execution queues
when the SYS$STARTUP:TCPIP$SMTP_SHUTDOWN command is issued; they have
to be stopped manually. I haven't had the chance to do a clean V8.4
install with TCPIP V5.7 to see if there's any difference.

[RobertsonEricW]

Yes, I agree that it is rather obtuse behavior on the part of the HP TCP/IP Services for OpenVMS SMTP service. But, this is what it does currently. The funny thing is that the obsoleted TCPIP Services Database for SMTP correctly reflects the change in the queue name but this change is not propagated to the "new" SYS$SYSDEVICE:[SYS0.TCPIP$SMTP]TCPIP$SMTP.CONF file which is now actually used to control the execution of the SMTP service. As you suggested, it would have been smarter to base the queue name configuration entry on some string substitution syntax which would automatically adjust the queue name based on the node name active at the time the service is started.

I would consider this a bug (NOT a "feature"). But, my recent past experience with the HP OpenVMS Engineering people makes me think they will not agree with that conclusion. Even if they did miraculously agree that this behavior is a bug, I would not expect a fix any time soon.

I have since verified that using my original procedure for renaming the node does not produce a different result. So, I think what happened in my particular case was that I both updated to the newer version of HP TCP/IP Services for OpenVMS and enabled the SMTP service therein between the last time that I performed a node rename procedure and my most recent attempt. So, I guess for now (if you are so inclined) you should update your article to reflect this stupidity for V5.7 and later of HP TCP/IP Services for OpenVMS.

By the way, this all seems even more half baked when you find out that the SYS$SYSDEVICE:[SYS0.TCPIP$SMTP]TCPIP$SMTP_CONF.TEMPLATE file uses the queue name TCPIP$SMTP which has no node name within it at all!

Anyway, thanks for the help everyone.

Eric

[amit.s...@gmail.com]

Hi Gents,

We are also facing issue with SMTP after up-gradation to OS 8.4 and TCPIP V5.7-13. Mails are not delivering through SMTP. The SMTP.CONF file doesn't have any entry against Queue-name, but in the UCX SMTP database its showing a queue "TCPIP$SMTP_CSWASP_00". However if I see "sh queue *smtp*" its returning with other queue name.

CSWASP> sh que *smtp*
Generic server queue TCPIP$SMTP

Server queue TCPIP$SMTP_CSWASP_1, idle, on CSWASP::, mounted form DEFAULT

I have deleted these two queues, stopped SMTP, put entry into SMTP.CONF file for TCPIP$SMTP_CSWASP_00, and started SMTP. It gave error
"Initializing TCPIP$SMTP_CSWASP_00 queue got status %SYSTEM-F-BADPARAM, bad parameter value
%SYSTEM-F-BADPARAM, bad parameter value"
and no SMTP queue were present on system. then I stopped SMTP again, modified SMTP.CONF with "Queue-name : TCPIP$SMTP_CSWASP_1" and started SMTP. Now it gave me 3 SMTP queues :

CSWASP$ sh que *smtp*
Generic server queue TCPIP$SMTP

Server queue TCPIP$SMTP_CSWASP_1, idle, on CSWASP::, mounted form DEFAULT

Server queue TCPIP$SMTP_CSWASP_1_CSWASP_1, idle, on CSWASP::, mounted form DEFAULT

then, I have again modified SMTP.CONF file to its original version. Obviously mail sending is still not working on this node.

Any suggestion would be helpful.

Cheers
Amit

[Stephen Hoffman]

On 2013-05-20 07:21:58 +0000, amit.s...@gmail.com said:

> Hi Gents,

There are ladies here, too.

> We are also facing issue with SMTP after up-gradation to OS 8.4 and
> TCPIP V5.7-13. Mails are not delivering through SMTP. The SMTP.CONF
> file doesn't have any entry against Queue-name, but in the UCX SMTP
> database its showing a queue "TCPIP$SMTP_CSWASP_00". However if I see

> "sh queue *smtp*" its returning with other queue name........

>
> then, I have again modified SMTP.CONF file to its original version.
> Obviously mail sending is still not working on this node.
>
> Any suggestion would be helpful.

If you have HP support, call HP.

I'm going to assume you've dredged up this old thread but have not
changed the host name here; that you have an isolated error with an
upgrade. (If you have changed the host name, then re-check the steps
and ensure the box has been rebooted after the changes.)

There's probably either an error secondary to the upgrade, or there's
an error in the SMTP configuration file. User-edited configuration
files are painful to manage without implementing a decent file parser,
as the range of syntax errors is large. VMS also entirely lacks the
tools to manage a configuration file from DCL, too, whether it's a
defaults-like command syntax or lexical functions which would allow the
settings to be stored and retrieved. Rolling your own file-parsing
code means adding bugs and/or testing, and can mean using
lib$table_parse or another parser and building a VMS-style control
program (CP) tool, too. Or upgrading the UCX command utility to
implement and integrate the required settings. But I digress.

If you don't have HP support or if you need a faster answer than that
call might provide, set your recall buffer huge within your terminal
emulator, turn on DCL verification, reset and re-run the SMTP
processing, and go hunting through the DCL output for HP's DCL bug,
which should then point to what I'd guess is a configuration file
syntax error. Cmd-A Cmd-C over into a text editor, then search for
the DCL error, and work backwards from that error to the trigger.
Again, it's probably a configuration file syntax error.

The brute-force approach would be to get the host name and related
working as desired, shut down and disable the SMTP server entirely,
delete the SMTP directory and the configuration files and SMTP queues
and related baggage, and then re-add it all back in. Basically, try
again.

[Phillip Helbig---undress to reply]

In article <kndcqu$2b7$1...@dont-email.me>, Stephen Hoffman

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

> User-edited configuration
> files are painful to manage without implementing a decent file parser,
> as the range of syntax errors is large. VMS also entirely lacks the
> tools to manage a configuration file from DCL, too, whether it's a
> defaults-like command syntax or lexical functions which would allow the
> settings to be stored and retrieved.

VMS TCPIP used to be configurable via a command-line interface, which
WOULD catch syntax errors etc. But then the decision was made to go to
the unix-like user-editable plain-text configuration file. Even if VMS
TCPIP is ported from some unix stack, surely it would have been worth
the effort to maintain the TCPIP> interface?

[Stephen Hoffman]

If that was not rhetorical, then that's a question best addressed to
the folks at HP. They best know what the trade-offs were here, after
all.

TCP/IP Services package has long used the UCX$CONFIG / TCPIP$CONFIG
configuration tool as a wrapper around the UCX / TCPIP utility and
related files, but the configuration tool has clearly found an expanded
role in recent years. All of the TCP/IP Services release I've
encountered have used a variety of service-specific configuration
files, too. The SMTP configuration file isn't an entirely new
implementation pattern.

I've previously posted comments around my preference for configuration
tools <http://labs.hoffmanlabs.com/node/1007>, though hand-editing
configuration files is certainly lightweight and very simple to
implement. I've implemented a lib$table_parse parser for managing the
NEWUSER <http://labs.hoffmanlabs.com/node/1260> data, too.

It might behoove you to review and potentially recalibrate your concept
of what's typical of Unix management, as well. While some
distributions still target hand-ended configuration files, the Unix
distribution I use seldom involves or requires directly editing
configuration files. In recent years, it's more common for me to be
editing configuration files on VMS than on Unix systems, including
managing VMS via the Apache, Samba/CIFS, MODPARAMS.DAT, DNS,
SYLOGICALS.COM, SYSTARTUP_VMS.COM and other configuration files.

As I've suggested once or twice before, look around and see what other
options and alternatives are available. Unix isn't what it used to
be. Nor is VMS, for that matter.

[amit sharma]

Hi Everyone, Thanks for reply.

I forgot to mention that, I had dig up this old thread, because there was change in HOST name.

Basically, here what we have done :

1) Image backup of Prod server (CSWAXP, vms 7.3)
2) Minimum boot of backup disk on Spare server (CSWASP)
3) Changed the decnet ID, IP address, SCSNODE and SCSSYSTEMID as per Spare server (CSWASP) and booted the Spare node.
4) Upgraded the CSWASP to vms 8.4 on Spare server (CSWASP).
5) Everything worked except SMTP.
6) Tried some of the steps mentioned in this forum, and some other, but nothing seems to fix the problem.

Now, we are thinking to re-install TCPIP or contact to HP.

Regards,

[Peter 'EPLAN' LANGSTOeGER]

In article <e6b00ab0-5ada-4a8b...@googlegroups.com>, amit.s...@gmail.com writes:
>We are also facing issue with SMTP after up-gradation to OS 8.4 and TCPIP V=
>5.7-13.

We also did some years ago (when we changed to TCPIP V5.7 (but kept on 8.3)

> Mails are not delivering through SMTP. The SMTP.CONF file doesn't h=
>ave any entry against Queue-name, but in the UCX SMTP database its showing =
>a queue "TCPIP$SMTP_CSWASP_00". However if I see "sh queue *smtp*" its retu=
>rning with other queue name.

The SMTP configuration changed with V5.7
and we had been bitten by Anti-SPAM features of V5.7
(wrong configuration setting, which had been incorrectly ignored in V5.6)

After ~3 years, I no longer remember the details (only the fact, that I
should have read the TCPIP release notes more carefully - it's documented)

I also remember, that the names of the TCPIP SMTP queues changed with 5.7
Instead of one generic SMTP queue *per node* (named _00 - and one or more
execution queues _01 ... _nn - configured in SET CONF SMTP), there is now
one generic SMTP queue *per cluster* (named TCPIP$SMTP) directing to all
existing execution queues (usually one *per node* named _1)

I also remember deleting the old SMTP queues per hand
(as they weren't touched by new configuration procedures)!

>I have deleted these two queues, stopped SMTP, put entry into SMTP.CONF fil=
>e for TCPIP$SMTP_CSWASP_00, and started SMTP. It gave error=20
>"Initializing TCPIP$SMTP_CSWASP_00 queue got status %SYSTEM-F-BADPARAM, bad=

> parameter value
>%SYSTEM-F-BADPARAM, bad parameter value"

My TCPIP$SMTP.CONF was created during TCPIP upgrade and I haven't changed
anything for TCPIP queue names. Therefore it reads:

Queue-Name :

>and no SMTP queue were present on system. then I stopped SMTP again, modifi=
>ed SMTP.CONF with "Queue-name : TCPIP$SMTP_CSWASP_1" and started SMTP. Now =

>it gave me 3 SMTP queues :
>
>CSWASP$ sh que *smtp*
>Generic server queue TCPIP$SMTP
>
>Server queue TCPIP$SMTP_CSWASP_1, idle, on CSWASP::, mounted form DEFAULT
>

>Server queue TCPIP$SMTP_CSWASP_1_CSWASP_1, idle, on CSWASP::, mounted form =
>DEFAULT
>
>then, I have again modified SMTP.CONF file to its original version. Obvious=

>ly mail sending is still not working on this node.
>
>Any suggestion would be helpful.

*) Use SHOW QUEUE/FULL (especially with TCPIP$SMTP) to understand the system.
*) Delete all the SMTP queues again
*) Remove the queue name from TCPIP$SMTP.CONF (to use the default name)
*) Reconfigure SMTP with the documented procedures
*) Then you have one TCPIP$SMTP and one (or more) TCPIP$SMTP_CSWASP_n queue(s)
*) And finally consider to RTFM again

HIH

--
Peter "EPLAN" LANGST�GER
Network and OpenVMS system specialist
E-mail Pe...@LANGSTOeGER.at
A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist

[Stephen Hoffman]

On 2013-05-21 04:57:57 +0000, amit sharma said:

> 6) Tried some of the steps mentioned in this forum, and some other, but
> nothing seems to fix the problem.
>
> Now, we are thinking to re-install TCPIP or contact to HP.

Your postings aren't sufficiently detailed for me to be able to sort
out what happened, what you've tried, nor what errors or diagnostics or
issues you've seen beyond that DCL error mentioned up-thread.

As mentioned up-thread, enable a long recall buffer in your terminal
emulator or otherwise record your session, turn on DCL verification,
and go hunting for the DCL bug that was being generated in (presumably)
TCPIP$CONFIG. That'll provide you with some details of where the HP
DCL code failed, and working backwards from there should show what
failure(s) or corruptions are presumably lurking in the TCPIP$SMTP.CONF
configuration file.

Or desk-check that TCPIP$SMTP.CONF file, minimally.

I wouldn't expect a reinstallation of TCP/IP Services to resolve this.
Not without some extra clean-up steps beyond those performed by
removing and reinstalling the kit via PCSI. The general sequence for
cleanup would shut off SMTP, restart IP (or VMS), clean up the
TCPIP$SMTP directory, clean out and delete the SMTP queues, and then
reconfigure and restart TCP/IP Services. Basically, brute-force reset
the SMTP server. I'd not expect a TCP/IP Services reinstallation to
clean up the mess that was left, in other words. Not without verifying
the deletion, that is.

Or call the folks at the HP support center, or somebody familiar with
troubleshooting SMTP mail on OpenVMS, yes.

Separately from the host name change morass, I'd suggest efforts to
improve the reproducability of your production environment, working
toward the goal of being able to install on a scratch disk from distro
kits, restore your database(s) from backup, and commencing operations.

[Peter 'EPLAN' LANGSTOeGER]

In article <knfslb$cbq$1...@dont-email.me>, Stephen Hoffman <seao...@hoffmanlabs.invalid> writes:
>On 2013-05-21 04:57:57 +0000, amit sharma said:
>
>> 6) Tried some of the steps mentioned in this forum, and some other, but
>> nothing seems to fix the problem.
>>
>> Now, we are thinking to re-install TCPIP or contact to HP.

Not neccessary in my eyes.

>Your postings aren't sufficiently detailed for me to be able to sort
>out what happened, what you've tried, nor what errors or diagnostics or
>issues you've seen beyond that DCL error mentioned up-thread.

While I second the idea to always provide more details in a posted
question, I had the (educated) guess that the DCL error was
issued by having a too long queue name (and so gave my hints).

I admit, that the TCPIP configuration procedure of SMTP is not that
good, but works for most of us.

So, if the OP still has problems, then he will hopefully write
again (with more details)...

Btw:
I faced a problem with the configuration by wanting a system which
only allows to send mails out of VMS, but not to receive any of them.
In contrast to other SMTP packages (like MX freeware), TCPIP/UCX
does not let you the SMTP sender/client and the SMTP receiver/server
be handled separately (means if you shutdown the TCPIP SMTP server,
you can't *send* mail - with $ MAIL)

Our Solution was to restrict the SMTP server to "localhost".
But this restriction (still) can't be done after SMTP service creation.
And the TCPIP configuration procedure (still) has nothing to implement
this restriction. So, I had to delete the SMTP service, and recreate
it *by hand* (with $ UCX SET SERVICE/ADDRESS=localhost SMTP/...).
This worked and is in use for many years now...

[Phillip Helbig---undress to reply]

In article <519b7100$1...@news.langstoeger.at>, pe...@langstoeger.at (Peter

'EPLAN' LANGSTOeGER) writes:

> I also remember, that the names of the TCPIP SMTP queues changed with 5.7
> Instead of one generic SMTP queue *per node* (named _00 - and one or more
> execution queues _01 ... _nn - configured in SET CONF SMTP), there is now
> one generic SMTP queue *per cluster* (named TCPIP$SMTP) directing to all
> existing execution queues (usually one *per node* named _1)

Finally someone involved in TCPIP understood the concept of generic and
execution queues!