DB2 11 for z/OS: Intermediate Training for Application Developers

Introduction

Welcome

Congratulations on your purchase of DB2 11 for z/OS: Intermediate Training for Application Developers.  This text book will help you learn the more challenging concepts and features of DB2 11 so you can master DB2 development as soon as possible.  You’ll receive instruction, examples and questions/answers to help you master the tools and techniques you need for day to day development work on a DB2 technical team.   

Assumptions:

While I do not assume that you know everything about DB2, I do assume a basic knowledge of development using DB2 11.  If you do not have a basic grounding in DB2 on the mainframe, then step back and start with my earlier book, DB2 11 for z/OS: Basic Training for Application Developers.  I assume that you have a working knowledge of the COBOL and/or PLI programming language which we will use for all the embedded SQL examples. All in all, I assume you have:

1.   A working knowledge of DB2 on z/OS.

2.   An intermediate level understanding of SQL, as well as a working knowledge of either the COBOL or PLI programming languages.

3.   Access to a mainframe computer running z/OS and DB2.

To maximize your chances of success as a DB2 11 developer on z/OS, I recommend that you acquire two things:

1.   Intermediate knowledge of DB2 11.

2.   Extensive experience with DB2 11.

Knowledge of DB2 11

We’ll briefly review the DB2 11 basics.  Then we’ll move on to the intermediate topics such as stored procedures, user defined functions, triggers, referential integrity, the various kinds of special tables in DB2, XML and finally performance evaluation and tuning.

Experience with DB2 11

Unless your shop has already upgraded to DB2 11, you may not have any experience with it.  My suggestion is to practice with whatever version of DB2 you have, and then put some extra study effort on the new features of DB2 11.  Once you are in an environment that uses DB2 11, this effort will pay off.

If you do not have access to a mainframe system through your job, I can recommend Mathru Technologies.  You can rent a mainframe account from them at a very affordable rate, and this includes access to DB2 (at this writing they offer DB2 version 10).  Their environment supports COBOL and PLI as well.  The URL to the Mathru web site is: 

http://mathrutech.com/index.html

Knowledge and experience.  Will that guarantee that you’ll succeed as an intermediate level DB2 application developer?  Of course, nothing is guaranteed in life.  But if you put sufficient effort into a well-rounded study plan that includes both of the above, I believe you have a very good chance of excelling in the DB2 world as an application developer and that you’ll have the technical skill set to lead a DB2 team.    

Best of luck!

Robert Wingate

IBM Certified Application Developer – DB2 11 for z/OS

CHAPTER ONE:  DB2 BASICS REFRESHER

We’ll spend a bit of time refreshing the basics of DB2 11.  This will give us a good take off point.  Also this information is good reference material for you in the future.  We’ll review DB2 Data Definition Language (DDL), Data Manipulation Language (DML) and Data Control Language (DCL). 

Data Definition Language

Before rushing into programming it is a good idea to understand data types, and then how to create and maintain the basic DB2 objects.   We’ll first look at the IBM supplied data types, as well as those you can define yourself.  Then we’ll look at the basic properties of the various objects (tables, indexes, views).  Finally we’ll look at the DB2 catalog and the information it provides.

IBM-supplied and user-defined data types

DB2 supports the following data types.  You should be familiar with all of these.  Comprehensive information about data types is available on the DB2 product documentation web site.  [i]

String data types

DB2 supports several types of string data: character strings, graphic strings, and binary strings.

CHARACTER(n)

Fixed-length character strings with a length of n bytes. n must be greater than 0 and not greater than 255. The default length is 1.

VARCHAR(n)

Varying-length character strings with a maximum length of n bytes. n must be greater than 0 and less than a number that depends on the page size of the table space. The maximum length is 32704.

GRAPHIC(n)

Fixed-length graphic strings that contain n double-byte characters. n must be greater than 0 and less than 128. The default length is 1.

VARGRAPHIC(n)

Varying-length graphic strings. The maximum length, n, must be greater than 0 and less than a number that depends on the page size of the table space. The maximum length is 16352.

