Richard, and others,

Thanks for the on- and off-line responses. I have followed up the
suggestions made, but so far no success.

Richard,

I checked to make sure that nothing was strange with the filespaces. I
actually did an incremental from the command line, then followed it up
immediately with another, and sure enough almost all the files backed up
twice. DSMC Q FI shows just one occurrence of each defined filespace, so
I don't think anything is happening to them between backups. In this
case, it would have had to have happened in about one minute.

Q BACKUP on the client shows multiple instances of each file -- one
active, the rest inactive. I don't see anything on the details of each
file that indicates a change. Last access date, file size, all appear
identical. I chose several operating system files that I know have not
changed since the last server upgrade (more than a year ago) and they
still back up when using INCREMENTAL by itself.

The number of files backed up is just a few dozen short of the number
inspected - a difference which is attributable to those files that were
open (such as log files) and could not be backed up. Obviously, with
full backups running each night, my tape count in increasing
dramatically.

I have run traces, and have a call open with IBM. It has been open for
20 days. They are stumped as well, and have no idea what to do. So, I
was trying this avenue again in the hope that someone else may have seen
this. 



-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Richard Sims
Sent: Monday, January 28, 2008 5:43 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] TSM performing full backups where incremental
specified

Kevin -

Heck of a problem you have there.  I don't do z/OS or Netware, so
unlikely that I'll have an answer, but some thoughts...

This is too obvious, but: The filespaces involved are not in some way
being renamed or deleted in between the mass incrementals?  That would
cause a full backup.  Seems very unlikely to me, but one thing I would
consider.  Does a 'dsmc q fi' show a singular instance of the suspect
file system?  Here I'm thinking of some oddity causing the server to
believe that the file system is different each time.  But, tape
consumption would cause this to stand out.

In the backup log, does the number of objects backed up equal the
number inspected?  If a substantive difference, I would look into the
exceptions to see what's the basis of their immunity.  Also, perform a
'dsmc q ba -detail -ina _______' on one of the files and see if all
versions look the same, or there is some different which might incite
the backup.  And, if you don't see a bunch of versions, it may be
possible that some mutation to the policies is causing obliteration of
what was backed up the last time.

As a last resort, I would run a client trace of your partial versus
unqualified incrementals and see if any functional differences stand
out in causing the mass backups.  If nothing apparent, give TSM
Support a call.

    wacky stuff I can think of,  Richard Sims