In our last installment of this series on IBM zIIP processors, we defined what is meant by zIIP eligibility. We took a look at specific types of workloads that IBM has made zIIP eligible. This post will dig a little deeper into what makes a workload eligible for running on zIIPs. And we will also take a look at why you would want to exploit zIIP processors for your workloads.
TCBs and SRBs
To fully comprehend what can and cannot run on a zIIP, we need to discuss TCBs and SRBs. Many Db2 DBAs and performance analysts first heard about TCBs and SRBs in an IBM performance class, but not everyone has taken one of those classes. And even for those of us who have, a refresh is probably in order.
For mainframe z/OS programs, code can execute in one of two modes: TCB mode, also known as task mode, or SRB mode. Most programs execute under the control of a task. Each thread is represented by a TCB or Task Control Block. A program can exploit multiple processors if it is composed of multiple tasks, as most programs are.
An SRB, or Service Request Block, is a control block that represents a routine that performs a particular function or service in a specified address space. SRBs are lightweight and efficient but have some limitations. Although an SRB is similar to a TCB in that it identifies a unit of work to the system, an SRB cannot “own” storage areas. SRB routines can obtain, reference, use, and free storage areas, but a TCB must own the areas. Operating system facilities and vendor programs typically use SRB mode to perform certain performance-critical functions.
In general, z/OS will dispatch Db2 work in TCB mode if the request is local or in SRB mode if the request is distributed. These parallel tasks are assigned the same importance as the originating address space.
Preemptable enclaves are used to do the work on behalf of the originating TCB or SRB address space. An enclave is a construct that represents a transaction or unit of work. Enclaves are a method of managing mainframe transactions for non-traditional workloads. You can think of an enclave as an anchor point for resource accumulation regardless of where the transaction is executing.
It is relatively easy to map the resources consumed to the actual transaction doing the consumption with traditional workloads. But with non-traditional workloads – web transactions, distributed processing, etc. – it is more difficult because the transaction can span platforms. Enclaves are used to overcome this difficulty by correlating more closely to the end user’s view of the transaction.
So even though a non-traditional transaction can comprise multiple “pieces” spanning many server address spaces and can share those address spaces with other transactions, the enclave gives you more effective control over the non-traditional workload.
Enclaves are grouped by common characteristics and service requests, and since they are preemptable, the z/OS dispatcher – and Workload Manager – can interrupt these tasks for more important ones. There are two types of preemptable SRBs: client SRBs and enclave SRBs.
From a Db2-perspective, if the request is distributed DRDA workload, then it will be executed in enclave SRBs. If the request is coming over a local connection, then it will be dispatched between TCBs, client SRBs, and in some cases enclave SRBs (such as for parallel queries and index maintenance).
An SVC, or a supervisor call instruction, is a processor instruction that directs the processor to pass control of the computer to the operating system’s supervisor program. Because zIIPS must run under an SRB, many commonly used z/OS services (used by TCBs) are not available; specifically, SVC calls other than ABEND. But we are getting deep into the weeds here, and these detailed nuances are more important for software engineers writing code for zIIPs than for those of us using them.
Why use zIIPs?
Let’s take a moment to circle back and answer the fundamental question: why should I use zIIPs? And the simple answer is cost reduction.
When work is redirected to, and then runs on, a zIIP instead of a general-purpose CP, that workload is not included in the MSU metrics for MLC software charges. Now that was a mouthful, so let’s make sure we understand what I’m talking about. First of all, I used the term MSU, which is an acronym for million service units. MSU has replaced MIPS (Millions of Instructions Per Second) as the standard measurement for mainframe capacity and consumption (see MSU versus MIPS). An MSU is a measurement of the amount of processing work that can be performed in an hour. One “service unit” originally related to an actual hardware performance measurement, but that is no longer the case; a service unit is an imprecise measurement. Nevertheless, IBM publishes MSU ratings for every mainframe model, so MSUs are used for modern mainframe capacity and workload measures.
The next term I mentioned without defining was MLC, which stands for Monthly License Charges. This refers to a specific category of mainframe software that is billed and paid for every month. Your organization will produce a report of each month’s consumption and submit it to IBM. This report dictates your IBM software bill, based on usage, for your IBM MLC products. Some of the most common MLC products include z/OS, DB2, CICS, IMS, MQSeries, and COBOL. Specific pricing and terms and conditions for IBM MLC products are based on the pricing metric in your IBM contract(s). There are more details behind the scenes, but this is a sufficient overview for now.
So, what does all of this mean? Well, the workload that gets run on zIIPs does not get counted on your monthly processing capacity, and therefore your software bill can be reduced, perhaps significantly, by using zIIPs. I’d be remiss if I did not mention that there is also a hardware cost reduction because a zIIP costs considerably less than a general-purpose CP, so when you use zIIPs to run workloads, they are being run at a reduced hardware cost.
An additional consideration on why you should use zIIPs is that, at times, they can provide a performance gain. Depending upon the type of mainframe you are using, the general-purpose CP may be kneecapped, meaning that its processing power is artificially constrained. But the zIIP(s) you add to your system are never kneecapped. Consequently, the workload redirected to the zIIP may outperform the same workload if it were to run on the general-purpose (kneecapped) CP.
There are many factors to consider when it comes to understanding zIIPs and determining why and how best to use them. But, once you do have a better understanding, you recognize they can play a valuable role in reducing or avoiding mainframe cost.
Craig Mullins, Copyright Craig Mullins Consulting, Inc
