HI, I think your problem might be the NOLIMIT option - it saves a copy of all files - whether or not they are deleted - it doesn't clear space off your disks during expiration - we had the same problem - until I removed NOLIMIT off our Novell policy.
Jane %%%%%%%%%%%%%%%%%%%%%% Jane Bamberger IS Department Bassett Healthcare 607-547-4750 ----- Original Message ----- From: "Matt Simpson" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, October 22, 2002 9:46 AM Subject: Re: Co-location > At 3:53 PM -0400 10/21/02, Thach, Kevin said: > >The person that installed our environment basically set up 6 Policy Domains: > >Colodom, Exchange, Lanfree, MSSQL, Nocodom, and Oracle. > > > >99% of the clients are in the Nocodom (non-collocated) domain, which has one > >policy set, and one management class which has one backup copy group with > >retention policies set to NOLIMIT, 3, 60, 60. > > This is away from the topic of Kevin's question, but his background > info led to a question that we're looking at right now. > > We currently have one big disk pool for all our backups, which > migrates to one tape pool, which we copy to another tape pool for > offsite. > > We turned on co-location on the onsite tape pool a couple of weeks > ago, because we just started using the SQL TDP, and the doc > recommended colocation. We turned it back off this morning, because > we were running out of tapes and had a lot of them that were only 5% > full. > > We would like to do what Kevin says he's doing: specify colocation > for a small number of our clients and leave it off for a bunch of > them. But, if I understand correctly, colocation isn't specified > directly in the management class. It's specified on the tape > storage pool definition. So specifying colocation for some clients > but not all would require multiple tape storage pools, which wouldn't > really be a problem. But it looks like that would also require > multiple disk storage pools, because, as far as I can tell, the only > way to get a client into a different tape pool is to have it in a > different disk pool. > > We'd really like to avoid carving up our disk space into more smaller > pools. But, as far as I can tell, that's the only way to use > colocation selectively. Am I missing something, or is that the way > it works? > -- > > > Matt Simpson -- OS/390 Support > 219 McVey Hall -- (859) 257-2900 x300 > University Of Kentucky, Lexington, KY 40506 > <mailto:msimpson@;uky.edu> > mainframe -- An obsolete device still used by thousands of obsolete > companies serving billions of obsolete customers and making huge obsolete > profits for their obsolete shareholders. And this year's run twice as fast > as last year's. >