BINARY(n)

Fixed-length or varying-length binary strings with a length of n bytes. n must be greater than 0 and not greater than 255. The default length is 1.

VARBINARY(n)

Varying-length binary strings with a length of n bytes. The length of n must be greater than 0 and less than a number that depends on the page size of the table space. The maximum length is 32704.

Numeric Data Types

DB2 supports several types of numeric data types, each of which has its own characteristics.

SMALLINT

A small integer is binary integer in the range of -32768 to +32767.

INTEGER or

INT

Large integers. A large integer is binary integer with a precision of 31 bits. The range is -2147483648 to +2147483647.

BIGINT

Big integers. A big integer is a binary integer with a precision of 63 bits. The range of big integers is -9223372036854775808 to +9223372036854775807.

DECIMAL or

NUMERIC

A decimal number is a packed decimal number with an implicit decimal point. The position of the decimal point is determined by the precision and the scale of the number. The scale, which is the number of digits in the fractional part of the number, cannot be negative or greater than the precision. The maximum precision is 31 digits.

DECFLOAT

A decimal floating-point value is an IEEE 754r number with a decimal point. The position of the decimal point is stored in each decimal floating-point value. The maximum precision is 34 digits.

REAL

A single-precision floating-point number is a short floating-point number of 32 bits. The range of single-precision floating-point numbers is approximately -7.2E+75 to 7.2E+75. In this range, the largest negative value is about -5.4E-79, and the smallest positive value is about 5.4E-079.

DOUBLE

A double-precision floating-point number is a long floating-point number of 64-bits. The range of double-precision floating-point numbers is approximately -7.2E+75 to 7.2E+75. In this range, the largest negative value is about -5.4E-79, and the smallest positive value is about 5.4E-79.

Date, time, and timestamp data types

DATE

A date is a three-part value representing a year, month, and day.

TIME

A time is a three-part value representing a time of day in hours, minutes, and seconds.

TIMESTAMP

A timestamp is a seven-part value representing a date and time by year, month, day, hour, minute, second, and microsecond.

XML data type

The XML data type is used to define columns of a table that store XML values. This pureXML data type provides the ability to store well-formed XML documents in a database.

Large object data types

You can use large object data types to store audio, video, images, and other files that are larger than 32 KB.

Character large objects (CLOBs)

Use the CLOB data type to store SBCS or mixed data, such as documents that contain single character set. Use this data type if your data is larger (or might grow larger) than the VARCHAR data type permits.

Double-byte character large objects (DBCLOBs)

Use the DBCLOB data type to store large amounts of DBCS data, such as documents that use a DBCS character set.

Binary large objects (BLOBs)

Use the BLOB data type to store large amounts of noncharacter data, such as pictures, voice, and mixed media.

ROWID data type

You use the ROWID data type to uniquely and permanently identify rows in a DB2 subsystem.

Distinct types

A distinct type is a user-defined data type that is based on existing built-in DB2 data types.  Here are a couple of examples:

CREATE DISTINCT TYPE

US_DOLLAR AS DECIMAL (9,2);

CREATE DISTINCT TYPE

CANADIAN_DOLLAR AS DECIMAL (9,2);

Default values for data types:

Data Definition Language Statements

Data Definition Language (DDL) is what we use to create, change and delete DB2 objects using the  CREATE, ALTER and DROP statements respectively.  We’ll look at the basic syntax of each of these with respect to particular objects.  

ALIAS

An alias is an alternate name for a table or sequence.

CREATE

Syntax:

CREATE ALIAS FOR

Example: 

Create an alias named WORKERS for the EMPLOYEE table owned by HRSCHEMA.

CREATE ALIAS HRSCHEMA.WORKERS FOR HRSCHEMA.EMPLOYEE;

ALTER

You cannot change an alias. The only thing you can do is to add a comment on it.  Here is the DDL for that:

COMMENT ON ALIAS HRSCHEMA.WORKERS IS 'EMPLOYEE ALIAS'

DROP

