This is the result of a combination of things going on. You have a client
that supports compressalways and you are running caching in your disk pool,
and compression is turned on for the client. The compressalways change will
eliminate the retry on "compressed data grew" - it will continue to send the
file after detecting that the file is not compressible and is in fact getting
larger.
There are 3 ways to circumvent the problem:
1. Turn off caching
2. Turn off compression
3. Add a statement to the options file for the client that says
"Compressalways NO"
Of the three, the last is the one that appealed to me personally, since it a
return to the way things were prior to the implementation of compressalways.
It will cause the client to retry when a file grows.
BTW, the problem is caused not when the data grows so much as when the
storage pool is at high utilization - and with cache turned on, that is
usually the case - 99.9% is common. The client estimates the file space
needed, then starts the compression/transmission. If the estimate is
incorrect, and more is needed, the ANR0534 is the result. The unfortunate
thing here is that, true utilization of the pool (the amount migrateable) is
almost always considerably less - We sometimes saw this at 20%! IBM has
recognized that this is an issue, and an APAR (PQ12677) was taken, but it was
still open the last time I looked.
Hope this helps - we have had no reoccurrence since changing to
compressalways no.
Jerry Lawson
jlawson AT thehartford DOT com
______________________________ Forward Header __________________________________
Subject: ANR0534W error
Author: INTERNET.OWNERAD at SNADGATE
Date: 2/23/98 10:49 PM
We received the following error on one of our (Digital Unix) servers
last night:
02/23/98 17:48:32 2951 for node ANR0534W Transaction failed for
session
AUDOZX617 (OSF/1) - size estimate exceeded and server
is
unable to obtain additional space in storage pool
BACKDISK.
I think I remember reading about this error here within the past few
weeks, but I haven't had any luck finding it in the archives. From what
I remember, this is a problem in some (all?) V3 clients. Can someone
fill me in on the details? Cause? Fix? I understand that the workaround
is to disable caching on the storage pool, but I am not keen on doing
that.
Thanks,
Trevor
|