In the world of z/OS data transfer, milliseconds matter and every CPU cycle counts. Yet many organizations still rely on XCOM Data Transport’s original record-by-record transfer method.
It’s safe. It’s reliable.
And for today’s data volumes, the overall speed and resource requirements creates inefficiency.
If your XCOM transfers are stuck in the last millennium, here’s the 411 on the freshest way to transfer data. By enabling record packing, you may be able to dramatically increase throughput, reduce CPU consumption, and unlock the power of your zIIP processor, all without changing applications or redesigning workflows.
PACK=LENGTH with MAXPACK=1023000
It’s pretty simple; by modifying your configuration to change how XCOM prepares data for transport, you can instruct XCOM to pack records into large buffers instead of sending them individually. For all XCOM partner transfers you can use the following transfer options:
PACK=LENGTH
MAXPACK=1023000
These settings pack the data allowing XCOM to deal with packed buffers rather than discrete records, potentially dramatically reducing overhead.
- z/OS to z/OS transfers: When both partners support MAXPACK=1023000, XCOM can use Extra Large (XL) Record Packing for maximum throughput.
- z/OS to non-z/OS transfers: If the receiving partner supports a smaller MAXPACK (for example, 31744), XCOM automatically negotiates down, yet still delivers meaningful performance gains over record-by-record processing.
Why this is totally rad:
- Reduced CPU overhead: Packing hundreds or thousands of records into a single buffer greatly reducing the per-record processing costs
- Faster transfers: Fewer physical data sends result in shorter elapsed times, which is especially noticeable with large datasets
- Enables zIIP offload: For TCP/IP transfers, enabling PACK=LENGTH with a high MAXPACK value (for example, above 4096) is a prerequisite for offloading compression work to your zIIP engines, reducing general-purpose CPU consumption
Get Started in 3 Steps
1. Check if you’re already using XL Packing
Don't guess—check! You can use standard z/OS monitoring tools and utilities to inspect the features registered by XCOM to check if XL Packing is used.
Check the details using either:
- SYSVIEW FXE command
Vendor: Broadcom
Product: XCOM Data Transport
Function: XL Packing - FXEPRINT utility
//FEATREG1 EXEC PGM=FXEPRINT
//SYSPRINT DD SYSOUT=*
//SYSOUT DD SYSOUT=*,DCB=(LRECL=80)
//SYSIN DD DUMMY
Look for XCOM function name: “XL Packing”
Check both:
- XCOMJOB (used for TYPE=EXECUTE transfers)
- Your XCOM started task names (used for TYPE=SCHEDULE or remotely initiated transfers)
What to look for:
- “NotUsed”: XL Packing is available but not enabled
- “Used”: XL Packing is already active for some transfers
If it’s already active, review transfer logs to identify additional candidates that could benefit.
2. Enable XL Packing
Ensure all z/OS XCOM partners are running maintenance Level Set 12.0.03 (PTF LU16627) or later. This maintenance level includes:
- XL Record Packing
- Feature Registration Service integration for verification
By applying this maintenance Level Set, you’ll be able to leverage the XL Packing feature and use the Feature Registration Service Integration to verify you’ve enabled the optimization. For more information about Level Set 12.0.03, visit this link.
Once applied, you can enable packing at multiple levels for granular control:
To enable the best performance, ensure PACK=LENGTH is set in one of the following locations (listed in order of precedence):
- Transfer Request (SYSIN01): For individual transfers
- Execution Parameter (EXEC PARM): For specific started tasks or address spaces
- Destination Member: For all transfers going to a specific partner
- Global Configuration (CONFIG Member): When no value is specified for one of the above, XCOM defaults to the global configuration setting. Ensure the global PACK parameter is set correctly.
Note: The MAXPACK value sets the maximum possible packed block size and is negotiated down during the connection handshake to the capacity of the receiving partner. Ensure your receiving z/OS XCOM partner specifies the largest possible value, but you’ll need a value greater than 31744 to be considered as using XL Packing.
3. Understand the Tradeoff
What you gain:
- Faster transfers
- Lower CPU utilization
- Better zIIP efficiency
What it costs:
- Higher buffer storage usage
For most environments, the additional storage usage is a negligible tradeoff compared to the performance and CPU savings.
Beyond Packing: Compression Synergy
Once packing is optimized, you can layer in compression for additional gains.
- PACK=LENGTH improves compression efficiency
- Options like zEDC and zIIP offload minimize CPU impact
- Software compression (e.g. ZLIB) may increase CPU usage if not offloaded
Our recommendation is simple:
- Prioritize PACK=LENGTH with a high MAXPACK first
- Secondly, evaluate compression by adding COMPRESS=ZLIB where appropriate
Modern Data Volumes Need Modern Moves
Here’s the bottom line: If you’re still shuffling data one record at a time, you’re wasting CPU and leaving serious performance on the table.
It’s 2026. The party already left the building—and XCOM just showed up with the boombox.
Let’s stop moving data like it’s 1999.
Have questions about XL Packing or XCOM configuration?
Schedule a no-cost technical consultation with Broadcom Mainframe engineers and architects.