On Wed, 10 Aug 2011 08:25:53 -0500, Chris Mason wrote: > > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1b990/5.44 > >Because compression is such a light-weight process - here a comparison with >the heavy-weight processes compaction or encryption is valid! - it has a very >small overhead. It causes a major reduction on the volume of data to be >"moved" when the data consists of reports with a lot of "white space" - let's >just say blank characters - and maybe lots of fancy lines of asterisks or >maybe just hyphens to assist with the presentation of arithmetical >calculations - that sort of thing. > Of course, these are parochial definitions of "compress" and "compact". Elsewhere in the data processing community (there is such an "elsewhere"), the publication you cite would hardly be taken as authoritative.
>You would be "stark, raving" to consider compressing anything other than text. >Text-rich text, a novel for example, would also be getting close to pointless. >As for "tersed" data - perish the thought! > FSVO (in a broader context than IBM's FTP) "compress" I just downloaded the Gutenberg Project's "Moby Dick" (a novel; arguably text-rich). The statistics: Compressed: 584,758 bytes Uncompressed: 1,231,344 bytes I'll fully agree (without trying the experiment) about "tersed" data. BTW, is "mode C" in an RFC nowadays? It's easy enough to find FTP clients that don't support it. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
