RE: Time limit reached for SIGTERM signal handler.

So monitoring that particular call and handling the error would
eliminate "some unhappy on-call programmer

syndromes the next day" yes?



Just having a routine that generates a job log and does a program dump
could go a long way. The routine could also determine if a programmer
needs to be involved during after-hours.



Gary



-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of hockchai Lim
Sent: Friday, March 25, 2011 3:20 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: 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 :)