topic Re: Promis Application Problem in Operating System - OpenVMS

Promis Application Problem

SANJAY MUNDHRA — Thu, 04 Oct 2007 22:25:04 GMT

Hi All,

There was Promis aplication problem in one of teh sites here, the application failed with the following bug check. This looks like more of Promis mail messaging issue. Does nayone have any idea where to look into.

%CFC-W-TRACEBACK, follows
%TRACE-W-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
TPSERVER TPS_PROCESSCOMMAND_HANDLER TPS_PROCESSCOMMAND_HANDLER
5905 0000000000000094 00000000003C7C84
DEC$FORRTL 0 0000000000081908 000000007C787908
----- above condition handler called with exception 007E802A:
%MAIL-E-NOSUCHUSR, no such user
----- end of exception message
0 FFFFFFFF800A209C FFFFFFFF800A209C
MAILSHR 0 0000000000053004 000000007B767004
MAILSHR 0 000000000003D83C 000000007B75183C
MAILSHR 0 00000000000359B8 000000007B7499B8
MAILSHR 0 0000000000036B08 000000007B74AB08
TPSERVER LOG_HOSTMAIL LOG_HOSTMAIL 1947 000000000000018C 00000000006D018C
TPSERVER LOG_SENDMSGL_NOTALKACTION LOG_SENDMSGL_NOTALKACTION
5441 00000000000014E4 00000000004BF384
TPSERVER LOG_SENDMSGL_NOTALK LOG_SENDMSGL_NOTALK
2336 0000000000000154 00000000004BDE44
TPSERVER 0 00000000003940C8 00000000003940C8
TPSERVER TST_MSGUTIL_SENDONEMESSAGE TST_MSGUTIL_SENDONEMESSAGE
22044 0000000000000908 0000000000830048
TPSERVER TST_MSGUTIL_WARNINGS TST_MSGUTIL_WARNINGS
13806 00000000000014FC 0000000000624A0C
TPSERVER TSTUTIL_LOTUTIL_DOUPDATES TSTUTIL_LOTUTIL_DOUPDATES
33297 0000000000000144 0000000000609AF4
TPSERVER TSTUTIL_LOTUTIL_FINALLY TSTUTIL_LOTUTIL_FINALLY
19917 000000000000012C 000000000060A29C
TPSERVER TSTENTER_GENDATA_EXECUTE TSTENTER_GENDATA_EXECUTE
23241 00000000000000B8 0000000000603518
TPSERVER TSTENTER_GENDATA_MAIN TSTENTER_GENDATA_MAIN
15768 0000000000000388 0000000000461118
TPSERVER SIG_CALLWITH_NFUNCNN SIG_CALLWITH_NFUNCNN
2147 000000000000005C 00000000003A9EFC
TPSERVER CUE_CALLWITH_HANDLER CUE_CALLWITH_HANDLER
38 0000000000000058 00000000003D4A58
TPSERVER TSTENTER_GENDATA TSTENTER_GENDATA
6276 0000000000000044 00000000003C90A4
TPSERVER TPSTSTENTER_GENDATA_MAIN TPSTSTENTER_GENDATA_MAIN
15636 0000000000000144 00000000003BFEC4
TPSERVER SIG_CALLWITH_NFUNCNN SIG_CALLWITH_NFUNCNN
2147 000000000000005C 00000000003A9EFC
TPSERVER TPS_PROCESSCOMMAND TPS_PROCESSCOMMAND
3417 0000000000000698 0000000000398B28
TPSERVER RV6SERVER commandCallback 11288 0000000000000CCC 000000000039614C
LIBTIBRVCMQSHR CMQ_WORK _tibrvcmqWorker_CertifiedDeliveryCB
21994 0000000000000244 0000000005D8AE84
LIBTIBRVSHR DISP _tibrvQueue_Dispatch
24885 0000000000000554 0000000005CB2554
LIBTIBRVSHR DISP tibrvQueue_TimedDispatch
24930 0000000000000710 0000000005CB2710
TPSERVER RV6SERVER TpsRv6_Rv6Server 11494 0000000000001618 0000000000396A98
TPSERVER TPSRV6_CALLSERVERWITHARGS TPSRV6_CALLSERVERWITHARGS
370 000000000000047C 00000000003952BC
TPSERVER TPS_TPSERVER TPS_TPSERVER 263 0000000000000094 0000000000394E14
PTHREAD$RTL 0 0000000000055FF8 000000007BD2FFF8
PTHREAD$RTL 0 0000000000030404 000000007BD0A404
0 FFFFFFFF8026FED4 FFFFFFFF8026FED4
%TTC - application error, status - ' 7E802A'x
Error text - "%MAIL-E-NOSUCHUSR, no such user !AS"
*F- ---- 4-OCT-2007 16:46:20.22----Command that caused TP failure
*F-Command: "TSTENTER_GENDATA " 1113 bytes
*F-"USERID CIM_AUTO"
*F-"PWD xxxxxxxx"
*F-"operId MESDUV2.04"
*F-"location ALITHO"
*F-"eqpId ALD756"
*F-"data 9"
*F-"22.0308576650915"
*F-"21.8657937477045"
*F-"22.1644868009335"
*F-"21.67"
*T- ---- 4-OCT-2007 16:46:20.22----Reply: "TTCFAILURE "
*I- Reply: "TTCFAILURE " 61 bytes
*I-"%TTC-F-APPSIGNAL, Internal error in PROMIS application code"
*F- Restarting due to fatal error in application code.
*L- FAST security mode: Logging out of PROMIS.
*L- Defining logical DCLSTATUS to: %X08478021
Server image exited with status=%X08478021 at 4-OCT-2007 16:46:20.30
Fatal application error: restarting server image. 4-OCT-2007 16:46:20.30
Renaming current process to TEMP_205B42DD
Starting new server process.
Starting TP/RV6 server RV6_TPSER_6 at 4-OCT-2007 16:46:20.33
%RUN-S-PROC_ID, identification of created process is 205D8C58
Exiting current server process.
PROMS1 job terminated at 4-OCT-2007 16:46:20.43

