>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