Re: SMTPR4 and SIGALRM -- MIDRANGE-L

Don,

My message essentially said 3 things:

1) SMTPR4 tries to tell the OS not to end the job by calling sigaction() in the init_signals() procedure.

2) It seems that something else is overriding this behavior so #1 isn't working.

3) It could be fixed (the "right" way) by rewriting SMTPR4 to avoid the use of signals.

Does that clear up confusion?

-SK

On 8/24/2018 3:09 AM, Don Brown wrote:

Thank you for the reply Scott.

As you can see in joblog in the post trail the SIGALRM is definitely
killing the job.

Also this is very strange that the process successfully connects with the
server but then times out on the send()

I was following everything you were saying until you got to the "right" fix
and unfortunately you have lost me totally there :-)

Based on your suggestion of how this is happening is there any logging that
can check if the signalling did call caught_alarm or if something external
overrode it ?

So if I am understanding correctly the init_signals is providing the
address of caught_alarm but in my situation caught_alarm is NOT being
called and subsequently the job is being cancelled - is that correct ?

as this is happening so infrequently I wanted wrap some additional code
around where the timeout is happening to try and identify the reason but it
is sounding like this may not help in identifying the reason ?

Appreciate your reply.

Thank you

Don Brown

From: "Scott Klement" <midrange-l@xxxxxxxxxxxxxxxx>
To: "Midrange Systems Technical Discussion"
<midrange-l@xxxxxxxxxxxx>
Date: 23/08/2018 02:47 AM
Subject: Re: SMTPR4 and SIGALRM
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>

Hi Don,

SIGALRM shouldn't cancel the job. There's a procedure within SMTPR4
called 'init_signals' that uses the sigaction() API to tell the
operating system that the SIGALRM should call the caught_alarm
subprocedure. (It's possible for sigaction() to tell it to end the job,
but that's not what it does.)

When SendText() writes data, it tells the OS to send an alarm at the
given timeout interval. That will interrupt the send() API... but if
send() completes beforehand, it disables the alarm. The result should
be that the call is only interrupted if its unable to complete in the
timeout interval. (Usually due to network lag.)

If that happens, it will call SetUnixError() and return off, and the
calling routine can check for the error.

Having said that... I've found that there are circumstances where (not
exactly sure how this works) code outside of SMTPR4 (and other tools
which I've written that worked similarly) can override the signal
behavior. I'm guessing that's what's happening, here... for some
reason external code has overridden the behavior of SIGALRM so that it
ends the job...

The "right" fix, would be to change the code to use non-blocking sockets
and the select() API for timeouts, eliminating the use of signals.

-SK

On 8/20/2018 6:31 PM, Don Brown wrote:

Kevin you are correct the code snippet is from the sendtext function. (I
think I need something like your Stevens book - when not in use would

make

an awesome doorstop :-) )

We use a file that gets updated with the relevant information for the

email

that includes;
From, To, Subject, Text, Attachments

Then we call a procedure that builds and sends the email using the
procedures in SMTPR4.

So we have the following summary call stack;

Payment_processor ==> Email_Sender ==> SMTPR4

The SIGALRM is cancelling the entire job - Is that what you would

expect ?

And because the alarm process is external I have no way to monitor for

this

- is that correct ?

Interestingly the failure only occurs on the send - let me explain
further ...

first we build a stream file in the ifs with the contents of the email
including attachments.

Then we call the individual procedures to process sending the message.

hsmtp = SMTP_new( %trim( pServer )); <=== This succeeds

if ( SMTP_from( hsmtp: %trim( sender )) = FAIL ); <==== This succeeds

if ( SMTP_recip(hsmtp: %trim( receiver( x ))) = FAIL ); <=== This

succeeds

for all recipients

if ( SMTP_data_stmf( hsmtp : %trim( emailFile )) = FAIL );

The check to ensure the stream file exists succeeds.

Then the call to send(SMTP.sock: %addr(buf): len: 0); <=== This
times out and after 60 seconds the SIGALRM cancels the job.

The job log shows ...

CPC1224 Completion 50 16/08/18 09:31:00.735554

QWTPITP2

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

signal

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

job.

The only option I can see is to change the call to the Email_Sender to be

a

submit job thereby separating the main processing and email sending into
completely separate jobs - Would you agree or can you suggest any
alternative ?

Appreciate your feedback.

Don Brown

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

The send will sit there forever. That is why you have to have the
timeout and the alarm. The alarm should only be killing the send.
Nothing else. The code that you are showing looks to me to be inside the
sendtext function in smtpr4. At least in my case, that gets called one
of two ways. Either all wrapped up in SMTPSend mail, or as individual
calls to the various pieces of an SMTP transaction. If you are calling
sendtext() directly, then it is up to you to deal with getting the
errors and handling them.

Either
hsmtp = SMTP_new('mail.i-55.com');

if ( SMTP_connect(hsmtp) = FAIL );
ErrMsg = SMTP_error();
// Error handling goes here.
endif;

if ( SMTP_from(hsmtp: 'blah.blah@xxxxxxxxx') = FAIL );
ErrMsg = SMTP_error();
// Error handling goes here.
endif;

Or
SMTPSendMail( FileName
: %len(FileName)
: fromAddr
: %len(fromAddr)
: recip
: %elem(recip)
: NullError );
// Check nullerror for errors.

The unix api documentation on the IBM site is very barebones, but to be
fair, I have the Stevens book on unix network programming and it is over
1000 pages and that is only volume 1. Scott's wrapper hides all of that
complexity from you, so that you should just have to make the calls to
his high level routines and check for errors that he returns.

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: 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

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
__________________________________________________________
____________

--
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
______________________________________________________________________

--
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
______________________________________________________________________