That is not the way it works.

Each backup image of a file is an object and is assigned an object id.  That
object id is in the CONTENTS table which shows the relationship of an object
to a volume.  The unfortunate part is the CONTENTS table is only indexed by
volume_name meaning any searches against it run forever if your database is
large like mine.  So, really there is not a way to find out easily.

Now, to explain how it works.  During a copy of a primary pool to a copy
pool TSM compares what objects have not been copied to that backup pool in
the backups table (I guess, that is the only place the information could
be).  Then, it synchronizes the entries by reading from the primary and
writing to the copy pool tape and creates the entries in the contents and
backups tables.  So, if several backups were run before a backup stgpool is
run the stuff could be all out of sequence in the copy of primary to copy
pool and TSM does not care because it knows where everything is.  So, forget
primary volumes to backup volumes, that does not exist in TSM.  You have to
think about two tanks of marbles.  One tank has 1 million marbles that are
capable of cloning themselves so they can be put into another tank any time
you ask.  The target tank can clone back to the source tank only if the
source tank clone does not exist.  The tanks are made out of stackable rings
that can be added to make them bigger.

Paul D. Seay, Jr.
Technical Specialist
Naptheon, INC
757-688-8180