Thanks in advance.

Re: Promis Application Problem

John Gillings — Fri, 05 Oct 2007 00:50:57 GMT

Sanjay,

Wow, that's a rather extreme response to a simple "NOSUCHUSER" condition. I would have expected an application to log a message saying it couldn't send mail (including the username) and then carry on.

First step is to read the Promis documentation or log a case with the Promis support folk. This is most likely an FAQ.

Failing that, I'd be looking for a configuration file or logical name which defines a username to which mail messages might be sent. If it's a hardcoded name, and you don't want to create another username, you can create a forward entry with:

MAIL> SET FORWARD/USER=target newtarget

For example, suppose Promis is hardcoded to send mail to an account PROMIS_ALERT you could redirect them with:

MAIL> SET FORWARD/USER=PROMIS_ALERT SYSTEM

The source username does not need to exist, but the destination does.

If you get really stuck, look up my FAKE_RTL tool in the OpenVMS Technical Journal. You could use it to build a fake MAILSHR which could help you determine what username Promis is trying to send to, and/or force the return status to success.

Re: Promis Application Problem

SANJAY MUNDHRA — Fri, 05 Oct 2007 02:50:17 GMT

Hi John,

Thanks for the response. The users assuch are not VMS users and are in the Oracle table, the customer verified that the users exist. C case has been logged with BROOKS (for Promis), will be having a concall today. His initial findings is as under:

This seems to be happening because of the addresses that are being fed into
your Log_Mail system. For example, in your traceback PROMIS signal handler
is trying to cleanup the e-mail resources used to try and send a message to
the nonexistent user. This is where the TP server runs out of e-mail
resources after handling, I believe, 50 nonexistent user messages and then
all messages, to good or bad addresses, are rejected because of the
resource exhaustion. PROMIS is doing this in the signal handler because
there are dozens of places where MAIL$ calls could cause a problem and it
is safer to put it here.

The system used everywhere else is to give each e-mail address used in
PROMIS a VMS account with attached VMS mailbox. If you want to forward the
mail to some other system, you set that VMS mailbox to forward it to some
other address; you don't go to another machine right away.

The SMTP handler is run on the system running PROMIS. Each node on a
cluster should have its own SMTP server. And each server sends the mail to
some mail gateway. Also, just make sure NOT to use node names in your
e-mail addresses, of possible.

Here is the important scenario for your environment that I am recommending
to test:

I do a login with my user "mpinharry". So I am logged in with "mpinharry"
as well as in VMS and PROMIS. Then I change the user within PROMIS from
"mpinharry" to an other account named "1908". So under VMS it is still
"mpinharry" and in PROMIS now it is "1908". With this constellation (PROMIS
user "1908" with "mpinharry" as VMS user below) I try to send an email to
"mpinharry". Is it possible to recreate this scenario in your environment
to see if mail traceback appears? Please use your test system, of course.

There is a possibility that in this case mail forwarding is done via an
other VMS-Host using DEC-Mail instead of SMTP. The reason is DEC-Mail does
not write any temporary files as it sends the mail directly and immediately
to the forwarding address. Mail forwarding of the mail recipient should be
always set as SMTP.

Re: Promis Application Problem

Hein van den Heuvel — Fri, 05 Oct 2007 07:22:20 GMT

That looks like a fine response.
Cancel the conference call and do what the man says!

fwiw,
Hein.

Re: Promis Application Problem

Ronald Y. Salem — Fri, 05 Oct 2007 07:58:22 GMT

Sanjay,
Can you check whether CIM_AUTO userid exists both PROMIS AUTH and VMS UAF database?

Thanks.

Re: Promis Application Problem

SANJAY MUNDHRA — Fri, 05 Oct 2007 22:44:26 GMT

CIM_AUTO is a PROCIM database user and not available in VMS. Had a concall with BROOKs, they will be trying to replicate the problem. Will keep u all posted.