technical: Control Blocks for Beginners Pt 1: The Basics

In this two part series of articles, we talk about Control Blocks: what they are, what they're for, what to do with them, and how to do it.

Introduction

Systems Programmers, and in particular those that code in Assembler or read dumps, often seem to be talking about Control Blocks. But what are they, and what do you do with them? That's what this article is all about.

What is a Control Block?

It's a block of memory with information in it. z/OS Systems Programmers sometimes need to 'look under the hood' of z/OS and other systems software to see what's going on. Why?

• When analysing dumps. Control Blocks can tell a lot about what was going on when a dump was taken.
• When writing exits or programs that need to access and change z/OS information that isn't available elsewhere.

Applications programmers don't often need to know about Control Blocks - they usually have Application Programming Interface (API) calls that tell them what they need to know.

How to Create a Control Block.

Usually systems software creates and maintains Control Blocks. But there's nothing stopping any programmer from creating their own. All you have to do is:

1. Getmain storage.
2. Map the storage to your information using a COBOL copybook, Assembler macro or C include.
3. Decide how you're going to find the Control Block.
4. Release the storage when you're finished with it.

Working With Control Blocks

Imagine you're creating a new Control Block. You have four things to think about:

1. How will you find your Control Block? If you're using it in the same program, then there's no problem. However if other programs, or even address spaces, need to use it then you need a way to pass the address of the Control Block around. You've got a couple of choices:
• Pass the address in a parameter.
• Store the address in a user field in one of the z/OS Control Blocks. z/OS Control Blocks such as the SSCVT, CVT, TCB and ASCB all have one or more user fields that you can use. We'll talk more about these blocks in Part 2 of this series.
• Store the address in another Control Block you've created.
• Store the address using z/OS name/token services.
2. How will you enforce data integrity? If more than one task will want to update the Control Block, you need a way of guaranteeing its integrity - a locking mechanism. You can use the z/OS Compare and Swap instruction (or the C compare and swap function), use C pthreads, or use ENQ and DEQ services.
3. Where will the Control Block live? Will it be in private storage (great if your address space is the only one using it) or common storage (where everyone can access it)? Will it be in key 8 (available to everyone) or a system key (available to tasks running in the same key, or key 0)? Will it be storage protected (so only certain tasks can see it)?
4. How can you be sure that a piece of memory is really your Control Block? Many Control Blocks have an eyecatcher - a field with a set string (for example, the ASCB Control Block has the string 'ASCB' at the beginning of the Control Block). So programs can check this eyecatcher to check they are really looking at a Control Block, and not something else.

If you're just working with Control Blocks that have been already created, these issues are still important. Let's look at them again:

1. How will you find your Control Block? You have the same problem. Whoever created the Control Block will have solved this problem, giving you a way to hunt them down. You will be able to find this address by:
• Getting the address from another Control Block
• Getting it from a z/OS Name/Value pair. This only works if the creator has put the address in a z/OS Name/Value pair.
• Using an API. For example, the macro LOCASCB locates a specific ASCB Control Block address.
• You may already know it. If you're writing an exit or executing in a specific environment, you may be passed the address of your control block. For example, the PSA is always at address 0.
• If you're reading a dump, search for the Control Block's eyecatcher.
2. How will you enforce data integrity? If you haven't created the Control Block, the chances are that you don't know how data integrity is enforced. So there's one simple golden rule: don't mess with Control Blocks! Unless you are 120% certain you know what you're doing, just look without touching.
3. Where will the Control Block live? Some Control Blocks may be in a different address space, in a different key, or storage protected to prevent you accessing them.
4. How can you be sure that a piece of memory is really your Control Block? Back to the eyecatcher thing again.

How Do You Know What's Inside Them?

Control Blocks can contain anything. It's up to the creator to determine what's stored where. So how can you find out a Control Block's format? There's a couple of ways:

• Look it up in the manual. Many products like z/OS and CICS have Data Areas manuals. These manuals document many Control Blocks. They also document where they live, how you can find them, and even where the eyecatchers are.
• Look at other code that accesses Control Blocks. One excellent example of accessing all sorts of z/OS Control Blocks is Gilbert St Flour's SHOWMVS. This utility display all sorts of information about your z/OS system. You can find it (including the source) from the CBT tapes website at http://www.cbttape.org.
• Look at the mapping macro. z/OS, CICS, IMS and many other products provide High Level Assembler (HLASM) macros that map out their Control Blocks. If using macros, you may find it easier to read if you assembler the macro, and look at the assembler output.

How Do You Look At Them?

OK, how can you look at Control Blocks? Again, you have some choices:

• Perform a dump and use IPCS. IPCS is great for reading dumps. It also has a function that maps out some of the more common Control Blocks: CBFORMAT. To see how it works, go into IPCS and type:
  IPCS CBFORMAT 0. STR(PSA)
  This will show you the PSA Control Block. See the IPCS Commands Manual for more information on CBFORMAT, and what Control Blocks it supports.
• Look at your TSO address space's memory using IPCS. In IPCS, you set DEFAULTS to the name of your dump dataset (in the format DATASET('datasetname'). But if you set this to 'ACTIVE', you're looking at your TSO address space's memory.
• Use software. Software such as IBM TASID, BMC MAINVIEW, IBM Tivoli Omegamon or ASG-TMON give you a way of looking at storage. Some of these products (such as ASG-TMON) also provide facilities to locate and format Control Blocks.
• Write a program. We talk more about this in Part 2.

Summary

So, there you have the basics about Control Blocks. They're areas of memory that hold information - what they hold, and what format they are is set by the Control Block creator. There are some issues with creating and working with Control Blocks, and various ways to get at them.

Next issue, we'll talk about some specific Control Blocks, and look at some coding examples of how to look at them.

David Stephens

LongEx Quarterly is a quarterly eZine produced by Longpela Expertise. It provides Mainframe articles for management and technical experts. It is published every November, February, May and August.

The opinions in this article are solely those of the author, and do not necessarily represent the opinions of any other person or organisation. All trademarks, trade names, service marks and logos referenced in these articles belong to their respective companies.

Although Longpela Expertise may be paid by organisations reprinting our articles, all articles are independent. Longpela Expertise has not been paid money by any vendor or company to write any articles appearing in our e-zine.