>we have a TSM client installed on an NT server that has about 250gb of IBM ESS >storage attached to it. Recently we have experienced problems with the >scheduler service which appears to hang during the backup. The client schedule >and error logs do not contain any information.
Examination of the evolutionary context of the client might show that the number of files on it has been steadily increasing, and so the number in TSM storage, and thus an increasingly burdensome inventory obtained from the server during a dsmc Incremental. The amount of available CPU power and memory at the time are principal factors: it may be that the NT system's load has evolved whereas its real memory has not, and needs more. Watching the backup run via the Windows Task Manager or the like can illuminate the problem: in most cases, the client is running, but may seem like it's "hung" because it hasn't found any new files to send in a while. The monitor should show I/O and CPU activity proceeding. In the client log, look for the backup lingering in a particular area of the file system, which can indicate a bad file or disk area, where a chkdsk or the like may uncover a problem. You could also try a comparative INCRBYDate type backup and see if that does better, which would indicate difficulty dealing with the size of the inventory. TSM Journaling may also be an option. Richard Sims, BU
