IDMS IUA EIUA

Over the last few months, we received several inquiries asking for updated information about the utilization of zIIP processors within the CA IDMS® environment. This post provides a brief history of zIIP processing in CA IDMS and updated information for the current CA IDMS Version 19.0 delivery.

IBM introduced the zIIP (system Z Integrated Information Processor) in 2006. IBM hardware purchase costs for the zIIP processors are significantly lower than the corresponding charges for GP (General Purpose) processors. More importantly to the customer, zIIP processors are not included in the billable processing power, which is the basis for many software license fees. Mainframe customers can see major savings by shifting a portion of their mainframe computing workload from GP processors to zIIP processors.

The software must follow a specific set of rules set by IBM to utilize the zIIP processors. One of the key rules is the workload that is dispatched on a zIIP processor must be executed on a WLM SRB (Workload Manager Service Request Block). 

Additional rules include limitation of what types of processing are eligible to execute on a zIIP processor. For example, physical I/O (EXCP) processing is not eligible. To utilize zIIP processors, the executing program must be able to split its workload between operations that are executable on a zIIP and those that must execute on a general purpose (GP) processor. 

When zIIP processors were initially delivered by IBM, CA IDMS® utilized TCBs (Task Control Blocks) to execute the majority of its workload. Therefore, CA IDMS Version 16.0 (and earlier) could not exploit zIIP processors.  

CA IDMS exploitation of zIIP processors began with the delivery of CA IDMS for zOS Version 17.0. With Version 17.0, CA IDMS customers had the ability to exploit the IBM zIIP processors by offloading a portion of the CA IDMS-DC region workload to available zIIP processors. The CA IDMS region is the persistent address space that handles the majority of Data Communication and database requests for the CA IDMS user. By offloading part of the database request workload to zIIP processors, CA IDMS customers were able to improve the overall throughput of the IDMS address space while reducing GP CPU consumption.

To exploit zIIP processing in CA IDMS, the CA IDMS address space must be enabled using the JCL startup option “ziip=y” which enables the use of single Unitasking or multiple Multitasking processing TCBs to process the workload. Specifying “ziip=y” indicates that the WLM enabled SRBs are enabled to help with the workload. 

In the current implementation, SRB/TCB pairs are used to process the database request workload with eligible work processed on the WLM SRB (zIIP eligible). Non-eligible work is processed on the TCB (GP CPU). 

Note: If no zIIP processors are available in the system, or the zIIP processors are overloaded, the WLM SRB workload is re-directed to the GP processors for processing. This ensures that the workload completes as fast as possible on whatever processors are available.

With each CA IDMS delivery, zIIP offload improvements have been implemented to increase the percent of the database request workload that is eligible to run on the WLM SRBs of the IDMS REGION therefore increasing the zIIP offload capabilities.

For most sites, a ratio or percentage between zIIP CPU seconds consumed and GP CPU seconds consumed by the CA IDMS REGION address space is a simple way to represent the amount of zIIP offload that is occurring:

zIIP offload % = zIIP CPU seconds / (zIIP CPU seconds plus GP CPU seconds)

Using the above calculation, we estimate that the typical CA IDMS z/OS site with zIIP processors available can see CA IDMS REGION address space offloads of:

Release 17.0 – zIIP offload percentages 20-30%

Release 18.0 – zIIP offload percentages 40-50%

Release 18.5 – zIIP offload percentages 70-85%

Release 19.0 – zIIP offload percentages 75-91%

All CA IDMS system mode code processing is offloaded to the zIIP specialty engines. This is the code that supports the running of the CA IDMS system. User mode code is not eligible to be offloaded to the zIIP specialty engines. This would be the programs and application developed by the user as well as third party vendors. Other code that executes in the CA IDMS online region that is not eligible to be run on the zIIP specialty engines are user developed, User exits defined via RHDCUXIT, and other available exits created by users or third party vendors and defined via the IDMSUXIT module.

When non CA IDMS system code is given control the CA IDMS system must ensure that those entities do not get dispatched on the zIIP specialty engines. To do this, the CA IDMS system will swap from SRB mode (running on the specialty engine) to TCB mode (running on the GP or CP). When that non system mode code is finished and control is given back to the CA IDMS system it will once again swap back to SRB mode.

Due to this requirement of swapping, certain workloads will achieve higher zIIP offloads. Workloads where the CA IDMS system is acting as a backend to frontend system such as CICS, Batch to CV jobs, Server tasks. Conversely, when running user developed programs and applications, as well as other vendors’ products, DB procedures, and exits mentioned earlier will achieve a lower zIIP offload.  The zIIP offload for a given CA IDMS REGION can vary slightly depending on the workload that is processed (for example, day shift versus night shift, daily versus end of month).  

Another critical point to consider is that the zIIP offload percentage is directly affected by how well the CA IDMS REGION address space is tuned. CA IDMS REGION address spaces that utilize large buffer pools, memory cache (above the bar buffers, as well as Shared Cache in a Parallel Sysplex environment, all which have reduced physical I/Os, which results in higher zIIP offload eligibility.  CA IDMS REGION address spaces with smaller buffer pools.  

Possible techniques to improve zIIP

• Separate online processing into FE (TOR) /BE (AOR), ziip off on FE, ziip on in BE
• Apply all ptf/fixes asap

Viewing Statistics

Dcprofil:                               number of ziips available             

DCMT D STAT SYS             ziip CPU across all subtasks

Final note:  A large health insurance customer is realizing the following zIIP results in their CA IDMS environment:

• 98% of all CPU zIIP eligibility
• 100% zIIP eligible code offloaded
• 100% code offloaded to zIIP ran on zIIP
• Less than ¼ swap per task (based on over 100 million tasks/week)

For additional details about the exploitation of zIIP processing in CA IDMS, watch for future blogs on:

• Understanding CA IDMS® Symmetrical Multiprocessing and the IBM z Integrated Information Processor (zIIP)
• Measuring CA IDMS® Symmetrical Multiprocessing and the IBM z Integrated Information Processor (zIIP)