Units of work that run on the mainframe, at least those running on z/OS, are dispatched using two different types of control blocks: TCBs (Task Control Blocks) and SRBs (Service Request Blocks). It can be beneficial to understand these two types of control blocks, including how they are used, the differences between the two, and the implications of using each.
There are significant nuances to understanding how z/OS work is dispatched, but we will not go into those details in this article. We will simply define TCBs and SRBs at a high level to provide guidance on what types of workloads use each and what that means for your applications.
What is a Control Block?
The first step is to define what is meant by the term “control block.” Think of control blocks as storage areas used by the operating system for running tasks and processing data. At a high level, the work and resources of the system are managed by control blocks in z/OS.
Typically, application programmers do not need to know about control blocks, but they are used by z/OS behind the scenes for everything. On the other hand, systems programmers and Assembler programmers work with control blocks all the time.
We don’t want to get too “down in the weeds” here as this is just an introduction to control blocks. The main discussion here will focus on the two types of control blocks used by dispatchable units of work. The term “dispatchable” generally means something that can be passed on for further processing.
TCBs and SRBs
So, a dispatchable unit of work is a process that can be executed (that is, run) on the mainframe. And two types of control blocks can be used for dispatchable units of work:
• Task control blocks (TCBs) and
• Service request blocks (SRBs)
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, and most programs are. This means that there can be multiple TCBs associated with each address space, with potentially more than one task running in any one address space at any one time. So, TCBs are used when executing tasks for user programs and some system programs that support user programs.
An SRB, or Service Request Block, is typically used to communicate between address spaces. An SRB gets initiated by system code that is executing in one address space to perform a task impacting another address space. SRBs and TCBs are similar, but SRBs have some limitations.
Like a TCB, an SRB identifies a unit of work to the system, but an SRB cannot “own” storage areas. SRB routines can obtain, reference, use, and free storage areas, but a TCB must own those areas. Operating system facilities and vendor programs typically use SRB mode to perform certain performance-critical functions.
There are two types of SRBs based on whether the units of work being processed are preemptible or non-preemptible. A non-preemptible unit of work can be interrupted, but it must receive control after the interrupt is processed. So, if a routine is processed using a non-preemptible SRB and is interrupted, it will receive control back after the interrupt has been processed.
If a preemptible unit or work is interrupted, control returns to the operating system when the interrupt handling completes. This means that z/OS will decide what has to execute next. Most TCBs are preemptible, as are preemptible enclave SRBs.
At a high level, then, TCBs are used for application processes, and SRBs are typically used for system processes.
For example, if you have ever looked at a report from a Db2 performance monitor and reviewed the CPU times for the Db2 address spaces, you will see something that looks like this:
TCB TIME SRB TIME TOTAL TIME
CPU TIMES H:MM:SS.THTTH H:MM.SS.THTTH H:MM.SS.THTTH
———————— ————- ————- ————-
SYSTEM SRVCS ADDR SPC 00:00.15734 00:01.68555 00:01.84289
DATABASE SRVCS ADDR SPC 00:01.44904 00:01.27390 00:02.72294
IRLM 00:00.00000 00:00.03119 00:00.03120
DDF ADDRESS SPACE 00:00.04893 00:02.15467 00:02.20360
TOTAL 00:01.65532 00:05.14531 00:06.80062
Furthermore, additional lines will break out the preemptable SRB time for work that did and did not run on the zIIP engine. It is not my intent to dig deeper into this information only to show that you can report and view the work processed by your system on TCBs and SRBs.
And Now we zIIP to a Synopsis
So, all of the above offers a very high-level treatise on units or work, TCBs, and SRBs and how z/OS processes work under the covers. Knowing this information is crucial to help you properly take advantage of zIIP processors.
To run a process on a zIIP requires a preemptible enclave SRB. This is not the type of coding a typical application developer can just whip out. That is why taking advantage of zIIPs to offload work requires understanding the systems that support running workload using preemptible enclave SRBs. You usually will not see it phrased this way though. Instead, the system software (e.g., Db2, zCX, etc.), programming language (e.g., Java), or ISV software will talk about what aspects of its functionality are zIIP-eligible.
So take some time to evaluate your environment to determine how best to exploit zIIPs to reduce cost. Understanding what can run on zIIPs and how you can get more of your workload to run on zIIPs can benefit your bottom line!
For Additional Information about zIIP Eligibility, see these recent articles:
Types of Processing That Can Utilize ZIIPs & Why You Want to Use ZIIPs
