From: Mike Knight, IBM GS Central, (314)234-5096, KNIGHTM at ISSCVM
Inet:                                             KNIGHTM AT VNET.IBM DOT COM
Subject: Re: V2 -> V3 Upgrade on AIX

We have a similar situation with ANR0534W errors, but with ADSM 2.1.0.13
and 2.1.0.15 servers on AIX 4.x and during incremental backups instead of
archives.  In our case, the errors are seen on most, or all, Netware
clients that have been upgraded to the ADSM 3.1 client.  Other client
platforms run fine.  We also are not using client compression and ADSM
support has not been able to isolate the cause yet.  We tried turning off
the disk cache on one server and had the same problem with terrible server
performance for several days with the CPU 100% busy.  We turned caching
back on and performance got better the next day.  We are now living with
hundreds of these errors every day.

My opinion is that turning off caching just means the server is able to
get more space and bypass the message when the client makes a bad
estimate.  There is still something that is causing the incorrect estimates.

         Mike (Just another user, personal opinion) Knight
 =========================================================================
On Fri, 13 Mar 1998 09:18:43 +1100, Trevor Foley said:

>The server that was downgraded had two problems after the upgrade. We
>use the VMS ADSM client from SSSI. After the upgrade most (all??)
>archive operations failed with ANR0534W (size estimate exceed and server
>is unable to obtain additional space in storage pool). This sounded a
>little like the problem that was reported were some weeks back that
>involved compression, compressalways, and cached disk storage pools. We
>are not using compression, so we, nor IBM, nor SSSI, as yet understand
>why this message is occurring.
>
>We did implement that workaround mentioned for that problem though,
>which was to disable caching. We did that, and then re-ran some archives
>that had failed previously and didn't get the error.
>
>However, we then noticed some pretty severe database performance
>problems. This was narrowed down to a particular client session. This
>session was very difficult to cancel from the server; it continually sat
>in run state. Several minutes after doing a cancel session, the session
>finally went away. And when it did, performance became reasonable. We
>weren't comfortable with continuing with V3 though until we understood
>this problem. And we still don't.