Richard my sincerest apologies to you and the group. I consider myself
scolded ! Twice!!

TSM Verson 5.1.0 is the server level.

Taking the server up to say 5.1.6 may well fix it Richard. Unfortunately, we
live an far from perfect world and we have SAN agents running that need to
go up at the same time. These agents are across a great many nodes.  So
these issues need also to be considered.

Unloaddb failed. This is an undocumented feature in 5.1.0 so the unload and
reload is not on.

Seems also that on closer look simultaneous writes to different storage
pools may be causing and issue. (This we expect is fixed on 5.2) ???? Once
again we need to consider the SAN agents on the other machines. These need
to come up to version 5.2 at the same time and the nodes need a reboot if
not mistaken. This is not as a simple task in our environment and will need
to be phased in over time. The upside may well be the phase in process,
which may be that we dedicate a new 5.2 Server and move across the nodes as
we upgrade each node. What we need to consider is the method of eventually
marrying the two machines after all is done!

Meantime, we'll keep a close eye on the monitoring of the database, and
recovery log consumption etc, until we can move up to a Version 5.2.

We hope there are no gotcha's there. If there gotchas then I'd sure
appreciate a posting.

Thanks again for the scolding.

Stephen :-)





-----Original Message-----
From: Richard Sims [mailto:rbs AT BU DOT EDU]
Sent: 16 December, 2003 9:33 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Intermittant TSM Server - Database stops


...
>Since then, TSM Server stops at random times. (no messages in the actlog)

The *SM server has traditionally been programmed to produce an error log in
its
server directory when it crashes.  Have a look for such.

It could well be that simply boosting your maintenance level will resolve
the
issue.

A server with such issues needs to be carefully monitored.  In particular,
watch
Database and Recovery Log consumption as the server operates through the
day, and
watch for space constraints and anomalies.  Your surviving Activity Log from
the
crash vicinity may record the start of some highly-consumptive process which
may
need investigation.

  Richard Sims, BU