RE: SMTPR4 and SIGALRM

Kevin you will notice in the code snippet I sent that the time out is being
received on the

slen = send(SMTP.sock: %addr(buf): len: 0);

So the problem I have is not checking the error data structures, the
problem is that the alarm time out has been set and the send times out and
the SIGAMRM is sent that kills the job.

Will the send(...) wait indefinitely ? and that is why the alarm is used to
kill the job if that occurs ?

If I increase the time out will the send(...) eventually fail so i can
check the error data structure ?

The documentation in the knowledge centre is not, in my opinion, very easy
to understand.

Thanks you for your reply.


Don Brown






From: "Kevin Bucknum" <Kevin@xxxxxxxxxxxxxxxxxxx>
To: "Midrange Systems Technical Discussion"
<midrange-l@xxxxxxxxxxxx>
Date: 17/08/2018 10:13 PM
Subject: RE: SMTPR4 and SIGALRM
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>



I has been a while since I played with that, but I don't think you can
avoid having that job canceled. What does the send look like? Are you
doing the individual calls, or using one of the wrappers that does all
the calls for you? Both ways have error reporting. SMTPSendMail or
SMTP_Sendmail both have an error data structure that you need to check.
If you are doing individual calls like SMTP_connect, SMTP_from, etc, you
need to check the return from SMTP_error.

Kevin Bucknum
Senior Programmer Analyst
MEDDATA/MEDTRON
Tel: 985-893-2550

-----Original Message-----

From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf
Of Don Brown
Sent: Thursday, August 16, 2018 11:11 PM
To: Midrange Systems Technical Discussion (midrange-l@xxxxxxxxxxxx)
Subject: SMTPR4 and SIGALRM



We are using SK's SMTPR4 to send emails.

We have a payment process that charges credit cards via an external
payment gateway and sends an email with the transaction result.

The problem we have is occasionally the job will be cancelled with

CPC1224 as

per following ...

CPC1224 Completion 50 06/08/18 08:17:38.219994

QWTPITP2

QSYS 0645 *EXT *N
Thread . . . . : 00000001
Message . . . . : Job ended
abnormally.
Cause . . . . . : A SIGALRM

signal

was received for the job. The action for
the signal was to terminate the

job.

I have tracked this back to the SMTPR4 service program that does the
following;

/free
DebugMsg(text);
len = e2a(SMTP: text: buf: %size(buf));
alarm(SMTP.timeout);
slen = send(SMTP.sock: %addr(buf): len: 0);
alarm(0);
if (slen < len);
SetUnixError( SMTP_ERR_SEND: 'send()' );
return *OFF;
endif;
return *ON;
/end-free

So my understanding is the alarm(...) is setting the timeout to 60

seconds.

The send(...) must be failing causing a delay of 60 seconds or more

which

causes the alarm to be signaled/processed. I presume the signalling

was

used as the send(...) would wait indefinitely ?

The the job is then cancelled which leaves the payment process

incomplete.

I have not been able to identify why the email server is not

responding and

while increasing the timeout could be done I don't think that is the

best

option.

As the SIGALRM is external to the job how can I detect failure of the

email to

send but not have the entire job cancelled ?

Appreciate any assistance or suggestions.

Would also appreciate any links to signalling for dummies or similar

so I can

bet a better understanding of what and how they work.

Thanks

Don Brown


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take
a moment to review the archives at
https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________