Thanks...this will help.

        -----Original Message-----
        From:   Bill Colwell [SMTP:bcolwell AT DRAPER DOT COM]
        Sent:   Monday, November 23, 1998 3:33 PM
        To:     ADSM-L AT VM.MARIST DOT EDU
        Subject:        Re: Compression vs Non-compression Stats

        In <7D56E0277E05D211971A0000580119270215CE9B AT msgmsp4.norwest DOT 
com>,
on
        11/23/98
           at 02:19 PM, "Glass, Peter" <Peter.K.Glass AT NORWEST DOT COM> said:

        >Hello Group,
        >We are on ADSM V3-MVS, backing up about 300 clients of various
platforms,
        >including about 110 or so UNIX platforms. We currently allow
clients the
        >choice of whether to compress. Most of them do not. In order to
slow  the
        >rate of DASD growth in our primary backup pool, we are considering
forcing
        >compression from the Server. We would like to get an idea of  how
much of
        >an impact we can expect in terms of CPU usage, and backup runtimes.
Does
        >anybody know of an algorithm that can forecast approximate CPU
usage with
        >compression turned on? Disk space savings? Or where I can look for
this
        >kind of information? Any advice or instructive personal experiences
along
        >these lines would be greatly appreciated. I would at least like to
get an
        >idea of how much compression I can force without burying the CPU.
Also,
        >whether the savings in disk space would be enough to make this idea
worth
        >pursuing. Thank you!

        You can expect your mainframe cpu usage to go down but not by that
much.
        There will be few aggregates to allocate, track in the db, migrate
to tape,
        etc.

        The backup time for a single client will go up, but you should focus
on the
        total end-to-end daily cycle -- client to server to tapepool -- and
tune to
        optimize that.

        If you turn on compression from the server, I recommend also turning
on
        compressalways in the client option sets.

        --
        -----------------------------------------------------------
        Bill Colwell
        C. S. Draper Lab
        Cambridge, Ma.
        bcolwell AT draper DOT com
        -----------------------------------------------------------