Re: Time limit reached for SIGTERM signal handler.

nope. I'm not monitoring that particular call.


"Monnier, Gary" <Gary.Monnier@xxxxxxxxx> wrote in message
news:mailman.36009.1301084809.2702.rpg400-l@xxxxxxxxxxxx...
I admit I haven't followed this thread but I have to ask...

Is the call to PROCESSTHI monitored for a call error? In other words
are you using a CALLP(E) or MONITOR group to trap for errors?


Gary

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of hockchai Lim
Sent: Friday, March 25, 2011 12:57 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Time limit reached for SIGTERM signal handler.

I'm not using signals in this particular program. All I know is that
this
program has been running on our QA box for over 2 months now. It gets
ended
with ENDSBS OPTION(*IMMED) every night. Never have problem until last
night. (Note: I got that same error in QSYSOPR when I manually end it
this
morning also. But the job ended without me having to reply to that
message).

Here is the only thing that is different about last night and this
morning.
Our QA has purposely setup a invalid sever (non-existent sever). My
process
is designed to send email to notify someone when connection problem
occur
(Every so often). But the process will continue to attempt to process
the
transaction (Every so often). So, I'm thinking, because the sever does
not
exist, when the RPG calls the java's connect method, it takes up
unusually
long time before it returns control back to RPG, which may have caused
the
cancel handler to get timeout. Cancel handler gets timeout is actually
not
a big deal. But I just do not understand why the system sending that
inquiry message. The job has already ended, what is the point of
sending
that INQ message? Everytime our operator sees a INQ/Escape message, he
calls the on-call programmer, so, we got some unhappy on-call programmer
syndromes the next day :)




"Scott Klement" <rpg400-l@xxxxxxxxxxxxxxxx> wrote in message
news:mailman.35996.1301080792.2702.rpg400-l@xxxxxxxxxxxx...

This kinda sounds like you're using signals (SIGTERM is a signal) via

the

signal() or sigaction() API. When the job is ended, the signal

handler

fires, et al, but isn't doing it's job quickly enough (or, perhaps,

it's

getting stuck in a loop?)

So the OS says "you've had enough time, now I'm going to end the

program."

I don't know if CEERTX might use signals under the covers? But maybe

it

does, and that's resulting in the same issue?

But, I'd check to see if your handler isn't responding quickly enough,

or

is maybe getting stuck in a loop or something like that.


On 3/25/2011 10:30 AM, hockchai Lim wrote:

hello all,
I've just created a brand new RPG program that will call the CEERTX

to

register the Cancel handler at runtime. The main function of this

new

RPG
program is to update/add record to a table in a mysql database (using
JDBCR4
by Scott, of course).

Everything has been working fine. When the job is being ended
(option(*IMMED)), the cancel handler is being called to do the

cleanup

task.
But, last night, something strange happened. When the job was being
ended
last night (option(*IMMED)), the job did get ended. But in the

Operator

Message Queue, I'm getting error below:

Message ID . . . . . . : RNQ0202 Severity . . . . . . . :

99

Message type . . . . . : Inquiry
Date sent . . . . . . : 03/25/11 Time sent . . . . . . :
08:42:44

Message . . . . : The call to PROCESSTHI ended in error (C G D F).


When reviewing the log, I also see this:
CPC1166 Completion 50 03/25/11 08:44:30.105304
QWTMETMR
QSYS 019E *EXT
From user . . . . . . . . . :
QSYS
Message . . . . : Time limit
reached
for SIGTERM signal handler.
Cause . . . . . : Job
009075/PALHC/BLWGINTCMP did not complete during the
time allowed. An immediate

end

job
request was issued by the system. The
time limit was 120 seconds.
Recovery
. . . : If the time limit of 120
seconds is not enough time

for

the
SIGTERM signal handler to complete,
contact your system

administrator

to
increase the time allowed by the
QENDJOBLMT and QPWRDWNLMT

system

values.

The reason I'm getting the RNQ0202 appears to be cause by this

CPC1166

error.


I've done cancel handler on several production programs before and

has

never
enconuter this. Any idea why?

thanks