search cancel



Article ID: 244576


Updated On:


XCOM Data Transport - z/OS


We have a user using XCOM to transfer large files with compression. Currently they make use of ZIIP and usage spiked very high. For internal reasons we now need to cap the available ZIIP capacity.

We ran a test to simulate this and determined the impact and the job ran 9x longer. We expected the job to use more General Processor MIPS to compensate when there are less ZIIP capacity available, we saw no increase in GP MIPS, but noted +-23% ZIIP wait time.

Can you please advice how XCOM uses ZIIP. If the ZIIP is not available, what does XCOM do? Will it reschedule workload to the GP, or will it wait until the ZIIP is available again and force workload to go on ZIIP only.




Release : 12.0

Component : XCOM Data Transport for z/OS


To use the ZIIP engine, XCOM uses an interface provided by Common Services that:
- Creates a unit of work suitable to be processed by ZIIP (a SRB and a WLM enclave)
- Uses a non-public IBM interface to ask WLM to run that unit of work in a ZIIP processor

XCOM does absolutely nothing when there is no ZIIP capacity available to process the requested workload. As a matter of fact, it is not aware of the situation as it only asks the system to run workload under ZIIP, but the main reason is that it's MVS and WLM who decide whether to move workload from specialty engines to regular processors when there is not enough capacity.

In the situation you describe, the default behavior is to move workload from ZIIP to regular processors instead of having the unit of work wait for availability of ZIIP. If this does not happen onsite, it must have been disabled by the system administrator, either globally for the whole system, or via WLM definitions.

The offload of ZIIP workload to regular processing may be disabled globally for the whole MVS by specifying IIPHONORPRIORITY=NO in member IEAOPTxx member in SYS1.PARMLIB library. The default is YES, which allows offload of workload from ZIIP to regular processors.

From the WLM side, this workload offload may be disabled by setting 'honor priority' attribute to NO  in the definition of the WLM service class which controls the unit of work, The default is to allow the workload to be offloaded. The service class is selected by the WLM classification rules.