topic Re: Turning off TCPIP stack dumping in Operating System - OpenVMS

Turning off TCPIP stack dumping

Dan Herron — Thu, 21 Jan 2010 12:53:38 GMT

I am using the MAIL$ utility routines to programatically send email.

When I invoke MAIL$SEND_ADD_ADDRESS and pass it an invalid email address, like smtp%joe@blow. (notice the missing COM or NET after the final period) TCPIP returns a warning "%TCPIP-E-SMTP_BADADDR, recipient address is illegal; unparsed string: @." and then stack dumps.

I have no problem with the error message, but do not want the program to abort/stack dump as I have code within the calling program to handle the situation. I have included the MAIL$_NOSIGNAL item in the input item list when calling MAIL$SEND_ADD_ADDRESS but this does not turn off TCPIP's need to signal the error and stack dump.

How do I turn off the signal/stack dump so that MAIL$SEND_ADD_ADDRESS will just return the error status to the calling program?

Thanks for your help,
Dan Herron

Re: Turning off TCPIP stack dumping

Volker Halle — Thu, 21 Jan 2010 13:17:12 GMT

Dan,

can your reproduce this behaviour using MAIL ?

$ MAIL
MAIL> SEND
To: smtp%joe@blow.

What happens ?

Volker.

Re: Turning off TCPIP stack dumping

Dan Herron — Thu, 21 Jan 2010 13:19:06 GMT

Volker,

MAIL> send
To: smtp%joe@blow.
%TCPIP-E-SMTP_BADADDR, recipient address is illegal; unparsed string: @.
%TCPIP-E-SMTP_ABORT, SMTP session aborted

MAIL>

Same error message. No stack dump. Control is returned to the calling program..in this case MAIL.

Thanks,
Dan

Re: Turning off TCPIP stack dumping

Volker Halle — Thu, 21 Jan 2010 13:22:38 GMT

Dan,

could you provide an example output of the 'stack dump' ?

Volker.

Re: Turning off TCPIP stack dumping

Dan Herron — Thu, 21 Jan 2010 13:24:22 GMT

Volker,
%TCPIP-E-SMTP_BADADDR, recipient address is illegal; unparsed string: @.
%TRACE-E-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
TCPIP$SMTP_MAILSHR 0 000000000006E2D8 000000000221E2D8
TCPIP$SMTP_MAILSHR 0 0000000000070A44 0000000002220A44
MAILSHR 0 0000000000044CC8 0000000000720CC8
MAILSHR 0 000000000003C138 0000000000718138
MAILSHR 0 000000000003C954 0000000000718954
0 FFFFFFFF808B5F18 FFFFFFFF808B5F18
MAILSHR 0 000000000003AF48 0000000000716F48
MAILSHR 0 000000000003B63C 000000000071763C
MAILSHR 0 000000000003B8E0 00000000007178E0
MAILSHR 0 0000000000036F64 0000000000712F64
MAILSHR 0 0000000000037368 0000000000713368
TEST_EMAIL_TYPE_SEND MAIL_SEND_ADD_ADDRESS MAIL_SEND_ADD_ADDRESS
1265 000000000000037C 000000000007C82C
TEST_EMAIL_TYPE_SEND EMAIL_SEND_ARRAY EMAIL_SEND_ARRAY
1623 0000000000000934 0000000000070A94
TEST_EMAIL_TYPE_SEND EMAIL_TYPE_SEND EMAIL_TYPE_SEND
1079 0000000000000D7C 00000000000622DC
TEST_EMAIL_TYPE_SEND TEST_EMAIL_TYPE_SEND$MAIN TEST_EMAIL_TYPE_SEND$MAIN
544 00000000000002F8 00000000000602F8
0 FFFFFFFF8028163C FFFFFFFF8028163C
%TCPIP
-SYSTEM
-CLI
%F-NORMAL, normal successful completion
%?-NOMSG, Message number 0000534E
%E-ILLSER, illegal service call number
%?-NORMAL
%?-BADIMGHDR
%E-ILLSER
%?, normal successful completion
%BADPARAM, bad parameter value
%TRACE-E-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
0 FFFFFFFF80888954 FFFFFFFF80888954
DEC$BASRTL 0 000000000000E48C 00000000007EE48C
----- above condition handler called with exception 0764B39A:

