Gentlemen,

One compromise that you may try is to leave your backups on disk through the
day and migrate them to tape immediately prior to your next backup cycle by
updating your storage pool thresholds.  You would only need to migrate
enough of the pool to comfortably hold your next night's backup.  One issue
with storage pool caching that none of you have mentioned is that it has an
adverse effect on backup throughput.  This is due to the fact that ADSM must
perform approximately twice as many updates in order to the same backup
load: Once, to delete the entry for the cached file(s) and then again to
make the entry for the new file to be backed up.  This strategy gives you
the benefits of restoring current backups from disk without incurring the
performance penalty and other adverse side effects of storage pool caching.
I hope this was helpful.

DanC
=============================================
Daniel G. Crouse
IBM Certified Specialist - ADSM
Mainstar Software Corporation
Storage and Recovery Solutions
  URL:  www.mainstar.com
Email:  Dan.Crouse AT mainstar DOT com
Vmail:  800-233-6838
Voice:  770-682-7739
   Fax:  770-682-7739
>>Date:    Wed, 22 Jul 1998 08:43:27 +0800
>>From:    Simon Watson <Simon.S.Watson AT OPENMAIL.FIC32.BSPSER.SIMIS DOT COM>
>>Subject: Re: ANR0534W
>>
>>We are having the same problem and have preferred to turn client
>>compression off rather than do away with the cache.  This seems to work
>>but is not ideal.  The problem seems to be worst on files that are
>>already compressed on the client, in our case MS Mail MMF files, which
>>actually grow when ADSM tries to compress them!  The space they need in
>>the storage pool is then more than what was originally asked for.
>>
>>We are seriously thinking of moving completely to H/W compression
>>because of this problem.  We are using 3590 drives.  Haven't quite
>>thought this through yet about how to make this change.  Do we need to
>>create now tape pools, or if we change the drives can our existing
>>tapes still be read?  Network bandwidth is not really an issue at this
stage.
>>
>>Regards,
>>Simon
----------
| From: ADSM-L AT VM.MARIST DOT EDU; roger_hohmann AT WESTLB DOT DE
| From: ADSM-L AT VM.MARIST DOT EDU; roger_hohmann AT WESTLB DOT DE
| To: ADSM-L AT VM.MARIST DOT EDU
| Subject: Re: ANR0534W
| Date: Tuesday, 21 July, 1998 11:41PM
|
| We saw this message some times ago. Then we corrected the stgp def, the
| following way:
|
| 1. caching off
| 2. maxfilesize = (100 - high mig)/100 * est cap of stgp vol.
|
| Afterwards, we have less problems.
|
| Regards
| Roger
|
| >We are getting a number of the following messages each day:
| >
| >07/21/1998 02:22:01 ANR0534W Transaction failed for session 353
| >for node PDLEWI01 (WinNT) - size estimate exceeded and server
| >is unable to obtain additional space in storage pool IT-WS-BACK-DASD.
| >
| >The message manual suggests we either have to turn off cache
| >at the server or compression at the client, neither of which is
| >an attractive solution. Is there a fix that would force the
| >server to go ahead and free up more space and then retry the file?
| >
| >David Ehresman
| >University of Louisville
| Roger Hohmann
| WestLB
| Division: 009 Services
| Abteilung: 001-80633
| Herzogstrasse 15
| D - 40217 Dusseldorf
| Tel.: +49211 826 8155
| Fax: +49211 826
|