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