Jim - I've seen this when client option compressalways is set to yes and a
binary file type "grows" during compression. Setting compressalways to no
corrected the problem. Is there any further information regarding how
"emergency extentions for low estimates"  work from David Bohm's post?

I am seeing a few "ANR0534W Transaction failed for session nnnn for node
xxxx - size estimate exceeded amd server is unable to obtain storage"
messages every night in the peak part of our client backups. I run with
CACHE=NO for the disk BACKUPPOOL which is the target for my backups and I
see the message even if the %Migr is fairly low altho more often if it is
high.  My console or log file (VM server running ADSM V2) is directed to
another virtual machine which issues a Q STG BACKUPPOOL when it sees the
ANR053W message so I know what %Migr is at that point.  What is puzzling,
because of the fact that I am not caching is that %Util is usually 100% or
real close.
Does the delta between the low %Migr and the high %Util represent the amount
of space that has been reserved for other clients that are concurrently
being backed up?  I run with migration, low and high, set to 20% and 90%
respectively.  If I were to drop the high end to, say 60% or 70% should that
buy me something?

I don't remember seeing the problem before I increased the number of clients
that could be backed up concurrently because I was too frequently having
sessions fail because the number of clients was at the limit.

Jim Bohnsack
Raytheon Systems Co.

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com