Re: Best Way to Kill Runaway Interactive Jobs?

Sounds like you need to fix the application problem to me.  If you already
know that this problem exists, why haven't you already fixed it?  I would
spend my time fixing programs like this one rather than spending time trying
to build a program that tries to monitor for these runaway jobs and ending
them.

Better yet, If this programmer is still in your employ, have _him/her_ fix
the offending programs, then string them up from the nearest pole with some
of you old twinax...

JMHO

Steve Landess


----- Original Message -----
From: "Ross Hartford" <ross.hartford@ccslink.com>
To: "Midrange Systems Technical Discussion" <midrange-l@midrange.com>
Sent: Wednesday, January 22, 2003 2:18 PM
Subject: RE: Best Way to Kill Runaway Interactive Jobs?


> We had that happen when a user closes their terminal session and the
> interactive program continuously tries to write to the screen.  Since the
> screen is not there anymore, the write fails, the error indicator comes
on.
> In this program, the programmer has studiously ignored the error indicator
> and continued to process in the program, eventually coming back around to
> the write statement.  Hence an infinite loop that consumed major portions
of
> the processor.
>
> Ross
>
> -----Original Message-----
> From: midrange-l-bounces@midrange.com
> [mailto:midrange-l-bounces@midrange.com]On Behalf Of Vern Hamberg
> Sent: Wednesday, January 22, 2003 1:55 PM
> To: Midrange Systems Technical Discussion
> Subject: Re: Best Way to Kill Runaway Interactive Jobs?
>
>
> You might want to look at the system values that relate to inactive jobs -
> there are a number of options there, like disconnect, end, send messages,
> etc.
>
> HTH
>
> Vern
>
> At 11:25 AM 1/22/2003 -0800, you wrote:
> >We have some users who shutdown their PC's without signing off the 400.
> >
> > >>> rob@dekko.com 01/22/03 11:17AM >>>
> >1)  How does one define a runaway job?  Lots of CPU?  Lots of disk?
Never
> >ending but neither of the first two?
> >We had a runaway query that sucked up disk space.  Set a cap on the group
> >profile and that problem will never occur again.  Try to keep them at 80
> >to 90% full.
> >After shooting a few people who insisted on *wrap or *prtwrap for all
> >joblogs, the occurance of never ending dropped off significantly.
Instead
> >of getting upset because their job ended because their log was full, they
> >now try to find out why their log got full.
> >Lots of CPU?  Better start delving into the work management API's.
> >
> >Rob Berendt
> >--
> >"They that can give up essential liberty to obtain a little temporary
> >safety deserve neither liberty nor safety."
> >Benjamin Franklin
> >
> >
> >
> >
> >"Ted Barry" <TBARRY@centralsan.dst.ca.us>
> >Sent by: midrange-l-bounces@midrange.com
> >01/22/2003 01:11 PM
> >Please respond to Midrange Systems Technical Discussion
> >
> >         To:     <midrange-l@midrange.com>
> >         cc:
> >         Fax to:
> >         Subject:        Best Way to Kill Runaway Interactive Jobs?
> >
> >
> >Does anyone know of a way to setup a server job to monitor and kill
> >runaway interactive jobs?  This invariably happens when one is on
> >vacation, but never when you're clued to the system.  Why is that?
>
>
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
> To post a message email: MIDRANGE-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo.cgi/midrange-l
> or email: MIDRANGE-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
> To post a message email: MIDRANGE-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo.cgi/midrange-l
> or email: MIDRANGE-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>