× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.





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



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.