Maybe there is a slight confusion as to what COMPRESSALWAYS does.
Basically, if compressing an object causes it to grow (if already compressed,
for instance),
ADSM would retry, turning off compression for that object.  If this happens a
lot, this is clearly
a performance overhead.

COMPRESSALWAYS YES says that even if the object grows, go ahead and send this
compressed
(larger) object anyway.  This removes the performance overhead, but again if
you have too many, you
are sending more than you need to, so turning COMPESSION off is the answer.

This is why COMPRESSALWAYS default is YES.  It will have NO effect unless
COMPRESSION is
also ON.

Hopefully, this will remove some of the confusion.....

>I noticed the default in the V3 client has changed from compressalways NO
>to    compressalways YES.
>We don't use compression in any of our large local clients because it's
>always been faster to not compress.
>Have any of you switched from no compression to compression with your v3
>rollouts?   Is compression now significantly faster to justify this change
>of default?
>Should I use the new capability with V3 on the host to change all the
>clients back to compressalways NO?
>Thanks,
>Julie