Brian - You'll have to examine the scheduler log and possibly the dsmerror.log to determine why the backup was "unsuccessful".
My cumulative notes on sparse file handling in ADSM QuickFacts may be helpful. Whereas Unix systems have sparse files, but no file system attributes to so flag them as such, any application has to plow through the entire contents of the file to discern that it really is sparse. Though the physical file (as reportable by 'du -sk') may be small, Unix generates the full entirety of the file's address range when read, inserting nulls to represent the unused space. This can tax an application, and in TSM's case may lead to a timeout in waiting for the application, depending upon conditions. To make matters worse, some of these files log system activity, and so can be in continual flux, and so costly retries can be futile. You should consider excluding bogies like this one from backup. Richard Sims
