As a new DBA or application developer, you may have many questions around the BIND command. What is it? Why is it necessary? Where do DBRM’s come from? What is a -805 SQLCODE and how do I fix it? At IDUG NA in Charlotte this year, I will be presenting a session entitled, “A15 – How You Can BIND Without Tying Yourself Up!” (currently scheduled to be held on Thursday June 6th at 9:30am, in the Carolina A room), where I hope to clear up much of this confusion.

The presentation will take the mystery out of the BIND command, discussing common issues with the command itself and sharing proven techniques to resolve them.

A BIND is a BIND is a BIND…or is it?

You can bind a PACKAGE, bind a PLAN, bind a SERVICE, or bind a QUERY. In my session, I will focus on BIND PACKAGE, with some information about BIND PLAN. These are the key types of binds that your development teams must use to prepare applications to execute SQL and, ultimately, access data on Db2 for z/OS.

You’ve probably seen job control language (JCL) to invoke a bind as part of the process of developing and deploying application code that executes SQL to access data on Db2 for z/OS. We will look at the details of the process and some of what is going on behind the scenes.

Untangling the Mysteries of BIND

During the presentation, I’ll be answering questions about the BIND command that I’ve received over the years, including:

1. Why Do I Need to Bind?
   If you have executed the BIND command, you have probably asked yourself that question. Why is there this extra step after coding a program? We will be discussing the mechanics of the BIND command and its JCL, as well as the inputs to and outputs of the bind process.
2. How Do I Bind a COLLECTION?
   A COLLECTION can be one of the more confusing concepts, so we will look at the different names associated with packages, collections, and plans, and clarify the naming conventions, which are a rich source of confusion.
3. What Can I Find in the Catalog?
   We will spend some time discussing the catalog tables and columns associated with packages and plans, and share some SQL you can use to extract information about your own Db2 applications from the catalog.

How Many Parameters Did You Say?

The Db2 12 documentation shows 66 separate parameters for the BIND command! Some of them even have sub-parameters. This is a very rich command, which is a polite way of saying it has a lot of complexity. How do you know which parameters are critical versus merely important? Which parameters can I learn about later, or as I need to? This session will help you to recognize the critical parameters that you must always get correct.

I’ll also talk about the parameters and rationale behind versioned packages and how to exploit this feature, as well as how they control Access Path Stability.

And whether you are able to attend IDUG or not, be sure to reach out to your BMC account team or a BMC Sales person to learn more about how BMC can help you manage your z/OS and Db2 environments to improve performance, raise productivity, and avoid risk.

Hope to see you at IDUG

There have been several high visibility data exposures in the news over the last year or so. As a Db2 DBA, one of your responsibilities is the protection of the data your business needs to run. Your auditors, internal and external, may be demanding action to protect your valuable Db2 data from prying eyes. None of us want the cost, potential fines, or negative publicity associated with a potential or real data exposure. IBM has provided a partial solution in Transparent Data EncryptionTM (or “TDE”) for Db2, which is part of a wider effort they call zSystem Pervasive EncryptionTM (or “zSPE”). Transparent Data Encryption provides a mechanism to encrypt your data at rest, on disk.

TDE has been provided for both Db2 11 and Db2 12. For Db2 12, there is additional function, which has been provided via Continuous Delivery as part of Function Level 502.

First, let’s look at the encryption mechanism itself, how it is implemented, and what you will need to deploy it. Encryption exploits a hardware instruction which is executed in an attached Crypto processor, to minimize the cost of the instruction. IBM decided to implement the feature in the media manager, which is a low-level access mechanism (part of DFSMS) used by BSAM, QSAM, VSAM, and by Db2. It is worth pointing out that this encryption technique does not support tape. z/OS allows three methods of enabling encryption; in priority order, these are: in a RACF dataset profile, as an attribute of the dataset (specified in JCL with DSKEYBL syntax or KEYLABEL in IDCAMS), and as an attribute in a SMS DATACLAS. To be encrypted, a dataset must have the Extended attribute. SMS encryption is available in z/OS 2.2 (if the PTF for APAR OA50569 has been applied) or z/OS 2.3. You will need the attached Crypto processor.

There is a misconception that a z14 is necessary to implement encryption. This is not true, but the Crypto 6-S processor is much faster than the Crypto 5-S, and the 6-S is available only on a z14. So, it is true that you need a z14 for acceptable performance of encryption (more on performance below).

Because encryption and decryption are done at I/O time, they are almost completely “transparent” to Db2. Tablespaces or indexes, or both, can be encrypted; the Db2 catalog and directory can be encrypted, as well as user data. You can also choose to encrypt the BSDS, active logs, archive logs (on disk), image copies, and utility work files. The first and third methods of enabling encryption for Db2 datasets are supported in both Db2 11 and 12. The second can be used for image copies and utility work files as early as Db2 11, but will be made available through DDL for Db2 data only in Db2 12 (as part of Function Level 502). Note that, after encryption has been enabled for a tablespace or index, the next Reorg of the object will encrypt the data.

The actual key to encrypt and decrypt the data is stored in the CKDS (“Cryptographic Key Data Set”). The key itself is system generated, but users access it through the key label, a 64 bit value used to access the actual key. Note that RACF (or equivalent) authorization is needed to access the key label, so to access an encrypted file, you must be authorized for the key label as well as the dataset itself. Be aware that, if you plan a disaster recovery test or to migrate data from one system to another, you must ensure that the CKDS datasets at both locations are synchronized.

