Ted, > I cannot tell if you're being sarcastic or not, but we did use compression on > our banking databases, VSAM, and flat files. [Ron Hawkins] Yes I was being sarcastic - you caught me - but it is still fact that I have successfully used these techniques for many countries, Banks and Telcos. I am surprised that the criteria we agree on ( example 2) does not apply to any dataset in any Canadian company you have worked for, but then again your maxim decrees that you would never look for IO reduction as a benefit. Remember we are talking about IO reduction to datasets that improves an application's critical path, and not the wholesale compression of datasets to save space. I work for a storage vendor so I would never recommend compression to save space...
> Both hardware and software (SHRINK). [Ron Hawkins] For Shrink to be hardware compression it must be using the instructions provided for compression services. That means it would be an asymmetric compress/decompress cost similar to DFSMS compression so we can be comparing apples and apples. > Around the late 1990's, we found they weren't worth the so-called benefits. [Ron Hawkins] Ted, you have only referred to space as the defining measure of your decree, so what of IO reduction? You claim to have never measured it because space savings neutered all other cases for compression. We are not discussing the so-called space and cost saving of uncontrolled compression, because I agree with you. Please don't compress your datasets and save DASD, because you hurt my bonus. We are talking about IO reduction that you may not be enjoying because of a space/cost based precept. > > A couple of years ago, I was working for a wholesaler who used EDI for the > majority of the orders. > The app updated an order file and deleted entries as the orders were > processed. > So, it was at least 67% writes. > > The app speeded up when we removed compression. [Ron Hawkins] No argument from me. It has no similarity to the example we agree on, or the synchronous remote copy example. In fact it I probably would have disregarded this file completely unless it was using synchronous remote copy? Even then, if it was a KSDS that did not use Deferred Writes it would most likely be a poor candidate for compression because there would not be any IO reduction due to compression. A KSDS using LSR with Deferred Writes would be a completely different proposition because the write percentage would probably be significantly smaller, and smaller again with compression. > > - > I'm a SuperHero with neither powers, nor motivation! > Kimota! > [Ron Hawkins] Why K? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