You can delete an alias using the DROP statement:

      DROP ALIAS HRSCHEMA.WORKERS

DATABASE

A DB2 database is a collection of objects including tablespaces, tables, indexes, views, triggers, stored procedures and sequences.  Generally a database is concerned with a single domain such as marketing, accounting, shipping and receiving, etc.  Within the database there are objects such as tables, indexes, views, etc. 

CREATE

You can create a database with the CREATE DATABASE statement and you can assign options such as bufferpool, index bufferpool, storage group and CCSID.  

Syntax:

CREATE DATABASE

Example:       

CREATE DATABASE HRDB2

STOGROUP DS1

BUFFERPOOL BP1

INDEXBP BP2;

ALTER

You can make changes to a database with the ALTER DATABASE statement.  

Syntax:           

ALTER DATABASE

Example:        

Change the default bufferpool to BP2.

ALTER DATABASE DB1

BUFFERPOOL BP2;  

DROP

You can remove a database by issuing the DROP command.

DROP DATABASE

TABLESPACE

You can create a tablespace and specify the associated database, storage group, locksize, bufferpool and other options.  The following example creates a large object (LOB) tablespace named TSEMP in database HRDB2 and with storage group SG00221.

CREATE

Basic Syntax:  

CREATE TABLESPACE

Example:

CREATE TABLESPACE TSEMP

IN HRDB2

USING STOGROUP SG00221

PRIQTY 52

SECQTY 20

ERASE NO

LOCKSIZE PAGE

BUFFERPOOL BP1

CLOSE YES;

ALTER

You can change the specifications of a tablespace using the ALTER command.

Basic Syntax:  

ALTER TABLESPACE

Example:

ALTER TABLESPACE TSEMP

LOCKSIZE ROW;

DROP

You can remove a tablespace by issuing the DROP command.

DROP TABLESPACE

TABLE

CREATE

You create a table using the CREATE TABLE command.   

Basic Syntax:

CREATE TABLE

(field specifications)

IN

Example:

CREATE TABLE EMPLOYEE(             

EMP_ID INT NOT NULL,               

EMP_LAST_NAME VARCHAR(30) NOT NULL,

EMP_FIRST_NAME VARCHAR(20) NOT NULL,

EMP_SERVICE_YEARS INT NOT NULL WITH DEFAULT 0,           

EMP_PROMOTION_DATE DATE,           

PRIMARY KEY(EMP_ID));

ALTER

You can change various aspects of a table using the ALTER command.  ALTER is often used to add an index or additional columns.  Two examples follow, the first adding a column to a table, and the second enabling a table for history.

ALTER TABLE HRSCHEMA.EMPLOYEE

ADD COLUMN EMP_PROFILE XML;

ALTER TABLE EMPLOYEE

ADD VERSIONING

USE HISTORY TABLE EMPLOYEE_HISTORY;

DROP

You can remove a table by issuing the DROP command.

DROP TABLE

Note:  You cannot drop a table for which a trigger is still defined.  You must first drop the trigger.

INDEX

CREATE

You create an INDEX using the CREATE INDEX command.

Basic Syntax:

CREATE INDEX

ON

Example:

CREATE UNIQUE INDEX

NDX_EMPLOYEE 

ON EMPLOYEE (EMP_ID);     

ALTER

You can make changes to an index using the ALTER INDEX command.

Basic Syntax:

ALTER INDEX

Example:

ALTER INDEX

DSN8A10.XPROJ1

BUFFERPOOL BP5;

DROP

You can remove an index by issuing the DROP command.

DROP INDEX

VIEW

CREATE

You can create a view using the CREATE VIEW command.

Basic Syntax:

CREATE VIEW

AS

SELECT

FROM

WHERE

Example:

CREATE VIEW HRSCHEMA.EMP_PROFILE_PAY      

AS                                      

SELECT                                  

A.EMP_ID,                               

A.EMP_LAST_NAME,                        

B.EMP_REGULAR_PAY                       

FROM HRSCHEMA.EMPLOYEE A, HRSCHEMA.EMP_PAY B

