Hello,

we had also a serious problem with backup of DB2 databases because the
declared size by UDB was rather random ! The UDB utility had to be patched,
available by IBM.

Regards,

René Lambelet
Nestec S.A. / Informatique du Centre 
55, av. Nestlé  CH-1800 Vevey (Switzerland) 
*+41'21'924'35'43  7+41'21'924'28'88  * K4-117
email rene.lambelet AT nestle DOT com
Visit our site: http://www.nestle.com

        This message is intended only for the use of the addressee and 
        may contain information that is privileged and confidential.



> -----Original Message-----
> From: Ole Holm Nielsen [SMTP:Ole.H.Nielsen AT FYSIK.DTU DOT DK]
> Sent: Wednesday, January 31, 2001 4:12 PM
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Re: How to avoid sending files larger than the STGPOOL
> MAXSIZE ?
> 
> rbs AT bu DOT edu wrote:
> > >However, this didn't solve the problem.  One 120 MB file had 35%
> > >sent to the server (with STGPOOL MAXSIZE=50m), before the expected
> > >warning came:
> > >   ANS1310E Object too large for server limits
> >
> > Ole - How annoying!  On the surface of it, this doesn't make much sense.
> >
> > Does your backup storage consist of a single storage pool, or a
> > hierarchy in which Maxsize is specified on the first one?  I'm
> > speculating a case in which there is a 2-level hierarchy, the first
> > level has the Maxsize, and the second is just tape...but of limited
> > physical capacity, and the space exhaustion is being attributed to
> > the maxsize rather than "server out of data storage space".  That's
> > just a speculation, and I don't think that much of it.  The error
> > message should involve simple rejection by size, not a physical
> > attempt to accept the data.  (See APAR IY00820, which explains some
> > ramifications of ADSM storage computations.)  It may be that there
> > is a client defect where it is failing to correctly determine the
> > size of the file beforehand, but I don't see an APAR for that (which
> > doesn't mean that there isn't one).  You could try the 3.7 version of
> > the client: it would install into a separate directory from your 3.1
> > client, but watch out for /usr/bin/dsmc being pointed to the new
> > client version.
> 
> I followed your advice and installed client version 4.1.2 on a node with
> no previous ADSM client.  It works nicely, like the 3.1.0.8 client.
> However, the files exceeding STGPOOL MAXSIZE are still transferred
> over the network, until nearing the MAXSIZE limit !!  The client is
> running Compaq Tru64 UNIX v4.0F.
> 
> My storage pools are:  Primary backup pool is a 10 GB disk, the
> secondary pool is an (old) Quantum DLT4700 jukebox (7*20GB + compression).
> Both pools have STGPOOL MAXSIZE=50m !  I'm pretty sure that there
> isn't any capacity problem at all in any of the two pools.
> I forced data-compression off in the server.
> 
> The observed behavior of the ADSM v3.1.2.90 server doesn't make much
> sense:  It's very late in discovering that the client is doing a
> transfer of a file, which is going to exceed all available storagepools'
> MAXSIZE limits.  This means a huge slowdown of the backups.
> Is my problem due to lack of configuration of the ADSM server,
> or is it a bug in ADSM that I just have to live with ?
> 
> I wish that someone could verify that the newer Tivoli ADSM servers
> wouldn't have this problem...  If so, I'd order an upgrade :-)
> 
> Ole Holm Nielsen
> Department of Physics, Technical University of Denmark,
> Building 307, DK-2800 Lyngby, Denmark