Thank you very much; that turned out to be exactly what happened.
One of our client systems has an application built around a
database made up of ten files. Some of the files change on any
day when the application is used, and some change much less
frequently. The database has had chronic problems with both
integrity and recoverability. The application vendor insists
that the recoverability problems occurred because different
database files were backed up on different days. My management
is well aware that this is nonsense, but felt that it was
necessary to back up all ten database files every day to
pressure the vendor into addressing the real issues. I set
up a new management class with 'mode=absolute' in the backup
copy group. The new class was tied with our existing default
management class for longest retention period. The TSM
documentation does not specify how ties are resolved when
selecting a management class for directories. At least some of
our client systems used the new management class for their
directories.

Best regards,
Thomas Denier

-----Steven Harris wrote: -----

>A distant possibility is that the tree being backed up has a
>different
>management Class and that has had its copymode set to absolute.

>>> -----Original Message-----
>>> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On
>Behalf
>>> Of Thomas Denier
>>>
>>> We recently noticed an unexpectedly rapid increase in database
>space
>>> usage on one of our TSM servers. This seems to be the result of
>two
>>> Windows clients that are consistently backing up hundreds of
>>> thousands of files every night. We checked our other two TSM
>servers
>>> and found two more Windows clients behaving this way.
>>>
>>> In all four cases the behavior started during the same backup
>>> window:
>>> late October 9 and early October 10.
>>>
>>> All four systems are in the same Windows domain. The domain
>>> administrator does not recall any noteworthy updates on October
>9.
>>>
>>> One of the Windows administrators involved looked at dsmsched.log
>and
>>> reported that the backups include large numbers of files that
>have
>>> not been updated or even accessed recently.
>>>
>>> The four Windows clients have, among them, three Windows levels
>(XP,
>>> 2003, and 2008), two TSM client levels (5.3 and 6.2), and three
>>> groups of people responsible for system administration.
>>>
>>> The three TSM servers involved include one 5.5 server and two 6.2
>>> servers. All run under zSeries Linux.
>>>
>>> I would appreciate any suggestions regarding possible causes for
>this
>>> behavior.