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 [email protected] http://www.existgruppen.se Posthusgatan 1 761 30 NORRTÄLJE -----"ADSM: Dist Stor Manager" <[email protected]> skrev: ----- Till: [email protected] Från: Richard Sims <[email protected]> Sänt av: "ADSM: Dist Stor Manager" <[email protected]> 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
