Unrecognized cc:Mail header lines follow:
Receipt Requested
--------------------------------------------------------------------------------
Text item: Body.822
Text item: Body.822
Jerry - version 3 gives partial relief to your problem.  You can say
'Compressalways on' in all the clients, not just api clients. So you can
eliminate the waste of retrying when a file grows -- it will just send
the grown file (groan).

Having an exclude_from_compression statement is a very good idea!  So good
in fact that I submitted it to SHARE more than a year ago.  Unfortunately
IBM just took it as a suggestion.

Bill Colwell
The Charles Stark Draper Laboratory
Cambridge Ma.

_________________________Reply Header_________________________
Author: ADSM-L AT vm.marist DOT edu
Subject: Proposed compression change?
11-19-1997 11:44 AM

Date: Wed, 19 Nov 1997 11:44:44 -0500
From: Jerry Lawson <jlawson AT thehartford DOT com>
Subject: Proposed compression change?
To: ADSM-L AT vm.marist DOT edu

Date:     November 19, 1997             Time: 10:31 AM
From:     Jerry Lawson
          The Hartford Insurance Group
(860)  547-2960          jlawson AT thehartford DOT com
-----------------------------------------------------------------------------
I haven't seen any good requirements discussed on the list lately - is the
I haven't seen any good requirements discussed on the list lately - is the
ADSM-R list still working?

At any rate we have a client that is giving us some fits, which as we
discussed options, this item came to mind....

The problem is that the server supports an Electronic Document Management
(EDM) system.  The server (which is NT, but I don't think that matters) has
about 50 GB of DASD.  A good portion of this data are .TIF files.   These
files do not compress well; we see lots of messages about "compressed data
grew", and retries on the backups as a result.  The net effect is that for
large parts of the nightly backup, we wind up retrying most of these files.
There are, however, many files on the machine, such as the data base itself
(an SQL DB) that compresses very nicely, thank you.

In the current design, compression is a binary decision - it is either on for
the whole client, or it is off.  It can be made to be "Client Determined",
but this doesn't really change my problem.

What I would like to see is the ability to set compression on by the file
type.  There are certain types of files (such as TIF, other graphics, and
sometimes things like DLLs) that just don't compress, and we just wind up
tripping over them.  These in turn slow down the whole backup process for the
retry.  By being able to set an "exclude from compression"  indicator, the
client would skip the files matching the pattern.

Any other opinions?


-----------------------------------------------------------------------------
                                                     Jerry
                                                     Jerry

Insanity is doing the same thing over and over..and expecting the results to
be different - Anon.