|
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalfbeing
Of Don Brown
Sent: Sunday, August 19, 2018 5:25 PM
To: Midrange Systems Technical Discussion
Subject: RE: SMTPR4 and SIGALRM
Kevin you will notice in the code snippet I sent that the time out is
received on theproblem
slen = send(SMTP.sock: %addr(buf): len: 0);
So the problem I have is not checking the error data structures, the
is that the alarm time out has been set and the send times out and theused to kill
SIGAMRM is sent that kills the job.
Will the send(...) wait indefinitely ? and that is why the alarm is
the job if that occurs ?check the
If I increase the time out will the send(...) eventually fail so i can
error data structure ?easy
The documentation in the knowledge centre is not, in my opinion, very
to understand.avoid
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
having that job canceled. What does the send look like? Are you doingthe
individual calls, or using one of the wrappers that does all the callsfor you?
Both ways have error reporting. SMTPSendMail or SMTP_Sendmail bothyou
have an error data structure that you need to check.
If you are doing individual calls like SMTP_connect, SMTP_from, etc,
need to check the return from SMTP_error.the
Kevin Bucknum
Senior Programmer Analyst
MEDDATA/MEDTRON
Tel: 985-893-2550
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] OnBehalf Of
Don BrownCPC1224 as
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
per following ...QWTPITP2
CPC1224 Completion 50 06/08/18 08:17:38.219994
QSYS 0645 *EXT *Nsignal
Thread . . . . : 00000001
Message . . . . : Job ended
abnormally.
Cause . . . . . : A SIGALRM
was received for the job. The action for
the signal was to terminate
job.the
seconds.
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
which
The send(...) must be failing causing a delay of 60 seconds or more
causes the alarm to be signaled/processed. I presume the signallingwas
used as the send(...) would wait indefinitely ?incomplete.
The the job is then cancelled which leaves the payment process
responding and
I have not been able to identify why the email server is not
while increasing the timeout could be done I don't think that is thebest
option.
As the SIGALRM is external to the job how can I detect failure of
email tomailing
send but not have the entire job cancelled ?so I can
Appreciate any assistance or suggestions.
Would also appreciate any links to signalling for dummies or similar
bet a better understanding of what and how they work.
Thanks
Don Brown
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)
listaffiliate
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,take
unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please
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
listlink: http://amzn.to/2dEadiD--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,service.
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
For more information please visit http://www.symanteccloud.comlist
__________________________________________________________
____________
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
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
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.