Jim...Because of the reboot, ADSM was not able to write an
end of tape marker on that tape volume.  However, each individual
file written to that tape should be fine because adsm can
guarantee its transactions through its commit processing.
Files that had not yet been written to tape during the migration
process should have been rolled back when you reipled the server
and should still be in the disk pool...there should be no 'lost files'.

The tape volume is marked readonly and files on that tape should
be accessible without a problem...but you won't be able to write
additional files to that tape.  Probably the best thing to do
would be to perform a MOVE DATA on that tape volume to move all
valid files on the tape to other storage pool volumes.  The
tape volume can then be reused as a scratch volume.

Greg Tevis
ADSM technical support
 ========================================================================

We are in process of testing ADSM for Sun/Solaris and plan to ease it into
production using backups done during our testing.  We had a Solaris system
problem, ended by an emergency reboot, while the ADSM server was in the midst
of migrating files from disk to 8mm tape.  The tape got damaged (?because the
server didn't get shutdown properly?) and is now flagged as "read-only", but
might not actually be readable either.  We have disk-caching turned on for our
ADSM backuppool so the "possibly lost" files are actually still on disk.  Is it
possible to change the status of these disk files from "migrated and cached" to
"unmigrated" so that I can delete the damaged tape volume and just start the
migration process over again with a new tape?  Please advise how to proceed.

Thanks for your help.
Jim Owen