Quoting Richard Sims <rbs AT BU DOT EDU>:

David -

I concur - I've never seen the TSM client lock files for backup, nor
seen any documentation suggesting that it does.

I perceive that the DBA made the claim without providing you with any
evidence.  Have them provide you with evidence from any tool they used
to detect such a condition.  More to the point, the SQL Server error
log should have detailed info on why it flagged the database as
Suspect - which can have many causes.

Hi Richard,
You're right, the DBA claim that without evidence, neither filemon
or other monitoring tool. Thanks to pointing to detailed sqlserver
log, I'll see it with DBA.

The larger issue is why TSM physical backup should apparently be
running at the same time as the SQL Server.  That would constitute a
"fuzzy backup", which would probably not result in a consistent,
usable object if restored.  Generally speaking, to use physical (i.e.,
TSM B/A client) backup tools on a database, the database server needs
to be down.  If striving to keep SQL Server up during backups, the TDP
would be the way to go.

   Richard Sims

Unfortunely, I'm ok with you about all of that...
We use TDP for many databases, but the DBA team don't want TDP for this one.
They want SQL Server up at a fixed time in the morning. The DBA stop the
server before backup and restart it at fixed time, backup finished or not...
I've spent many hours in meeting about that but the DBA don't want change
the configuration.

Cheers
David