RE: Best Way to Kill Runaway Interactive Jobs?

Fixing the app is one way, however, it may be that a) you don't have (or
trust) the necessary source, or b) the problem could occur in a million
places in the (large) app.  I've changed the "Maximum temporary storage"
(MAXTMPSTG) attribute on the classes that govern my interactive jobs to
avoid this very situation.  *NOMAX is the shipped value.  The value
specified here is how much temporary storage a job is allowed to use before
the system cancels the job.  I've set mine to 10Gb - I know, that's very big
but I didn't ever want any job that is legitimately going about its'
business to crash.  At this value, on my system, there'd need to be about a
dozen users switching off their PCs without signing off (at almost exactly
the same time!) and at a point in the application that writes to a screen
without monitoring the error indicator, for this problem to recur.  Could
happen, not likely.

Steve Scheele
"When the going gets tough, that's tough - I'm going."

-----Original Message-----
From: midrange-l-bounces+sscheele=ozemail.com.au@midrange.com
[mailto:midrange-l-bounces+sscheele=ozemail.com.au@midrange.com]On
Behalf Of Ted Barry
Sent: Thursday, 23 January 2003 7:00 AM
To: midrange-l@midrange.com
Subject: Re: Best Way to Kill Runaway Interactive Jobs?


What's happening is the user shuts off his machine without properly signing
off, then the app trys to recover (haven't pinpointed which app it is).  The
system then gets thrown into an endless loop.

>>> vhamberg@centerfieldtechnology.com 01/22/03 11:55AM >>>
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.