Is this a version 3 ADSM server and version 3 client? If so, then this sounds
very much like APAR IC19915. Currently we have test fixes for these platforms:

* AIX 4.1
* AIX 4.2 (and 4.3)
* NetWare

The test fixes are available on the ADSM ftp site index.storsys.ibm.com in the
/adsm/fixtest/v3r1 directory structure. The installation files have "IC20488"
in their names, not "IC19915". This is because both IC20488 and IC19915 are
fixed in the same test fix (both APARs are related). A test fix for Windows
NT/95 should be available within a week.

Assuming that your problem is indeed IC19915 and/or IC20488 (and I bet it is),
then the test fix should allow you to restore the problem files without any
data loss... assuming, of course, that the data is otherwise intact. The
problem was in the data expansion routines which are invoked during restore
operations if the client compressed the data during backup.

Andy Raibeck
IBM Storage Systems Division
ADSM Client Development
e-mail: storman AT us.ibm DOT com



ADSM-L AT VM.MARIST DOT EDU on 06/04/98 12:34:20 PM
Please respond to ADSM-L AT VM.MARIST DOT EDU
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: Help on ANS4032E


Hello,

one of my clients got this error,

ANS4032E Error processing 'c:\xxx\yyy.zzz': file is not compressed.

The book states:

ANS4032E Error processing 'filespace namepath-namefile-name': file is not
compressed.
Explanation: A file that was flagged as compressed was not compressed, and
the system failed.
System Action: Processing stopped.
User Response: See your system administrator to report this problem. This
error is a system failure.

So the client comes to me and says "What gives?"  I said, "Get back to you
real soon!"
So, first question - is this dataset recoverable?  Need this answer ASAP.
Next questions are (not necessary in any order):
Will there be a next time?
How can we be proactive about this?
What did we do wrong?
What can we do to fix/prevent this?

Your thoughts and comments are always appreciated.

Mark Mapes
PG&E