Re: "unprotected" storage usage

[Dave Shaw <dshaw1@xxxxxxxxxxx>]

-----Original Message-----
From: Graap Ken <keg@gasco.gasco.com>


>>Just before our last IPL, WRKSYSSTS showed our "Current
>>unprotect used" at over 20 GB, on a system with only 54 GB of DASD total.
>
>Dave,
>
>Interesting... I've had a similar problem and tracked it down to query
>commands that were doing joins against large data base files. I mean large,
>12GB - 66,000,000 record files!
>
>When these SQL or query jobs run I've seen them consume huge amounts of
>temporary system storage. We had one "out of control" adhoc query consume
>20GB of temporary space before an operator finally canceled it.
>
>Since we allow adhoc queries to be submitted and as we all know, humans can
>make mistakes, I've written a little utility that monitors the amount of
>temporary storage used by batch jobs. If any particular job uses more than
>2GB of temporary storage I notify the operator, and myself so we can keep
an
>eye on it.
>
>Of course the use of temporary storage is controllable via work management,
>on the *CLS object, but there are some problems with the implementation of
>this on V4R3. The parameter, on the CHGCLS command, used to control the
>amount of temporary storage a job can use is: MAXTMPSTG.  This value
>defaults to *NOMAX and you can only specify *NOMAX or a number up to a 2GB.
>The only action available when the MAXTMPSTG threshold is exceeded is to
end
>the job. This wouldn't work in our shop. We regularly have jobs that use
>3-5GB of temporary storage to run queries. That's why I wrote my utility to
>keep an eye on things...
>
>Do you use SQL and query in your shop?

Lots of it - we use ASC's Sequel for everything under the sun, we have users
doing downloads with both File Transfer and ODBC/MS Query, plus we have one
of the MAPICS client/server modules which uses ODBC heavily.  We had a
runaway job yesterday which ate 15 GB before we caught it - it was a
QZDASOINIT prestart job in QSERVER which was running an ODBC query for a
user - the user had killed her PC task, but the /400 didn't know about it.
We killed the job and got that space back, but I can't figure out where the
day to day incrementals are.

How does your utility get its information?

Thanks, Ken!

---
Dave Shaw, General Nutrition, Greenville, SC
To subscribe to the MAPICS-l mailing list send email to
MAPICS-L-SUB@midrange.com
The opinions expressed may not be my employer's unless I'm sufficiently
persuasive...



+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---