Testing use of zEDC it has been observed that when a receiving server is configured MAXPACK=1023000, zEDC is not used for decompression unless the sending side also uses MAXPACK=1023000.
For tests conducted (trace files provided):
- the first ZLIB transfer was sent with MAXPACK=31744 and zEDC was used for compression on the sending side while software decompression was used on the receiving side.
- the second ZLIB transfer was sent with MAXPACK=1023000 and zEDC compression/decompression was used on both sides.
Release : 12.0
Component : XCOM Data Transport for z/OS
The observed behaviour is not related to the send/receive MAXPACK settings needing to be the same.
In the traces provided, the compressed data buffers vary between about 2500 - 2800 bytes each.
The XCOM code currently enforces a 4KB minimum to use zEDC, which is why the decompression process consistently is falling back to software instead of zEDC.
NOTE: It is not possible to influence the size of the compressed buffer very much. The size of the data before compression as well as the content of the data itself are the main factors that govern to what extent data gets compressed, and its resultant size.
XCOM Engineering has made a code change to reduce the 4KB limit to the hardware-enabled minimum of 1KB which is available in LU05222 ("REDUCE MINIMUM BUFFER REQUIREMENTS FOR ZEDC").
1. Documentation links:
XCOM™ Data Transport® for z/OS 12.0 > Administrating > Utilizing zEDC Hardware Accelerator
XCOM™ Data Transport® for z/OS 12.0 >Administrating > Best Practices > Using zEDC Data Compression
NOTE: PACK (PACK) and MAXPACK requirements
If the records are not packed zEDC may still be used. However, when the records are packed the 4KB threshold (1 KB with LU05222 installed) should be reached (at least on the sending side...) for every transfer. It also greatly increases the odds of reaching that threshold on the receiving side as well.
This should provide a significant performance boost and record packing is the single most significant performance boost that can be achieved for XCOM file transfers simply based on XCOM parameter selection.
2. For many of Engineering's tests in-house on R&D systems, the compressed output is less than 1KB . In those cases, the decompression ALWAYS falls back to the software, rather than zEDC. There is nothing that can be done about that unless IBM changes their interface. So some data may potentially be out-of-band for zEDC processing. That is strictly dependent on the actual data being compressed and how well it lends itself to compression.
There is nothing XCOM can do about that limitation and zEDC will NEVER be used for buffers that compress to < 1KB.
3. These messages should be expected in sending job logs and receiving XCOM log
A XCOMM0935I message indicating zEDC is available fo deflate (compression):
"XCOMM0935I zEDC hardware acceleration available for zlib deflate buffers >= VALUE", where VALUE would be 4K or 1K depending on whether or not LU05222 is installed.
A XCOMM0934I message with confirmation that zEDC is being used for deflate (compression) :
"XCOMM0934I zEDC hardware acceleration will be used for compression".
A XCOMM0935I message indicating zEDC is available for inflate (decompression):
"XCOMM0935I zEDC hardware acceleration available for zlib inflate buffers >= VALUE", where VALUE would be 4K or 1K depending on whether or not LU05222 is installed.
A XCOMM0934I message with confirmation that zEDC is being used for inflate (decompression) :
"XCOMM0934I zEDC hardware acceleration will be used for decompression".