Re: Time limit reached for SIGTERM signal handler.

Yes, that is how I understand what condition handler should be use for. The
PROCESSTHI is actually processThis() procedure. It is not being call by the
condition handler.

Here is the code in the main procedure (Notice ProcessThis() is in the do
loop)
* include JDBC header
/copy qrpglesrc,jdbc_h
*****************************************************************
* main
*****************************************************************
/free
dow readNextBLWGINTSL0(WGINTS) = @SUCCESSFUL;
processThis(WGINTS);
enddo;
wrapup();
*inlr = *on;


Here is the condition handler exit procedure code:
*********************************************************************
* Cancel handler
*********************************************************************
P cncHandler B
D pi
D pCncMsg *
/free
wrapup();
/end-free
P cncHandler E



Here is the wrapup() procedure (Notice I've monitor on this whole proc):
*********************************************************************
* wrap up
*********************************************************************
P wrapup B
D pi
/free
monitor;
for ix = 1 to %elem(connList);
dropGroupServerConnectionAndAssociatedPS(ix);
endfor;
on-error;
endmon;
/end-free
P wrapup E


So, I'm puzzled by the inquiry message being sent to QSYSOPR.


"CRPence" <CRPbottle@xxxxxxxxx> wrote in message
news:mailman.35977.1301075237.2702.rpg400-l@xxxxxxxxxxxx...

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