Just a thought, but anyone processing internally compressed CICS or
DB2 data on a non-z/OS platform (Windows/Unix) might see substantial
CPU usage from RLE decompression.
Michael
At 07:02 AM 4/17/2024, Scott Chapman wrote:
My recommendation has always been to leave Db2/CICS's RLE
compression of SMF data enabled even with zEDC compression of the data.
1) Less data will be sent to the zEDC compression engine, which will
then process faster. I believe at one point I had an IBM chart that
showed this.
2) The data might (likely) compress better because intervening
repeated values are removed before it goes through the zEDC
compression. (As Andrew shows below.) It might be dependent on the
data, but it makes some sense when you realize that LZ77 relies on
compressing in 32K blocks and by removing the duplicate zeros you
potentially get more interesting repeated data into that 32K block.
3) When the data is read back from the zEDC-compressed store to be
sent someplace for processing it will be smaller if the RLE
compression was enabled. Depending on what you're doing with the
data, that might be significant.
4) The RLE compression is extremely lightweight in terms of CPU. I
do not expect it to be noticeable: it's going to disappear in the
normal variation in CPU time seen for running the same work on any
shared system. The only CICS/Db2s that I would expect could have a
measurable increase in CPU would be those that are completely idle
and doing nothing but writing interval SMF records to say they
haven't processed any data.
Scott Chapman
On Wed, 17 Apr 2024 16:36:34 +1000, Andrew Rowley
<and...@blackhillsoftware.com> wrote:
>On 17/04/2024 12:09 pm, Michael Oujesky wrote:
>> Yes and zEDC poorly compresses internally RLE compressed records.
>
>I was surprised how well zEDC compressed the already compressed records.
>Using my data:
>
>zEDC alone : 52000 tracks
>
>CICS compression + zEDC : 22000 tracks
>
>zEDC seems to be biased towards speed rather than compression ratio, so
>maybe the RLE compression helps by packing more repeated bytes into
>whatever compression window zEDC uses?
>
>> Plus CSRCESRV uses GP engine cycles
>
>That's true - CPU is probably more expensive than storage, so this could
>be just an interesting side-track. On the other hand, I think zEDC has
>to decompress and recompress the data for SMF dump etc. so CICS
>compression might save some overhead for SMF housekeeping type
>operations, reducing the amount of data going through zEDC?
>
>--
>Andrew Rowley
>Black Hill Software
>
>----------------------------------------------------------------------
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
