VDBA shows 2688502 rows with a table size of 0 K.

d underscore roesler at agilent dot com

I don't think there is any legit reason for uncompression to fail.
It's barely possible that you might be able to sneak garbage
data past the original row compression if you fastload the
table, or if you use RAAT.  However since this is obviously
a partitioned table I'd say that neither of those situations
apply.

Is there any other DMxxxx message?
The zero sizes happen (in dm1c) when the uncompressor or row-converter
return a not-OK status.  The only place I can see that happening
for normal (data) uncompression is if the uncompressed row becomes
longer than the supposed uncompressed-row size, which would imply
either a screwed-up row size or broken compressed-row data.
All the other situations appear to issue an additional error that
ought to be logged.

The other way this can happen is if the row is NOT compressed, but
alter table add/drop/alter column is in effect;  but the same
comment applies, i.e. if there is no other message it would seem
that the converted row got too big.

Might be interesting to try DM801 to see if you can get any
non-error rows out of the table.

My guess is that either the catalog row width is broken for some
reason, or the table files have been corrupted in some peculiar way.
(e.g. it's looking at the wrong files, something like that.  The
page headers are OK but the row data isn't.)

Karl