I fully agree with you Richard, and we do have a central log storage at this 
customer. However, in this case it's a simple matter of only being able to 
access the TSM server via remote HTTP (i'm not onsite) ;)

Best Regards

Daniel Sparrman


Daniel Sparrman
Exist i Stockholm AB
Växel: 08-754 98 00
Fax: 08-754 97 30
daniel.sparrman AT exist DOT se
http://www.existgruppen.se
Posthusgatan 1 761 30 NORRTÄLJE



-----"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> skrev: -----


Till: ADSM-L AT VM.MARIST DOT EDU
Från: Richard Sims <rbs AT BU DOT EDU>
Sänt av: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Datum: 08/17/2011 14:59
Ärende: Re: [ADSM-L] Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] Help tracking down 
spurious "Failed 12" errors

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