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