Richard,

What I found this week was that the error message was correct, but the
circumstances murky.  When I moved all the files for the client to disk
before exporting, the message I got was "insufficient space in
storagepool..." in a stgpool not even known to the exporting server, a
place holder for when I have to start exporting from server2 next
week.  What did catch my eye was that it had the highest RETO in the
DOMAIN, which lead me to the DIRMC stgpool, which surprisingly, had no
volumes assigned to it.  Once the hardware guys put some storage on, the
export went fine, but only if it goes directly from disk.

But that's another story.



At 08:13 AM 7/15/2005 -0400, you wrote:

...
07/14/2005 14:06:27  ANR0687E IMPORT (from Server TSM):
Transaction failure -
                      could not commit database transaction.
(SESSION: 228,
                      PROCESS: 8) ...

Fred -

Well, I think what you have there is a system with a fear of commitment.

Whereas you are exporting to a higher level TSM system, that should
be fine. (Export-Import is documented as happy to operate where the
importing TSM server is at least the same level as the exporting one;
and it should even work across architectural platforms.)

One thing I would assure is that neither the sending nor receiving
TSM server is doing any significant database work at the time of the
export, per the manual advisory: "Because of unpredictable results,
do not run expiration, migration, backup, or archive when issuing the
EXPORT NODE command."  Whenever documentation talks about
"unpredictable results", take all cautions.

To try to narrow the problem down, what I would do is: Try the export
with MERGEfilespaces=No, unless you really need that. If you do need
it, I would try exporting the filespaces individually, rather than en
mass, and see if there's one in particular which incites the problem.
My intuition says that merging is at the heart of this problem, where
there may be some kind of policy conflict or name confusion. Merging
is highly complex, and lots could go wrong.

If the problem persists, you should contact TSM Support.  Do not take
any database actions on your own: they will advise and guide.  In
conjunction with this, it would be prudent to scan your historic
Activity Log records on the problem system and see if there is any
evidence of irregularities, particularly in the database: such info
will help the support person in getting a handle on the situation.

Let us know the final resolution, for our communal edification.

   Richard Sims

Fred Johanson
ITSM Administrator
University of Chicago
773-702-8464