Why you need to know the difference between a TCB and an SRB

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
   ————————  ————-   ————-    ————-
   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

Digging Into the ZIIP: What Does ZIIP Eligible Mean?


Download cloudFrame Relocate Product Fact Sheet

Related Articles

Next Event

Recent Events