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
|