RE: SMTPR4 and SIGALRM -- MIDRANGE-L

You are correct about the book being a good doorstop. While I don't
regret having created my own protocol and writing a low level sockets
program, it's not something I ever want to do again.

SMTP_new calls init_signals() on the second line of it's code.
Init_signals calls sigaction whichs sets a handler for SIGALRM and
points it to the address of the routine caught_alarm. All caught_alarm
does is set a flag and return. That means that when the alarm is
signaled, it should set that flag, and then return execution to the next
line after the send which timed out. This is my interpretation of what
should be happening. Can you put it in debug and see what is really
happening?

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;

len gets set to the length of the text you want to send.
alarm sets the alarm to the timeout which defaults to 60 seconds.
The send is called and times out. The sigalrm handler should be called,
and set the value of ALARMED to *ON and return to the next line.
alarm(0) cancels the alarm. If the send was successful that would have
made sure that it doesn't go off later. In your case it doesn't really
do anything.
The if checks to see if what was sent was less than what you had to
send. In your case that should be true, so it sets up the unix error
reporting and returns *OFF.
That *OFF should percolate up your function calls until it gets back to
the SMTP_data_stmf call, and the check against FAIL should be true.

Submitting the job would fix your problem I think, but it would be nice
to understand what exactly is going wrong. I can't think of a way for me
to test it. The only thing I still use this library for is some job and
error monitoring that I do, and have the programs text me if there are
issues. I'm not sure how I could make something work for the other calls
but fail in the send().

Only last thought. Have you locked down the signal programs? I doubt it,
but what does DSPOBJAUT OBJ(QP0SSRV1) OBJTYPE(*SRVPGM) show? Should be
PUBLIC *USE

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: Monday, August 20, 2018 6:32 PM
To: Midrange Systems Technical Discussion
Subject: RE: SMTPR4 and SIGALRM

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

awesome doorstop :-) )

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

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

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

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