Re: Time limit reached for SIGTERM signal handler.

On 3/25/11 8:30 AM, hockchai Lim wrote:

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).

Cause . . . . . : RPG procedure &1 in program &3/&2 at statement &4 called program or procedure &6, which ended in error. If the name is *N, the call was a bound call by procedure pointer.
Recovery . . . : Check the job log for more information on the cause of the error and contact the person responsible for program maintenance.

When reviewing the log, I also see this:

CPC1166 Comp 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.

Since the msgRNQ0202 inquiry transpires about 106 seconds before the msgCPC1166, I would expect the latter is a side effect of the former rather than the supposed reverse.?

I've done cancel handler on several production programs before and has never
encounter this. Any idea why?

What was registered as the handler, and is the PROCESSTHI called by the handler or perhaps actually the handler itself?

FWiW the actual joblog versus specifically pared\chosen data is usually best to allow the reader to better understand the flow; e.g. what sent the inquiry. I expect for example that the errors referred to by the RNQ0202 are the origin for the issue in this specific scenario, and that the code might need to change to prevent the inquiry more generally.

In my experience in programming handlers, they were written to only perform cleanup and complete within a few seconds if not more likely subsecond, and would always monitor for all errors to prevent any delay including avoiding any default handler that might effect an inquiry waiting on reply. The exit is allowed to process even under "immediate" end, but only for the timeout allowed by the system as described in the CPC1166. So if that handler is "running" in a manner that is just "hanging" awaiting a reply to an inquiry, that exit will time-out and the job will be forcibly ended irrespective of the handler not completing within that time-limit.

Regards, Chuck