Quoting Daniel Sparrman <[EMAIL PROTECTED]>: > 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
