TCPIP Error - OpenVMS Itanium

[openvms_automat]

Hello,

We're calling some of the MAIL$ routines in C to send emails from VMS. One of our services keeps crashing with the following:

%TCPIP-E-SMTP_CFERROR, control file error in create_cf
%TRACE-E-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
TCPIP$SMTP_MAILSHR 0 0000000000163600 00000000069B5600
TCPIP$SMTP_MAILSHR 0 0000000000168432 00000000069BA432
MAILSHR 0 00000000000551E2 000000007B3E51E2
MAILSHR 0 0000000000055892 000000007B3E5892
MAILSHR 0 00000000000472E2 000000007B3D72E2
MAILSHR 0 0000000000047792 000000007B3D7792
MAILSHR 0 00000000000488D2 000000007B3D88D2
LIBRTL LIB$TABLE_PARSE LIB$TABLE_PARSE
1455 0000000000001B92 FFFFFFFF84209D92
MAILSHR 0 0000000000045B92 000000007B3D5B92
MAILSHR 0 00000000000466D2 000000007B3D66D2
MAILSHR 0 0000000000046C12 000000007B3D6C12
MAILSHR 0 000000000003E6C2 000000007B3CE6C2
MAILSHR 0 000000000003EF12 000000007B3CEF12

...

...

%TRACE-I-END, end of TRACE stack dump
%LIB-F-BADBLOADR, bad block address
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
TCPIP$SMTP_MAILSHR 0 0000000000163650 00000000069B5650
TCPIP$SMTP_MAILSHR 0 0000000000168432 00000000069BA432
MAILSHR 0 00000000000551E2 000000007B3E51E2
MAILSHR 0 0000000000055892 000000007B3E5892
MAILSHR 0 00000000000472E2 000000007B3D72E2
MAILSHR 0 0000000000047792 000000007B3D7792
MAILSHR 0 00000000000488D2 000000007B3D88D2
LIBRTL LIB$TABLE_PARSE LIB$TABLE_PARSE
1455 0000000000001B92 FFFFFFFF84209D92
MAILSHR 0 0000000000045B92 000000007B3D5B92
MAILSHR 0 00000000000466D2 000000007B3D66D2
MAILSHR 0 0000000000046C12 000000007B3D6C12
MAILSHR 0 000000000003E6C2 000000007B3CE6C2
MAILSHR 0 000000000003EF12 000000007B3CEF12

Really at a loss for what's happening. Network guys said all of stuff is up-to-date. None of the code that is being referenced has changed in some time.

Would it be possible that something has a memory leak and/or is messing with the stack? If that's the case, we have multiple services running in the same .EXE. It's seems strange that this is the only one that would crash it.

Thanks

Any help is much appreciated.

[abrsvc]

From help/mess:

The temporary mail file is created in the user's mail profile

directory. Check that this directory exists. Otherwise,

contact your HP support representative and describe the

conditions leading to the error.

Bolded by me.

Hope this helps a bit.

Dan

[Hein van den Heuvel]

>>  That %LIB-F-BADBLOADR, bad block address is probably a secondary failure.

Ignore untill the first one is addressed.

>>  If that's the case, we have multiple services running in the same .EXE. It's seems strange that this is the only one that would crash it.

Seems to me you need to know what that service might be doign differently. Username? Target? With/without file.

Have you tried to emulate the expected/anticipated failing Email command directly with VMSmail?

I do NOT expect there to be a (serious) bug in your service code considering it worked before, and is workign mosty of the time. It is just a way to focus on the real issue and if it reproduced with VMS mail, then it completely eliminate the C code as suspect. It will also help explain to us what command can be use to emulate..

$ MAIL /SUB=xxx <file?> "SMTP%aaa@bbb.ccc" ?

Finally try running with SET WATCH FILE/CLA=MAJOR

You will see many files created/accessed.

One of those may indicated a failure.

For grins... on EISNER  using OpenVMS Alpha 8.3 and the Multinet Stack I see (editted down):

%XQP, Thread #0, Access PMDFSHR.EXE;298 (20864,719,0) Status: 00000001
%XQP, Thread #0, Access CONFIG_DATA.EXE;20 (70289,142,0) Status: 00000001
%XQP, Thread #0, Access CHARSET_DATA.EXE;219 (23859,6,0) Status: 00000001
%XQP, Thread #0, Lookup PMDF.DIR;1 (6583,3,0) Status: 00000001
%XQP, Thread #0, Lookup TABLE.DIR;1 (9691,1,0) Status: 00000001
%XQP, Thread #0, Lookup SYS$ZONEINFO.DIR;1 (544,1,0) Status: 00000001
%XQP, Thread #0, Lookup SYSTEM.DIR;1 (545,1,0) Status: 00000001
%XQP, Thread #0, Lookup US.DIR;1 (671,1,0) Status: 00000001
%XQP, Thread #0, Access CENTRAL.;1 (37336,224,0) Status: 00000001
%XQP, Thread #0, Lookup TCP_LOCAL.DIR;1 (19065,5,0) Status: 00000001
%XQP, Thread #0, Create/Access ZZ01OP8VX2198K00UQHX.00;1 (71775,593,0) Status: 00000001
%XQP, Thread #0, Lookup QUEUE_CACHE.DAT;1 (46314,479,0) Status: 00000001
%XQP, Thread #0, Create-if Access QUEUE_CACHE.DAT;1 (46314,479,0) Status: 00000001
%XQP, Thread #0, Lookup COM.DIR;1 (9758,1,0) Status: 00000001
%XQP, Thread #0, Access MASTER.COM;435 (19883,424,0) Status: 00000001

What platform? OS version? Patches? TCPIP stack ? TCPIP stack version?

Cheers,

Hein.

[Richard Brodie_1]

If it's happening out of the blue, rather than after a patch, I would guess some sort of resource problem. Disk quota on the sending account, out of space on the disk, version limit reached.

Following on from Dan, where is the file being created, and is there a reason why it can't be now? Using SET WATCH might give you a helpful status, as Hein said.

[openvms_automat]

OpenVMS V8.3-1H1.

I doesn't happen everytime the routine is called that's why it points to a memory leak. Do the MAIL$ routines use a large chunk of memory?

Emailed our sys admin guys about the directory, but they haven't got back to me yet.

From what the network guys told me the TCPIP patchest are latest. We're running TCPIP V5.6 eco 5

[openvms_automat]

Also, can't seem to recreate manually. 

[abrsvc]

What is the environment that this process runs in?  Batch job?  Detached process?  The error message provides a clue, but little detail.  I'd be looking for outside influences here.  If it is a detached process, is it a subprocess where others may be consuming shareable resources and sometimes using too much?  You need to look for the basics here.  Verify "login" information for privs, protections, UIC variations etc.  Something has to be different to cause this.

Look for patterns such as the time when this happens.  If the problem shows up at 1PM each time (not necessarily every day), then look to see what happens at that time.  Maybe a standard program/system is processing an overly large amount of data on the day in question such that the resource requirements are larger than normal.  This could leave fewer resources for this mail process for example.

Dan