longpelaexpertise.com.au/ezine/CtBlksBeginners1.php?ezinemode=printfriend |
|
LongEx Mainframe Quarterly - November 2008
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:
- Getmain storage.
- Map the storage to your information using a COBOL copybook, Assembler macro
or C include.
- Decide how you're going to find the Control Block.
- 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:
- 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.
- 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.
- 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)?
- 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:
- 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.
- 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.
- 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.
- 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
|