Another alternative is to identify the owning application and see if *it*
can read some, if not all, of the data. Perhaps that application has a
feature that allows it to copy data from the file to another file,
affording the opportunity to rescue as much of the data as possible.

Regards,

Andy

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com

The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.

"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 11/26/2004
06:50:37:

> ...
> >ANS1228E Sending of object '/intermail/mss_db/mbox/18/db' failed
> > Read Failure
> ...
> >ok, the file is obviously corrupt on file system and we HAVE TO back it
up
> >... how ?
>
> Well, not "obviously" until you do the environmental problem analysis to
> find out what the problem *actually* is: an OS error log may reveal that
> there is a disk situation at play - which might be something as
resolvable
> as a loose cable or failed power supply, meaning that the disk and its
> data may be intact but currently unreachable.
>
> If all is well in the hardware and you have to satisfy someone's odd
> insistence that the data be in TSM storage, an image copy may be able
> to simply capture bits.  Of course, without resolution of the
fundamental
> issue involved here, the data would likely be pointless as a later
> restoral candidate, unless the intention was future forensic analysis
> rather than usage.
>
>    Richard Sims