What I ended up doing was something very similar to Steve's suggestion.
However, since they were db2 logs that were backed up, their path didn't
really exist.  I ended up going to another machine, creating a stanza in the
dsm.sys for the node I wanted to mess with.  I created directories mirroring
the path that db2 used (/dbname/dbnode), and touched the files in there.  Of
course, I had to use virtualmountpoint, but in your case, since Windows uses
filespace names like \\compname\d$, I think you should be able to rename
that filespace to the new machine/drive you're doing this on and then back
up each file individually.  If you just back up the directory, you'll have
to copy all those active files over or they'll inactivate.  So, to make a
cryptic paragraph easier to understand:

ServerA - server data normally lives on
ServerAnode - nodename that ServerA uses
ServerB - server that you'll use to recreate the path in consideration of
the queueing.

1.  Create a stanza for ServerAnode in the dsm.sys on ServerB.  Be sure to
use the correct includes/excludes.
2.  Recreate the path to the files on ServerB.
3.  Create all those zero length files you want to rebind.
4.  On the tsm server, "rename filespace \\ServerA\x$ \\ServerB\y$" where y$
is the drive where you recreate the path.  This because when you back up
those files, it wants to use the UNC of the current drive.
5.  Back up each file individually to rebind it.  This is necessary because
otherwise it'll inactivate all those other active files.  If inactivating
all those files until the next backup is OK with you, that'll save a bit of
work.
6.  In TSM, rename the \\ServerB\y$ filesystem back to \\ServerA\x$.

Voila, your files have been rebound and everybody is still wondering which
pea the cup is under.

Good luck,

Alex Paschal
Storage Administrator
Freightliner, LLC
(503) 745-6850 phone/vmail