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/1438http://labs.hoffmanlabs.com/node/1260I 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.
