ANR0534W error

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