× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.





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












As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.