Ted, I'm wondering if your primary rule of not compressing a file unless it will exceed its architectural limit may have blocked the opportunity for you to come across cases where compression is not a waste of time.
Synchronous remote copy is one area where compression of datasets created or updated in the batch critical path can buy back the impact of write elongation, and sometimes leave you with improved elapsed times. For example where TC, SRDF or PPRC introduce a 100% write response time impact in a father-to-son update, but the input and output files are compressed to 40% of their original size. That's a net run time improvement of 20% due to IO reduction. Another example are datasets written or updated once, and then read by many programs. Even a reduction in size of only 40% results in a corresponding reduction in IO activity multiplied by the number of times the file is read. Using LZW compression means that there is only a small increase in CPU Time to decompress the file multiple times, usually around 15-20% of the CPU cost of compressing the file. The more you read the dataset, the more benefit you obtain. These are two examples where I have used DFSMS compression to make significant improvements to batch run time. The only hiccup was when IBM moved the compression assist instructions to firmware on the G3 CMOS processor (it may have been G4). They were back in the hardware by G6 and all the advantages of asymmetric CPU cost for compress/decompress returned. Huffman may not be an appropriate compression algorithm for this because the implementations I have experience with (e.g. DFSMShsm, DFSMSdss) have an equal cost for compress and decompress. The symmetrical CPU cost heavily impacts the value of a compressed input file. Ron > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of > Ted MacNEIL > Sent: Tuesday, July 06, 2010 1:41 PM > To: [email protected] > Subject: Re: [IBM-MAIN] VSAM Max Lrecl? > > >I'm a "results oriented" guy; formal proofs, elegant or otherwise, don't > "float my boat" anywhere near as well as concrete results that I can > quantify. > > I tend to agree with you; without the time to do an empirical study on > compression what do you have? > > I've never had a compressed file come out larger than the original input. > > I've heard of others that have, but have never seen it. > > And, I wrote a Huffman programme in 1977, as part of the same course that > introduced me to the theory that we're discussing. > > And, in the early days of BBS, COMPUSERVE, AOL, and the INTERNET, compression > was important due to bandwidth concerns. > > Just like it was when DASD was expensive. > On disk, I only use compression when a file is going to exceed its > architectural limit. > > Using it to save space (or bandwidth) is a waste of time, productivity, and > CPU. > > > - > I'm a SuperHero with neither powers, nor motivation! > Kimota! > > ---------------------------------------------------------------------- > 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 ---------------------------------------------------------------------- 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
