On Aug 17, 2011, at 7:34 AM, Daniel Sparrman wrote:

> ... I have no access to the dsmerror.log / dsmsched.log so I cannot tell you 
> what kind of error (if any) to look for.
> 

This is a common situation in most most sites, where the TSM administrator is 
not afforded access to client systems, and yet is usually the only person with 
the knowledge to make sense of TSM processing issues.

Sites might consider instituting a standard client schedule model where a 
POSTSchedulecmd transmits a copy of the dsmerror.log and dsierror.log to a 
central location which allows such review by the TSM specialist.  Conveyance 
might be via scp, NFS, or even a 'dsmc archive' with a modest retention period 
and Set Access permission.  This should be an "easy sell" in most environments, 
given that logs are typically ignored by client administrators, and yet often 
reveal files which everyone thinks are being backed up but never are (as in 
Linux LANG/locale conflicts).

     Richard Sims