WHERE A.EMP_ID = B.EMP_ID;              

ALTER

In general views cannot be changed.  They must be dropped and recreated.  One exception is that you can regenerate a view from the existing definition.

Basic Syntax:

ALTER VIEW REGENERATE

Example:

ALTER VIEW HRSCHEMA.EMPLOYEE_HR REGENERATE;

DROP

You can remove a view by issuing the DROP command.

DROP VIEW

SEQUENCE

CREATE

You can create a SEQUENCE using the CREATE SEQUENCE command.

Basic Syntax:

CREATE SEQUENCE

START WITH

INCREMENT BY

NO CYCLE  

Example:

CREATE SEQUENCE HRSCHEMA.EMPSEQ    

START WITH 1                     

INCREMENT BY 1                   

NO CYCLE;

ALTER

You can change most of the options associated with a sequence, although you CANNOT change the data type.

Basic Syntax:

ALTER SEQUENCE

Example:

ALTER SEQUENCE HRSCHEMA.EMPSEQ    

INCREMENT BY 2                   

CYCLE;

DROP

You can remove a sequence by issuing the DROP command.

DROP SEQUENCE

TRIGGER

CREATE

You create a trigger using the CREATE TRIGGER command.

Example:

CREATE TRIGGER HRSCHEMA.TRG_EMP_PAY

AFTER UPDATE ON HRSCHEMA.EMP_PAY_X

REFERENCING OLD AS oldcol NEW AS newcol

FOR EACH ROW MODE DB2SQL

INSERT INTO HRSCHEMA.EMP_PAY_HST(  

EMP_ID,    

EMP_REGULAR_PAY,

EMP_BONUS_PAY,

AUDIT_DATE)

VALUES

(oldcol.EMP_ID,    

oldcol.EMP_REGULAR_PAY,

oldcol.EMP_BONUS_PAY,

CURRENT TIMESTAMP)

ALTER

You can change a trigger from being secured to unsecured or vice versa using the ALTER statement.  Example:

ALTER TRIGGER HRSCHEMA.TRG_EMP_PAY SECURED

ALTER TRIGGER HRSCHEMA.TRG_EMP_PAY NOT SECURED

DROP

You can remove a trigger by issuing the DROP command.

DROP TRIGGER

Characteristics and Properties of DB2 objects  

We’ve discussed the various types and properties for many objects including tables.  We’ll give a brief repeat plus some new information for other objects that we didn’t get too involved in yet.

Types of Tables

The table types are as follows.    

Types of Indexes

Indexes are of these types:

Unique index

Ensures that each row contains a unique value in the column upon which the index is built.

Primary index           

Indexes the primary key column of the table.  When you create a table and assign a primary key, you must create a unique index on the column before you can use the table.

Secondary index       

Depending on the context, a secondary index can mean one of the following two things:

An index that is not a partitioning index.

An index that is not a primary index.

Clustering index       

An index that forces a logical grouping by clustering the data based on a defined sequence.  A table can only have  one clustering index.

Expression-based index       

An index that is defined based on a general expression.

Partitioned index      

An index that is itself physically partitioned.

Partitioning index (PI)         

An index that corresponds to the columns that partition the table. These columns are called the partitioning key and are specified in the PARTITION BY clause of the CREATE TABLE statement.

Data partitioned secondary index (DPSI)  

A partitioned index that is not a partitioning index. These indexes are also called partitioned secondary indexes (PSIs).

Nonpartitioned secondary index (NPSI)    

An index that is not partitioned or partitioning. These indexes are also called nonpartitioned indexes (NPIs).

Multi-piece index      

A nonpartitioned index that has multiple data sets. The data sets do not correspond to data partitions. Use a multi-piece index to spread a large index across multiple data sets and thus reduce the physical I/O contention on the index.

XML index   

An index that uses a particular XML pattern expression to index paths and values in XML documents that are stored in a single XML column.

Types of views

View types are as follows:

F              SQL function

M             Materialized query table

V              View

As we conclude