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