ADSM-L

Re: TSM with 3rd party scheduler

2002-02-27 09:25:17
Subject: Re: TSM with 3rd party scheduler
From: Joseph Seigh <jseigh AT GENUITY DOT COM>
Date: Wed, 27 Feb 2002 14:22:50 +0000
Quoting Daniel Sparrman <daniel.sparrman AT EXIST DOT SE>:
> Hi
>
> I don't know what kind of OS you're using, but the pending move is only on
> the TSM server. That because it's not the server that controls the
> schedule, only the client.
>
> If you look at the log on your client , it will tell you if it has received
> the schedule. So, there is nothing wrong with the TSM scheduler. It a
> client/server software, and this means almost all information is stored at
> client level, not server level.
>
> The reason for this is probably that if you have a lot of clients(>1000),
> having all information stored at server level will be very hard to analyze.
> You only want to analyze clients that have missed, failed or (?) status.
> Therefore, it's easier to analyze at client level, when you have determined
> which clients are having problems.
>
> You could probably redirect information from the client scheduler to the
> server, but this would mean that your actlog would grow beyond proportions,
> and troubleshooting client errors could be very hard, if not impossible.
>
Actually, we do redirect the client scheduler log back to the server.
We have a userexit to demultiplex the output back into individual
client logs.  Works quite nicely though it would have been nicer if
the tsm client send useful information back to the server in the
first place.  But in this case the redirect is run as a
POSTSCHEDULECMD so you don't see anything until after a schedule
has run.

The problem is that if for example you have 1000 clients scheduled to
backup during an 8 hour window, it would be nice to know which clients
have non functioning scheduler daemons at the beginning of the window
rather than at the end of the window when it would be a lot more difficult
to meet your SLA's.

Joe Seigh
<Prev in Thread] Current Thread [Next in Thread>