RE: Time limit reached for SIGTERM signal handler.

["Monnier, Gary" <Gary.Monnier@xxxxxxxxx>]

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