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


  • Subject: RE: IPL frequency (was Who has a big QTEMP?)
  • From: "Shaw, David" <dshaw@xxxxxxxxxxx>
  • Date: Wed, 30 Aug 2000 09:44:40 -0400

Comments in-line:

-----Original Message-----
From: James David Rich [mailto:james@dansfoods.com]

>On Tue, 29 Aug 2000 booth@martinvt.com wrote:

>> Do your other machines run pretty good at 95% dasd utilization?  I know
my 

>Yes, my other machines (AIX and linux) do run well with very nearly full
>disks.

Don't those OS's have their virtual memory swap spaces pre-allocated on
disk?  That makes a machine much more tolerant of having nearly full disks,
since some of the "fullness" is actually empty space waiting to be used.
Undersize your swap space, though, and you have the same kinds of problems
when it fills up.  The /400's virtual memory model is a lot more flexible,
but does need space to work in, and doesn't provide a way to "hide" it in a
pre-allocated space.

>> wife's Windows box goes into a tailspin at about 85%.  It likes lots of 
>> swap space. and if it doesn't get it it doesn't warn her, it just goes 
>> blue or black and then re-IPLs, or she has to re-IPl.

>I don't really trust windows to get anything right.  Nor do I think that
>reliablilty should be stated in terms of 'its better than windows'.  The
>as400 is important enough that it should be up all the time, not just more
>than somebody else.

Windows, by default, uses an extendable swap space.  This makes it more
flexible than if it had a fixed swap space, but makes it susceptible to
performance problems when the swap space is fragmented.  Obviously, if the
free space that it extends into is badly fragmented, performance will worsen
as the disk fills up.  A Windows machine can run with very little
performance degradation at very high disk utilizations IF the free space is
kept defragmented.

Analogously, the /400's performance won't degrade as fast when disk fills up
if the free space is not heavily fragmented.  With V4R4 IBM has finally
given us the STRDSKRGZ command, which essentially is a free space
defragmenter.  I haven't had the opportunity to test it (thank heavens!),
but theoretically at least it should help those with high DASD utilizations
if it's run regularly.

>From reading other posts on this topic I am discovering that there are
>people who keep their machine up almost all the time.  And I am finding
>the reasons people shut them down.  It surprises me that an IPL was a
>requirement to simply get some disk space back.

It actually isn't a requirement.  I think the reason that the machine does
it on its own when it maxes out is because the designers found it to be the
simplest way to:

1) stop the (perhaps unknown) process(es) filling the space, and
2) get back space from temporary objects, QTEMP libraries, and virtual
memory so that the machine can run normally again.

I caught a system once at 99.98%, and managed to stop the job filling it up
and recover the disk space without an IPL (job was doing saves to save files
in QTEMP - without compression).  It was at the point where no one could
sign on - attempts to do so would hang.  Fortunately I knew which job it had
to be and was able to kill it at the console, which we left signed on to
QSYSOPR at all times.

Dave Shaw
Spartan International, Inc.
Spartanburg, SC
+---
| 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
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.