× 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.



On 6 March 2012 14:04, <rob@xxxxxxxxx> wrote:
DSPSYSSTS shows
Current unprotect used :   401774 M

Just for reference, that's 2/5 of a TB tied up in temporary storage.  We
have a few lpars with total lower disk than that.  Here's another lpar
Current unprotect used . :   208052 M
What has ran on this second lpar?  In December we IPLd it. One weekend
only, shortly after that, we switched over from our main lpar to this lpar
to run Infor's LX on a Friday and did our Mimix switch back on Sunday
evening.  Since then, just Mimix and BRMS.  That's it.  For that it needs
1/5TB of temp storage?  Another way to look at it.  We just added four
283GB disk drives to this backup lpar.  The space of one of those is used
for temporary storage.

Hi Rob

That's quite a bit!. We had a BRMS job hit 15Gb of temporary storage
last week, which seemed pretty excessive. Have you pinpointed the
job(s) causing the issue? I have a simple temp storage checker -
http://www.dbg400.net/foswiki/bin/view/DBG400/ChkTmpStg - and now have
a background job -
http://www.dbg400.net/foswiki/bin/view/DBG400/DasdMon - that looks for
temp storage hogs. in our case it's usually ODBC sessions that cause
the trouble.

Regards, Martin

Going back to the primary one.  The primary lpar runs domino.  The backup
domino stuff is on yet other lpars and not our backup.  Here's a diagram:

      |---DomBackupLpar
PROD---|
      |---MimixLpar

IBM knows of some of our memory leaks and had to patch the OS and rewrite
the DLTSTSHMEM command to clear out some of the memory leaks.  We had so
many leaks it was blowing that command up.  They felt this might be
contributing to temporary storage.  It helped.  I even captured a
dspsyssts before/after the dltstshmem.  But that only freed up 3GB of
temporary storage.  But apparently 3GB by sametime left hanging after not
only it's jobs, but it's whole subsystem is ended, and xGB by another job
and another job and another job starts to add up.

Rob Berendt
--
Group Dekko
Dept 1600
Mail to:  2505 Dekko Drive
         Garrett, IN 46738
Ship to:  Dock 108
         6928N 400E
         Kendallville, IN 46755
http://www.dekko.com

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.





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.