Note that, because encryption is implemented in the I/O routines in Db2, the data is available in the clear in the buffer pool, and SQL sees only decrypted data. You may ask why you would want to implement encryption; the answer in most cases, I think, will be to placate your auditors. This feature will not prevent hacking attempts like SQL injection or password stealing for unauthorized SQL access, but it does further close the window against insider accesses to the disk data (bypassing SQL).

In Db2 12, IBM is providing DDL control of encryption as part of Function Level 502. This will allow you to specify “KEY LABEL” as part of the syntax of the CREATE/ALTER TABLE and the CREATE/ALTER STOGROUP commands. The TABLE syntax can be used only with single table tablespaces, and automatically enables encryption for associated indexes, LOB and XML spaces, and clones. Archive and history tables must be encrypted separately.

You may be curious about the overhead of encryption and decryption. There is some of course, since you are adding encryption to disk writes and decryption to reads, but it is not onerous. I recommend you run some tests in your environment to see how high your overhead is. It does raise the desirability of keeping data pages in the buffer pool (to avoid the overhead incurred during I/O). You need to be aware that utility execution will also cost more. The lower cost utility suite from BMC Software may be worth looking at, to help you offset some of the cost increase incurred with encryption.

There are many choices for Transparent Data Encryption, starting with whether to deploy it, and then choosing the technique to use. We recommend that you choose one method and use it consistently. That will avoid the confusion of figuring out conflicting specifications. Remember to check with third party vendors to see what level of support they provide for TDE. Please note that all of BMC Software’s Db2 products support the feature today; you can ask your BMC account team for details.

Talk to your BMC account team or a BMC Sales person about the use of BMC Next Generation Technology utilities, that can help you alleviate the costs associated with encryption. BMC provides full suites of performance, administration, and recovery tools for Db2 on z/OS.

As a follow-up to Phil Grainger’s post about zIIP offload, I thought it was worth spending a few moments to focus on the characteristics of code that can run on a zIIP as well as code that could suffer minimum performance loss if it was rewritten to run on a zIIP rather than a general purpose processor (GP).

IBM introduced the zIIP (system Z Integrated Information Processor) in 2006. IBM licenses zIIP hardware for a fraction of the corresponding charges for GPs. More importantly to you, zIIP processors are not counted in the basis for software charges, so you can see major savings by shifting workload from GPs to zIIPs. In addition, zIIP processors are run “at full speed,” so you can actually get more processing done in less time if your GPs are not full capacity models.

So why not simply replace every GP with a zIIP and save money on both hardware and software?

First, IBM has placed a restriction on zIIP usage. Originally, there could be no more than one zIIP per GP in a CEC, but some models now allow two zIIPs per GP. Second, IBM’s license agreement places restrictions on the kind of code that is eligible to run on a zIIP; the code must run in a z/OS enclave under the control of an SRB (service request block).

The use of an enclave means that the work is dispatched by z/OS Workload Manager (WLM). Code run from the enclave can be handled by a common set of WLM controls and policies because the code has a common set of characteristics. Scheduling an SRB instead of attaching a task control block (TCB) implies further restrictions; the most pertinent of these is that no SVC (except ABEND) can be issued, which prevents the use of many z/OS services commonly invoked by application programs. This has been misunderstood as “you cannot do I/O on a zIIP,” which is not true. However, it is true that QSAM and BSAM, which many application programs use to perform sequential file I/O, cannot be invoked from SRB code because they issue SVCs.

For completeness, we should mention “zAAP on zIIP,” by which IBM allows processes that are zAAP eligible to run on a zIIP in environments where there are no zAAPs. Very little legacy code fits this profile, but we are seeing more Db2 installations that are converting legacy COBOL applications to Java because programmers are easier to find than ones with COBOL skills. A side effect of this move is to render legacy applications to be zIIP eligible after they are rewritten into Java.

So why aren’t your mainframe vendors zIIP enabling all of the code in all their products? The answer gets back to the second restriction mentioned above – to be zIIP eligible, code must run under an SRB and therefore cannot invoke many z/OS services. Most existing product code was written to run in TCB mode. Historically, SRB mode code was used only where it was considered a cost effective way to do cross memory processing.

Let’s look at a hypothetical piece of code (part of a software product) that runs under a TCB today and makes no SVC calls. To make the code zIIP eligible, we must do something like the following each time we execute the code:

1. Set up the SRB in memory to point to the code to be executed.
2. Issue the IEAMSCHED macro to schedule the SRB for execution.
3. The originally executing TCB code must wait for the SRB code to execute.
4. When the SRB code completes, it must signal the TCB code to resume before terminating.

Alternatively, we could start the SRB once, then loop and wait in the SRB code instead of scheduling a new SRB each time the function is to be performed.

The overhead incurred in moving from TCB to SRB mode and back will incur a CPU cost. Vendors weigh the advantages of making code zIIP eligible with the CPU costs to determine what code will be most efficient for users.

Vendors should make their products zIIP eligible where feasible. They should focus on programs that are CPU intensive, don’t contain the z/OS services calls that cannot be made from an SRB, and don’t require much I/O. The programs must be executed often enough that the CPU savings on your GPs will be substantial.

While it would be nice if we could enable all of the code in every one of your z/OS software products to run on zIIP instead of GPs, that is unrealistic.

One last thing is that the license that allows third party vendors to zIIP-enable their code specifically prevents use of the license to zIIP enable OTHER code to run on a zIIP. So a vendor can zIIP-enable code they have written, but they could not write a tool to zIIP-enable a customer’s code.

I hope the information in this article will provide you with the information you need to discuss zIIP exploitation with your vendors.