DCMT DISPLAY STATISTICS SYSTEM contains a field “Number of Swaps”. This article explains SWAPS when using the IDMS zIIP feature.
Release: All supported releases.
A "SWAP" is the process of moving the CPU processing from a GP (General Processor) also referred to as (CP) to a zIIP specialty engine. The "SWAP" also occurs in the reverse process of moving CPU processing from the zIIP specialty engine to the general processor.
There are restrictions as to what code is allowed to run on a zIIP specialty engine. With respect to an IDMS online system, all "SYSTEM mode" support code is allowed to run on a zIIP specialty engine. This is basically the IDMS nucleus modules such as RHDCWAIT, RHDCSTGP, IDMSDBMS, etc. IDMS provided database procedures IDMSCOMP, IDMSDCOM, and PRESSPACK are also run on zIIP specialty engines.
The code that is not permitted to execute on a zIIP specialty engine is all user developed code. This would include ADS Dialog code, Cobol programs, PL/I programs, user written assembler, RHDCUXIT exits, other user written exits defined in IDMSUXIT, and non IDMS database procedures.
NOTE: As of 19.0 enhancement PTF SO06651, ADS dialogs can execute in SRB mode, making them eligible to run on the zIIP specialty engines. This is only available for release 19.0.
Other code that is not eligible to run on zIIP specialty engines is any code that issues an operating system SVC, physical I/Os, etc.
For the two categories of code that is not allowed to run on a zIIP specialty engine, the IDMS system must ensure that code is scheduled and run on the proper type of processor. To do this the IDMS system code will execute the code to "SWAP" to the correct processor as needed. There are a few actions sites can take to attempt to reduce the number of swaps that occur.
Obviously business requirements will dictate the need for these exits but if there is a way to stop using some or all it will help reduce the number of swaps.
The process of swapping affects performance in a couple of ways. There is the direct CPU cost of processing the swap on both the GP and zIIP specialty engines. The code involved in doing the swap does things like requesting the amount of CPU time used when exiting the current processor, as well as calls to the IBM Workload Manager which handles the scheduling and dispatching. Reducing the swaps therefore improves performance.
zIIP processing works best when the IDMS system is functioning primarily as a back-end database request server. For example, access to an IDMS back-end from an IDMS system that is acting as a TOR (Terminal Owning Region). A CICS system and applications that simply ship database requests to an IDMS back-end. IDMS Server related processing, as well as batch to CV jobs. All of these configurations are primarily only shipping database requests to the IDMS system, there is no user code involved (other than the possibility of exits and database procedures as discussed earlier). Some clients have reported as much as 97 percent of the GP CPU cycles being offloaded to the zIIP specialty engines using these configurations.
zIIP will also work for online systems running user written programs of any supported language as well as ADS. Because IDMS must perform the swaps back and forth as discussed these configurations will see less of a benefit but they still will achieve a reduction in the GP CPU cycles.