----- end of exception message
0 FFFFFFFF800B7CCC FFFFFFFF800B7CCC
0 FFFFFFFF80888954 FFFFFFFF80888954
TEST_EMAIL_TYPE_SEND MAIL_SEND_ADD_ADDRESS MAIL_SEND_ADD_ADDRESS
1312 0000000000000584 000000000007CA34
TEST_EMAIL_TYPE_SEND EMAIL_SEND_ARRAY EMAIL_SEND_ARRAY
1623 0000000000000934 0000000000070A94
TEST_EMAIL_TYPE_SEND EMAIL_TYPE_SEND EMAIL_TYPE_SEND
1079 0000000000000D7C 00000000000622DC
TEST_EMAIL_TYPE_SEND TEST_EMAIL_TYPE_SEND$MAIN TEST_EMAIL_TYPE_SEND$MAIN
544 00000000000002F8 00000000000602F8
0 FFFFFFFF8028163C FFFFFFFF8028163C

Re: Turning off TCPIP stack dumping

Volker Halle — Thu, 21 Jan 2010 13:31:35 GMT

Dan,

did you try $ LINK/NOTRACE ?

Volker.

Re: Turning off TCPIP stack dumping

Dan Herron — Thu, 21 Jan 2010 13:37:21 GMT

Yes, I have NOTRACE on the compile and the link. But to of no avail.

Dan

Re: Turning off TCPIP stack dumping

Volker Halle — Thu, 21 Jan 2010 13:49:46 GMT

Dan,

MAIL uses it's own condition handler, which re-signals only in case of an ACCVIO. Otherwise it ignores the signal (returning SS$_CONTINUE) or prints the error message.

Volker.

Re: Turning off TCPIP stack dumping

Hoff — Thu, 21 Jan 2010 14:39:17 GMT

You may well be able to make the case that the MAIL$_NOSIGNAL should do this for you, but that's for HP OpenVMS Engineering to decide, and (even in the best possible case) any fix for this probably won't arrive on your schedule here. This matter is for y'all and for HP to discuss more directly, though.

If you have a condition handler established within your code and it's not getting triggered for this case, then you've arguably encountered a (bigger) bug in either the MAIL API or within TCP/IP Services. Various OpenVMS APIs (and particularly the older APIs) can and do use signals.

The simplest way to suppress these often looks like this:

lib$establish( lib$sig_to_ret );

Then start calling the MAIL$ routines; I usually have a set of wrappers (I've posted a set of wrappers with a BSD license in the NEWUSER code) and the wrappers here would include the declaration of the signal handler.

It's entirely feasible to do rather more within the handler than to just convert the signal into a return status (sig_to_ret), including (often) gathering (far) more information on the error.

nb: the conversion to the return occurs when the signal arrives at the call frame depth (level) of the code that has declared the handler, which would be at the "wrapper" call here.

Reading materials:

http://labs.hoffmanlabs.com/node/1438

http://labs.hoffmanlabs.com/node/1260

I wrote various updates to the HP Programming Concepts Manual over the years around these sorts of things, and that's probably also worth a read here if you've not taken the time. That document tries to describe some of these areas of OpenVMS in some detail.

Re: Turning off TCPIP stack dumping

Dan Herron — Thu, 21 Jan 2010 19:51:03 GMT

Volker,
Thank you very much for your quick responses to my question.

Hoff,
Thank you for your responses also.

Both your responses lead me (in a round about way) to the
OPTION HANDLE=ERROR command in BASIC (our language of choice) which allows the BASIC program to trap externally generated errors (via TCPIP, etc.) during the execution of the program.

Thanks again,
Dan Herron

Re: Turning off TCPIP stack dumping

Dan Herron — Thu, 21 Jan 2010 19:52:44 GMT

See my final reply

Re: Turning off TCPIP stack dumping

John Gillings — Thu, 21 Jan 2010 22:39:18 GMT

Dan,

A generic solution for any routine, in any language, which signals errors. Use a MACRO32 jacket around the routine:

.TITLE SIG_TO_RET_JACKETS
.ENTRY mail_send_add_address,^M<>
MOVAB G^LIB$SIG_TO_RET,(FP)
CALLG (AP),G^MAIL$SEND_ADD_ADDRESS
RET
.END

on Alpha and Itanium, your entry point should look like:

.CALL_ENTRY LABEL=mail_send_add_address, HOME_ARGS=TRUE, MAX_ARGS=

For the jacket routine name, I tend to change the "$" in the facility name to "_".

Your application calls the jacket. Any signalled conditions will be converted to a return status from the jacket.