Table Of Contents

1.

PURPOSE AND SCOPE OF THE DOCUMENT...................................................1

1.1.
1.2.

2.

USERS OF THE DOCUMENT...............................................................................1

ASSOCIATED DOCUMENTS................................................................................1

INTRODUCTION......................................................................................................2
2.1.
DATABASE MANAGEMENT SYSTEMS (DBMS)..................................................3
2.2.
TYPES OF DBMS............................................................................................. 4
2.2.1.
Relational DBMS......................................................................................4
2.2.2.
HIERARCHICAL DBMS...........................................................................6
2.2.3.
Net Work DBMS........................................................................................7
2.3.
SAMPLE DB2 DATABASE................................................................................... 8

3.

STRUCTURE OF DB2..............................................................................................9
3.1.
HIERARCHY OF DATA STRUCTURES..................................................................9
3.2.
DATABASES...................................................................................................... 9
3.3.
DB2 STORAGE GROUPS.................................................................................... 9
3.4.
TABLE SPACES.................................................................................................. 9
3.4.1.
Simple Tablespace.....................................................................................9
3.4.2.
Segmented Table Space.............................................................................9
3.4.3.
Partitioned Table Space............................................................................9
3.5.
TABLES............................................................................................................ 9
3.6.
INDEX SPACES.................................................................................................. 9
3.7.
INDEXES........................................................................................................... 9
3.8.
VIEWS.............................................................................................................. 9
3.9.
SYNONYMS...................................................................................................... 9
3.10. ALIASES........................................................................................................... 9
3.11.
DB2 CATALOG.................................................................................................. 9
3.12. DB2 DIRECTORY.............................................................................................. 9
3.13. ACTIVE AND ARCHIVE LOGS............................................................................9
3.14. BUFFER POOLS................................................................................................. 9

4.

DATA TYPES............................................................................................................39
4.1.
NUMERIC DATA.............................................................................................. 39
4.1.1.
Nulls........................................................................................................39
4.2.
STRING DATA.................................................................................................. 39
4.3.
CHARACTER FORMAT..................................................................................... 39
4.4.
DATE/TIME DATA........................................................................................... 39
4.5.
EQUIVALENT COBOL DECLARATIONS OF DATA TYPES....................................39

5.

SQL PROGRAMMING..........................................................................................49
5.1.
DDL STATEMENTS.......................................................................................... 51
5.1.1.
Create Database......................................................................................51
5.1.2.
Create Table Space..................................................................................51
5.1.3.
Create Table............................................................................................51
5.1.4.
Create View..............................................................................................51
5.1.5.
Create Index............................................................................................51
5.1.6.
Alter Table...............................................................................................51
5.1.7.
Drop........................................................................................................51
5.2.
DML STATEMENTS......................................................................................... 64
5.2.1.
Select.......................................................................................................64

Case Consult (India) Pvt. Ptd. 03/1998

/var/www/apps/conversion/tmp/scratch_2/303896757.doc

DB2 Fundamentals

5.2.2.
Joining Tables.........................................................................................64
5.2.3.
Sub Queries.............................................................................................64
5.2.4.
Union.......................................................................................................64
5.2.5.
Insert.......................................................................................................64
5.2.6.
Update.....................................................................................................64
5.2.7.
Delete......................................................................................................64
5.3.
CONTROL STATEMENTS................................................................................... 82
5.3.1.
Grant.......................................................................................................82
5.3.2.
Revoke.....................................................................................................82
5.3.3.
Commit....................................................................................................82
5.3.4.
Roll Back.................................................................................................82
6.

PROGRAM STRUCTURE.....................................................................................87
6.1.
HOST VARIABLES........................................................................................... 87
6.1.1.
Declaring Host Variables........................................................................87
6.2.
INDICATOR VARIABLES................................................................................... 87
6.3.
SQLCA.......................................................................................................... 87
6.4.
COBOL STRUCTURE OF SQLCA.....................................................................87
6.5.
SQLCA RETURN CODES................................................................................. 87
6.6.
SQLCA WARNINGS........................................................................................ 87
6.7.
IMPORTANT SQL CODES.................................................................................87
6.8.
STATIC SQL.................................................................................................... 87
6.9.
DYNAMIC SQL............................................................................................... 87
6.10. EXAMPLE FOR A DB2 APPLICATION PROGRAM...............................................87

7.

PROGRAM PREPARATION...............................................................................122
7.1.
STEPS IN PROGRAM PREPARATION................................................................122
7.2.
DCLGEN (DECLARATIONS GENERATOR )......................................................122
7.3.
PRECOMPILE................................................................................................. 122
7.4.
BIND............................................................................................................ 122
7.4.1.
Binding A DBRM To A Package............................................................122
7.4.2.
Binding An Application Plan................................................................122
7.5.
COMPILE AND LINKEDIT............................................................................... 122
7.6.
OVERVIEW OF DB2 APPLICATION PROGRAM PREPARATION AND EXECUTION
122
7.7.
ASSOCIATING LOAD MODULES AND PACKAGES............................................122

8.

SECURITY FEATURES.......................................................................................140
8.1.
PRIVILEGES................................................................................................... 140
8.2.
REFERENTIAL INTEGRITY.............................................................................. 140
8.2.1.
DB2 Enforcement Of Referential Integrity...........................................140
8.2.2.
Referential Integrity Enforcement Rules...............................................140
8.2.3.
Example For Referential Integrity Violation.........................................140
8.3.
DATABASE RECOVERY IN CASE OF FAILURE................................................140
8.3.1.
Unit Of Recovery...................................................................................140
8.3.2.
Data Recovery.......................................................................................140

9.

CONCURRENCY..................................................................................................157
9.1.
9.2.
9.3.
9.4.
9.5.

CONCURRENCY............................................................................................ 157
LOCKING STRATEGY..................................................................................... 157
LOCK SIZES AND TYPES...............................................................................157
ACQUIRE RELEASE PARAMETERS..................................................................157
ISOLATION PARAMETER................................................................................ 157

Case Consult (India) Pvt. Ptd. 03/1998

/var/www/apps/conversion/tmp/scratch_2/303896757.doc

ii

DB2 Fundamentals

10.
10.1.
10.2.
11.
11.1.
11.2.
11.3.
12.

DB2I (DB2 INTERACTIVE )..........................................................................167

DB2I............................................................................................................ 167
SPUFI.......................................................................................................... 167
UTILITIES.........................................................................................................171
LOAD........................................................................................................... 171
RUNSTATS..................................................................................................... 171
REORG.......................................................................................................... 171
ADVANCED DB2..............................................................................................179

12.1. MORE ABOUT INDEXES................................................................................. 179

12.1.1.
Example Of An Index............................................................................179
12.1.2.
Clustered Indexes..................................................................................179
12.1.3.
Non Clustered Indexes..........................................................................179
12.2. SPECIAL REGISTERS...................................................................................... 179
12.3. MORE ABOUT LOCKS.................................................................................... 179
12.3.1.
Modes Of Table And Tablespace Locks.................................................179
12.3.2.
Modes Of Row And Page Locking........................................................179
12.3.3.
Lock Mode Compatibility Of Table And Table Space Locks.................179
12.3.4.
Lockmode Compatibility Of Row And Page Locks...............................179
12.4. INVOKING ONLINE UTILITIES........................................................................179

Case Consult (India) Pvt. Ptd. 03/1998

/var/www/apps/conversion/tmp/scratch_2/303896757.doc

iii

DB2 Fundamentals

1.

Purpose and Scope of the Document

The Purpose of this document is to train fresh Software Engineers who would like to get
familiarized with DB2 and as a reference material for application programmers.
1.1.

Users of the Document

This document is intended for database designers, database application programmers,

students and teachers and more generally anyone who wishes to broaden his or her
knowledge of the database, DB2.
1.2. Associated Documents
No associated documents

2.

Introduction

DB2 ( IBM DATABASE2 ) is a highly successful relational database management system.

DB2 enables its users to create, update and control relational database using
STRUCTURED QUERY LANGUAGE (SQL). Designed to meet the needs of small and
large business alike, DB2 is available on a number of platforms. we will be dealing with
DB2 on MVS.
RISC SYSTEM/6000

DB2 FOR
OS/2

DB2 FOR
AIX

DB2 FOR
HP-UX

DB2 FOR
SOLARIS

DB2 FOR
WINDOWS /NT

DB2 FOR
SINIX

DB2 FOR
MVS
DB2 FOR
VSE & VM

DB2 FOR
OS/400

2.1.

Database Management Systems (DBMS)

DATABASE MANAGEMENT SYSTEMS deal with the problem of storing and

retrieving large amounts of data. DBMS provides an environment to share data among its
users. Preserving the correctness of data and restoring the database in failure are major
concerns for DBMS.

DBMS
DATABASE
APPLICATION

QUERY

PROGRAM

PROCESSOR

STORAGE MANAGER

DATA

DBMS CONSIST OF DATA, HARDWARE, SOFTWARE AND USERS

BENEFITS OF DBMS ARE
REDUCE REDUNDANCY

AVOID INCONSISTENCY
SHARE DATA
MANIPULATES DATA EFFICIENTLY
FAULT TOLERANT
DATA INDEPENDENCE

2.2.

Types Of DBMS

Depending on data models used, database management systems are mainly divided into
three.
RELATIONAL DBMS
HIERARCHICAL DBMS
NETWORK DBMS

2.2.1. Relational DBMS

DB2 is based on relational data model which was formulated by DR. E.F CODD in 1970.
Relational systems have their origin in the mathematical theory of relations. Using relational
data model , IBM developed DB2 in 1983.
A RELATIONAL SYSTEM IS A SYSTEM IN WHICH
THE DATA IS PERCEIVED BY THE USER AS TABLES
QUERIES ARE USED TO EXTRACT DATA FROM THE DATABASE.
ALL DATA VALUES ARE ATOMIC. ie EVERY ROW AND COLUMN
POSITION CONTAINS ONLY ONE DATA VALUE; NEVER A LIST OF
VALUES
EXAMPLE OF RELATIONAL DBMS IS DB2
SAMPLE DATABASE FOR COMPARING DIFFERENT DBMS
TABLE S
S#

TABLE SP

SNAME

S1
S2
S3

SMITH
JONES
BLAKE

STATUS
20
10
30

CITY
LONDON
PARIS
PARIS

TABLE P
P#

PNAME

COLOR

P1
P2
P3
P4

NUT
BOLT
SCREW
SCREW

RED
GREEN
BLUE
RED

WEIGHT
12
17
17
14

CITY
LONDON
PARIS
ROME
LONDON

S#

P#

QTY

S1
S1
S1
S2
S2
S3

P1
P2
P3
P1
P2
P2

300
200
400
300
400
200

 TABLE S represents SUPPLIERS. Each supplier has a unique SUPPLIER NUMBER

(S#), a SUPPLIER NAME (SNAME), a RATING (STATUS) and a LOCATION OF
THE SUPPLIER (CITY).
TABLE P represents PARTS. Each kind of part has a unique PART NUMBER (P#), a
PART NAME (PNAME), a COLOUR (COLOR), a WEIGHT (WEIGHT) and a
location where the PART IS STORED (CITY).
TABLE SP represents SHIPMENTS. It connects other two tables. It REPRESENTS a
shipment of parts of kind P1 by the supplier called S1 and the shipment quantity.
In a relational data model TABLES are called RELATIONS, ROWS are called
TUPLES and COLUMNS are referred as ATTRIBUTES.
In a relational data mode association of ROWS of different TABLES are done using
COLUMN VALUES of common columns.
DB2 relates TABLE S and SP using the COLUMN SUPPLIER NUMBER(S#).
TABLE P and SP are related using the COMMON attribute PART NUMBER (P#).
TABLES S and P are related using COLUMN (CITY)

2.2.2. HIERARCHICAL DBMS

Hierarchical View Of Supplier And Parts Database
In hierarchical database suppliers, parts and shipments are different databases
SUPPLIERS DATABASE

PARTS DATABASE

S1

P1
S2

..

SMITH

NUT

JONES
20

RED

12

LONDON

10
LONDON

SHIPMENTS DATABASE
PARIS

SHIPMENT
SEGMENT

LCHILD

In this view data is represented by a simple TREE STRUCTURES and DBMS links
these data bases using pointers.
The user sees three individual trees for supplier database, each tree has a parent
supplier. Each tree can be called a supplier record occurrence. Similarly you can see
part record occurrence and shipment record occurrence.
Shipment database contains the shipment quantity. The logical child of shipment
database consists of supplier number , part number and pointers to corresponding
databases .Similarly the supplier and parts databases also contains logical child which
points to the shipment database. Now the user can access shipment from supplier and
part databases. Similarly parts and supplier databases are also accessed from shipment
database
IMS (Information management system) is an example of Hierarchical DBMS

2.2.3. Net Work DBMS

SUPPLIER
RECORD SET

PART RECORD
SET

S1 SMITH..

P1 NUT ..

S2 JONES..

P2 BOLT.

QUANTITY RECORDS
300
400
.

NETWORK DBMS consists of owner databases and member databases. The member
database can be accessed only via the owner database.
In the example there are two owners for a member database. Supplier and part record
sets are owners of shipment record set. Using this database the user can access the
shipment of a particular part by a specific supplier
The supplier S1 supplies part P1 of quantity 300. From the supplier S1 there is a
pointer towards the supplied quantity and another pointer connects this to the
corresponding part. An owner can have more than one pointer towards different
quantities.
Example of network database is IDMS(Integrated database management system)

2.3.

Sample Db2 Database

The sample database consists of THREE tables and these tables are used through out this
book.
TABLE S

TABLE SP

S#

SNAME

STATUS

S1
S2
S3
S4
S5

SMITH
JONES
BLAKE
CLARK
ADAMS

20
10
30
20
30

TABLE P
P#

PNAME

P1
P2
P3
P4
P5
P6

NUT
BOLT
SCREW
SCREW
CAM
COG

CITY

P#

QTY

S1 P1
PARIS
S1 P2
200
PARIS
S1 P3
400
LONDON
S1 P4
ATHENS
S1 P5
S1 P6
S2 P1
S2 P2
S3 P2
COLOR WEIGHT
CITY
S4
P2
S4
P4
RED
12
LONDON
S4
P5
GREEN
17
PARIS
BLUE
17
ROME
RED
14
LONDON
BLUE
12
PARIS
RED
19
LONDON

300

LONDON

S#

200
100
100
300
400
200
200
300
400

TABLE S represents SUPPLIERS. Each SUPPLIER has a unique SUPPLIER

NUMBER (S#), a SUPPLIER NAME (SNAME), a RATING (STATUS) and a location
of the SUPPLIER (CITY). PRIMARY KEY IS S#.
TABLE P represents PARTS. Each kind of part has a unique PART NUMBER (P#), a
PART NAME (PNAME), a COLOUR (COLOR), a WEIGHT (WEIGHT) and a
LOCATION where the PART IS STORED (CITY).
PRIMARY KEY IS P#
TABLE SP represents SHIPMENTS .It connects other TWO TABLES .It represents a
SHIPMENT of PARTS OF KIND P1 by the SUPPLIER called S1 and the SHIPMENT
QUANTITY. For a given SHIPMENT the combination of S# and P# is unique .That is
the PRIMARY KEY is the COMBINATION of the above mentioned and the
FOREIGN KEYS ARE S# AND P#

3.

Structure Of DB2

This chapter deals with the definitions and examples of objects present in DB2.The topics
included in this chapter are
3.1.

Hierarchy Of Data Structures

3.2.

Databases

3.3.

DB2 Storage Groups

3.4.

Table Spaces

3.4.1. Simple Tablespace

3.4.2. Segmented Table Space
3.4.3. Partitioned Table Space
3.5.

Tables

3.6.

Index Spaces

3.7.

Indexes

3.8.

Views

3.9.

Synonyms

3.10. Aliases
3.11.

DB2 Catalog

3.12. DB2 Directory

3.13. Active And Archive Logs
3.14. Buffer Pools

STRUCTURE OF DB2

THE ELEMENTS OF DB2 ARE DIVIDED INTO

TWO BROAD CATEGORIES
DATA STRUCTURES

SYSTEM STRUCTURES

DATA STRUCTURES CONTAIN USER DATA AND ARE ACCESSED

UNDER USERS DIRECTION.
SYSTEM STRUCTURES ARE CONTROLLED AND ACCESSED BY DB2
DATA STRUCTURES CONSIST OF
DATABASES
DB2 STORAGE GROUPS
TABLE SPACES
TABLES
INDEX SPACES
INDEXES
VIEWS
SYNONYMS
ALIASES
SYSTEM STRUCTURES MAINLY CONSIST OF

DB2 CATALOG
DB2 DIRECTORY
ACTIVE AND ARCHIVE LOGS
BUFFER POOLS

HIERARCHY OF DATA STRUCTURES

DATABASE D1

STORAGE GROUP
G1

TABLE SPACE S1
TABLE T1

TABLE T2

VOLUME 1
(DASD)

INDEX X1
VOLUME 2
(DASD)
INDEX X2

PARTITIONED
TABLESPACE
S2

TABLE T3
PART 1
TABLE T3
PART 2

STORAGE
GROUP G2
VOLUME2
(3380)

PARTITIONED INDEX X3
PART 1
PARTITIONED INDEX X3
PART 2

Hierarchy Of Data structures

The total collection of stored data is divided into a number of disjoint databases. They
are USER DATABASES and SYSTEM DATABASES.
Each database is divided into a number of disjoint spaces, that is several
TABLESPACES and INDEX SPACES. A space is a dynamically extendible collection
of PAGES, where PAGE is a block of physical storage.
Each table space contains one or more stored tables. A stored table contains a set of
stored records. A given stored table must be wholly contained within a single table
space.
Each INDEXSPACE contains exactly one index. A given index must be wholly
contained with in a single index space. A given stored table and all of its associated
indexes must be wholly contained within a single DATABASE.
Each space (TABLE SPACE or INDEX SPACE) has an associated STORAGE
GROUP. When a space needs to be extended, storage is acquired from appropriate
storage group.

DATA BASES
DATABASE1

TABLESPACE1
INDEX 1

TABLE 1

TABLE 2

INDEX 2

TABLESPACE 2

DATABASE IS A COLLECTION OF A NUMBER OF TABLE SPACES ALONG

WITH A SET OF INDEX SPACES

A STORED TABLE AND ALL OF ITS ASSOCIATED INDEXES MUST BE IN A

SINGLE DATABASE

WHEN YOU

CREATE A TABLESPACE OR TABLE AND DO NOT SPECIFY

THE DATABASE THE OBJECT WILL BE CREATED IN THE DEFAULT
DATABASE DSNDB04

DB2 STORAGE GROUPS

STORAGE GROUP 1

VOLUME 1

VOLUME 2

USER AND SYSTEM DATABASES ARE PHYSICALLY STORED IN THE

DATASETS OF SPECIFIED STORAGE GROUPS
STORAGE GROUP IS A SET OF VOLUMES OF DIRECT ACCESS STORAGE
DEVICES(DASD).
PARTS OF SINGLE DATABASE CAN BE STORED IN DIFFERENT
STORAGE GROUPS
DEFAULT STORAGE GROUP IS SYSDEFLT

TABLE SPACES

TABLESPACE 1
TABLE 1
TABLE 2

SIMPLE

SEGMENTED

PARTITIONED

TABLESPACE IS MADE UP OF ONE OR MORE VSAM LINEAR DATASETS

(LDS ), WHERE ONE OR MORE TABLES ARE STORED.
A TABLE SPACE IS DIVIDED INTO 4K OR 32K PAGES.
A PAGE IS A UNIT OF I/O TRANSMISSION.
A PAGE MAY CONTAIN ONE OR MORE ROWS (MAX 127).
A ROW MUST LIE WITHIN A PAGE.

Table Spaces
A TABLE SPACE can be thought of as a logical address space on secondary storage that is
to hold one or more stored tables. Table spaces are divided into equal sized units called
PAGES which are written or read from DASD. Tables are physically stored in one or more
VASM linear datasets.
A table space can consists of 1 to 64 VSAM datasets which can together contain up to 64
GIGABYTES of data. When you create a table space you can specify the database and
storage group to which the tablespace belongs and table space type. As the amount of data
in tables grow storage will be acquired from appropriate storage groups and added to the
tablespace.
Fundamentally the table space is a storage unit for recovery and reorganization. If the table
space is very large the RECOVERY and REORGANIZATION could take a long time.
Hence making the tablespace simple, segmented, or partitioned can drastically affect the
performance.

SIMPLE TABLESPACE

SIMPLE TABLESPACE
FREE
PAGE
FREE
SPACE

4K
PAGE
RECORD OF TABLE 1
RECORD OF TABLE 2

SIMPLE TABLESPACE CONTAINS ONE OR MORE TABLES

RECORDS OF DIFFERENT TABLES ARE STORED IN AN INTERLEAVED
MANNER.
IMPROVE ACCESS TIME FOR LOGICALLY RELATED DATA

Simple Tablespace
In simple table space records of tables are interleaved .Records of different tables may be
present in a single page and to find all rows of a table a scan of the whole table space is
needed. But by loading the data in an appropriately interleaved manner; accessing logically
related data will be more efficient.
If a table is dropped, its rows are not deleted. The space occupied by the rows does not
become available until the table space is reorganized. All tables in a simple table space must
reside in the same user-defined data set or in the same storage group.
one stored table per table space is always the most satisfactory arrangement in the case of
simple TABLE SPACE.

SEGMENTED TABLESPACE

SEGMENT1

SEGMENT2
4K
PAGE

SEGMENT3

TABLE SPACE HAVING A SEGMENT SIZE 4

RECORD OF TABLE 1
RECORD OF TABLE 2

TABLE SPACE IS DIVIDED INTO A NUMBER OF SEGMENTS.

RECORDS OF DIFFERENT STORED TABLES ARE NOT INTERLEAVED IN
A SINGLE SEGMENT.
A SEGMENTED TABLE SPACE CAN CONTAIN ONE OR MORE TABLES.
SEQUENTIAL ACCESS TO A PARTICULAR TABLE IS MORE EFFICIENT.

Segmented Tablespace
In a SEGMENTED TABLESPACE the tablespace is divided into segments and each
segment consists of a logically contiguous set of N PAGES. N must be a multiple of 4 in
the range 4 TO 64 and is same for all segments in the table space. The size of the segment
is specified while creating the tablespace.
Each segment in the segmented tablespace contains rows from only one table. But the
tablespace can contain multiple tables, in different SEGMENTS. In order to find a row, it is
not necessary to scan the entire table space, but only the segments that contain the table.
Hence sequential access to a particular table is more efficient.
If a table in a segmented table space is dropped, the space for that table can be reused
without performing a reorganization of the table space.
A segmented table space can have between 1 AND 32 VSAM linear data sets. the
maximum size of a data set in the segmented table space is 2 GIGABYTES and so, the
maximum size of a segmented table space is 64 GIGABYTES .

PARTITIONED TABLESPACE

AF

PARTITION1

GP

PARTITION2

QZ

PARTITION3

RECORD OF TABLE 1

A PARTITIONED TABLESPACE CAN CONTAIN ONLY ONE TABLE.

EACH PARTITION CONTAINS A PART OF ONE TABLE.
THE PARTITIONS CAN BE INDEPENDENTLY ASSIGNED TO DIFFERENT
STORAGE GROUPS.
IMPROVED DATA AVAILABILITY AND QUERY RESPONSE TIME.

Partitioned Tablespace
PARTITIONED TABLESPACES are intended for stored tables that are sufficiently large.
Partitioned table contains exactly one stored table, partitioned in accordance with value
ranges of a particular column or column combination .
A partition can be 1, 2, OR 4 GIGABYTES in length, depending on the number of
partitions contained in the entire table space. If only one partition is defined on the table
space, then its MAXIMUM SIZE IS 4 GIGABYTES.
Partitioning a table space provides several advantages for large tables. When DB2 scans
data to answer a query it can scan through partitions simultaneously instead of scanning
through the entire table from the beginning to end.
A utility can work on all partitions simultaneously instead of working on one partition at a
time. Also, different utilities can work on different partitions simultaneously. This can
significantly reduce the amount of time needed for a utility to finish.

TABLES

TABLE S
KEY
S#
ROWS

S1
S2
S3
S4
S5

COLUMNS
SNAME
SMITH
JONES
BLAKE
CLARK
ADAMS

STATUS
20
10
30
20
30

CITY
LONDON
PARIS
PARIS
LONDON
ATHENS

A RELATIONAL DATABASE STORES DATA IN THE FORM OF TABLES.

TABLE CONSISTS OF A NUMBER OF RECORDS.
RECORD CONTAINS COLUMNS, ROWS, KEYS etc.
EACH RECORD SHOULD BE CONTAINED IN A SINGLE PAGE BUT A
TABLE CAN BE SPREAD OVER PAGES.

VIEWS

BASE TABLE AS IT EXISTS

STORAGE

VIEW AS THE PROGRAMS

LOGIC SEES IT.

TABLE S

VIEW

S# SNAME STATUS CITY

S#

STATUS

CITY

A VIEW CAN INCLUDE ALL OR SOME OF THE COLUMNS FROM ONE OR

MORE BASE TABLES
VIEWS ARE CREATED FOR BASE TABLES
COMBINATION OF VIEWS AND TABLES.

OR

VIEWS

OR A

VIEWS ARE LOGICAL REPRESENTATION OF DATA THAT EXISTS IN

BASE TABLES.
VIEWS ARE USED FOR SIMPLICITY AND SECURITY.

Views
A VIEW is a named table that is represented, not by its own physically separate,
distinguishable stored data, but rather by its definition in terms of other named tables.
VIEWS are created for base tables or views or a combination of views and tables.
When you define a view DB2 stores the definition of the view in the DB2 catalog. Data is
physically present in base tables only and not in views. When a view is accessed then data is
dynamically retrieved from the base table.
Advantages Of Views
1. They provide a certain amount of logical data independence in restructuring the
database
2. They allow the same data to be seen by different users in different ways.
3. Automatic security is provided for data that is present in the base table by creating a
view in which sensitive data is not visible.

INDEX SPACES
INDEX SPACE 1

INDEX 1

ONLY ONE INDEX IS STORED IN AN INDEX SPACE

INDEX SPACE IS AUTOMATICALLY CREATED WHEN THE
CORRESPONDING INDEX IS CREATED.
PAGES IN AN INDEX SPACE ARE 4K BYTES IN SIZE.
INDEX SPACE FOR PARTITIONED TABLESPACE ARE PARTITIONED.

INDEX

INDEX 1
RID

VALUE

PAGE P

INDEX CONSISTS OF TWO PARTS ,RECORD ID (RID) AND INDEXED

VALUE.
A TABLE CAN HAVE ANY NUMBER OF ASSOCIATED INDEXES.
INDEXES ARE USED TO IMPROVE PERFORMANCE AND IN SOME CASES
TO ENSURE UNIQUENESS.
IN THE EXAMPLE INDEX IS USED TO FIND A RECORD (T) IN PAGE P.
DB2 DETERMINES WHETHER TO USE AN INDEX OR NOT

Indexes
An index contains values from one or more of a tables columns and a pointer to the record
in a data which matches the index value. DB2 will find data more efficiently by scanning the
index and following the pointer than by scanning the entire tablespace.
Record ID of index has two parts. First part is to identify the page where the record lies
and the second part is the byte offset from the bottom of the page identifying the record.
Index is structured in ascending or descending sequence on one or more columns. A given
value of interest can be located quickly in the index because of their ascending or
descending structure.
An index created on a table in a partitioned table space is a partitioned index and is divided
into multiple index spaces.
Indexes are of two types, unique and non unique indexes. A non unique index can reference
duplicate values, a UNIQUE INDEX will not. You can create an index any time after you
create the table. But creating an index before loading the data provides significant
performance advantages.
Indexes can be clustered or non clustered. A clustering index is one in which the records are
physically stored in data pages in the sequential order of their index values. The index is
used to control physical placement of the indexed records. Newly inserted records are
physically stored such that the physical sequence of those records in storage closely
approximates the logical sequence as defined by the index. In a non clustered index the
records will not be in the order of index values.
A table can have any number of indexes but it can have only one clustered index.
Clustering is extremely important for optimization purpose. The optimizer will try to
choose an access path based on the clustering index .
For detailed explanation of indexes please refer More about indexes, chapter 12.

ALIASES

AN ALIAS IS AN ALTERNATIVE NAME FOR A TABLE OR VIEW. IT IS A

QUALIFIED NAME THAT CAN BE USED BY ANY AUTHORIZATION ID.
AN ALIAS CAN BE DEFINED FOR A TABLE OR VIEW THAT WAS
CREATED BY SOME OTHER USER AND FOR WHICH YOU WOULD
OTHERWISE HAVE TO USE A FULLY QUALIFIED NAME
ALIASES WERE DESIGNED FOR A DISTRIBUTED ENVIRONMENT TO
AVOID HAVING TO REFERENCE THE LOCATION QUALIFIER OF TABLE
OR VIEW
ALIAS IS NOT PRIVATE TO THE CREATOR
AN ALIAS CAN BE DEFINED ON AN UNDEFINED NAME. THAT IS THE
OBJECT ON WHICH THE ALIAS IS CREATED NEED NOT BE PRESENT AT
THE CREATION TIME

Aliases
Aliases are useful for creating meaningful names for TABLES and VIEWS. ALIASES are
created using CREATE ALIAS statement. One user can use an ALIAS created by another
user since aliases are not private to the creator
EXAMPLE
Suppose user ALPHA creates a table called SAMPLE.
CREATE TABLE SAMPLE
The fully qualified name of the table SAMPLE is ALPHA.SAMPLE and another user
BETA can refer to the table sample by its fully qualified name.
SELECT *
FROM ALPHA.SAMPLE
The user BETA can create an alias called ZTEST for the table ALPHA.SAMPLE using
create statement.
CREATE ALIAS ZTEST FOR ALPHA.SAMPLE
And now he can refer to the table SMPLE created by ALPHA by simply referring to the
alias ZTEST
SELECT *
FROM ZTEST
Another user GAMMA can also use BETAS ALIAS ZTEST to refer to ALPHAS
SAMPLE table.
SELECT * FROM
BETA.ZTEST

SYNONYMS

SYNONYMS ARE USEFUL FOR CREATING MORE MEANINGFUL NAME

FOR A PERSON USING A TABLE OR VIEW
A SYNONYM IS AN UNQUALIFIED NAME THAT CAN ONLY BE USED BY
THE AUTHORIZATION ID THAT CREATED IT.
A SYNONYM IS PRIVATE TO THE USER WHO CREATES IT
SYNONYM CANNOT REFER TO REMOTE TABLE IN A DISTRIBUTED
DATA ENVIRONMENT
A SYNONYM CAN ONLY BE DEFINED ON THE NAME OF AN EXISTING
TABLE OR VIEW.

Synonyms
A SYNONYM like an ALIAS is an alternative name for a table. Creating a SYNONYM for
a table or view will allow the creator to refer to those tables and views by the more
meaningful synonym created by him.
EXAMPLE
Suppose user ALPHA creates a table called SAMPLE.
CREATE TABLE SAMPLE
The fully qualified name of the table SAMPLE is ALPHA.SAMPLE and another user
BETA can refer to the table sample by its fully qualified name.
SELECT *
FROM ALPHA.SAMPLE
The user BETA can create a SYNONYM called ZTEST for the table ALPHA.SAMPLE
using create statement.
CREATE SYNONYM ZTEST FOR ALPHA.SAMPLE
And now he can refer to the table SAMPLE created by ALPHA by simply referring to the
SYNONYM ZTEST
SELECT *
FROM ZTEST
However the user BETA and table ALPHA.SAMPLE must be at the same site. Also the
name ZTEST is completely private to the user BETA. Another user GAMMA cannot use
the synonym created by BETA and if it wants a synonym it should be created on
ALPHA.SAMPLE.

DB2 CATALOG

DB2

CATALOG CONSISTS OF TABLES WHICH

CONTAIN

INFORMATION ABOUT OBJECTS DEFINED UNDER

DB2
4

SYSTEM .

CATALOG

WHEN A

TABLES

ARE

THE

NEW TABLE IS CREATED

UPDATED .

THEY ARE

SYSIBM.SYSTABLES ,

SYSIBM.SYSCOLUMNS .

SYSIBM.SYSTABLESPACE ,

SYSIBM.SYSTABAUTH

EXAMPLES OF CATALOG TABLES

SYSIBM.SYSTABLES
CONTAINS INFORMATION OF A TABLE. WHEN A NEW TABLE
IS CREATED DB2 INSERTS ONE ROW INTO THIS CATALOG
TABLE.
SYSIBM.SYSCOLUMNS
CONTAINS INFORMATION ABOUT THE COLUMNS IN A TABLE.
THIS TABLE CONTAINS ONE ROW FOR EVERY COLUMN OF
EACH ROW IN A TABLE .
SYSIBM.SYSTABLESPACE
CONTAINS INFORMATION OF THE TABLE SPACE CREATED.
THIS TABLE CONTAINS ONE ROW FOR EACH TABLESPACE.
SYSIBM.SYSTABAUTH
CONTAINS INFORMATION OF THE TABLE NAMES AND
AUTHORIZATION IDs WHICH HAVE PRIVILEGES ON THAT
TABLE

DB2 Catalog
The CATALOG in DB2 is a system database that contains information concerning various
objects that are of interest to DB2 itself. Examples of such objects are tables, views,
indexes, databases, plans, packages, access privileges, and so on. These information is
essential, if the system is to able to do its job properly.
CATALOG itself contains TABLES and you can see the contents of catalog tables using
normal query language ( SQL ). When you create, drop or alter any structure, DB2 updates
or deletes rows of the catalog that describe the structure.
DBA s and application programmers may use catalog tables to determine
Which application plan and packages use which indexes
Which tablespaces, tables and indexes are in a database
An indexs structure, whether unique or clustered or the number of levels present in an
index
The amount of physical space used and remaining
Who created an object and who owns it.
Which plans and packages use objects in a database.
Who has authorization to create objects
Which plans and packages use which tables and tables and views
Which synonyms and aliases have been created on tables and views
Who is authorized to execute which plans and packages etc
Optimizer component of bind will use catalog information to choose best access strategy.

DB2 DIRECTORY
DB2

DIRECTORY

REQUIRED

CONTAINS INFORMATION

TO START DB2 AND DB2

USES

THE DIRECTORY DURING NORMAL OPERATION.

DB2

DIRECTORY CONSISTS OF A SET OF DB2

TABLES STORED IN 5 TABLE SPACES IN SYSTEM

DATABASE DSNDB01.

SKELETON CURSOR TABLESPACE (SCT02) CONTAINS PLANS

SKELETON PACKAGE TABLE (SPT01) CONTAINS PACKAGES
LOG RANGE TABLE SPACE (SYSLGRNX) CONTAINS
(RELATIVE BYTE ADDRESS ) THE LOG DATASET
SYSTEM UTILITIES TABLE SPACE (SYSUTILX)
INFORMATION ABOUT RUNNING UTILITIES

THE

RBA

CONTAINS THE

THE DATABASE DESCRIPTOR TABLE SPACE (DBD01) CONTAINS

INTERNAL CONTROL BLOCKS THAT DESCRIBE THE DATABASES
EXISTING WITHIN DB2.
CANNOT ACCESS DIRECTORY USING SQL

ACTIVE AND ARCHIVE LOGS

DB2 RECORDS ALL DATA CHANGES AND SIGNIFICANT

EVENTS IN A LOG AS THEY OCCUR
DB2 WRITES EACH LOG RECORD TO A DASD DATA SET
CALLED THE ACTIVE LOG.
WHEN THE ACTIVE LOG IS FULL, DB2 COPIES THE CONTENTS
OF THE ACTIVE LOG TO A DASD CALLED THE ARCHIVE LOG

IN THE CASE OF FAILURE DB2 USES LOGS TO RECOVER DATA.

THE ARCHIVE LOG CAN CONSIST OF UP TO 1000 DATA SETS EACH OF

WHICH IS A SEQUENTIAL DATA SET.

BUFFER POOLS

BUFFER POOLS ARE AREAS OF VIRTUAL

STORAGE THAT TEMPORARILY STORE PAGES
OF TABLE SPACES OR INDEXES.
THE DATA REMAINS IN THE BUFFER UNTIL
DB2 DECIDES TO USE THE SPACE FOR
ANOTHER PAGE

BUFFER POOLS HOLD THE MOST FREQUENTLY ACCESSED DATA.

USING BUFFER POOLS IMPROVE PERFORMANCE.
DB2 ALLOWS TO USE 50 BUFFER POOLS THAT CONTAIN 4KB BUFFERS
AND 10 BUFFER POOLS THAT CONTAIN 32KB BUFFERS.
4KB BUFFER POOLS ARE BP0 TO BP49
32KB BUFFER POOLS ARE BP32K TO BP32K9

Buffer Pools
Buffer pools, also known as virtual buffer pools, are areas of virtual storage used
temporarily to store pages of table spaces or indexes. When an application program needs
to access a row of a table, DB2 retrieves the page containing that row and places the page
in a buffer. If the row is changed, the buffer must be written back to the table space. If the
needed data is already in a buffer, the application program will not have to wait for it to be
retrieved from DASD. The result is faster performance.
DB2 can provide 2 types of buffer pools, 4K and 32K buffer pools. There are fifty 4K
buffer pools named BP0, BP1, P49 and ten 32K buffer pools named BP32K, BP32K1,
BP32K9. DB2 manages each buffer pools separately . Generally system administrator
decides how much memory to allocate for buffer pools. The more memory allocated to
buffer pool the more data it can hold and therefore the greater the likelihood that an
application request will find the data there.

4.

Data Types

This chapter describes various data types used in DB2 and their examples. COBOL
declarations of the corresponding DATA TYPES are also included.
The sub divisions of this chapter are
4.1.

Numeric Data

4.1.1. Nulls
4.2.

String Data

4.3.

Character Format

4.4.

Date/Time Data

4.5.

Equivalent Cobol Declarations Of Data Types

DATA TYPES

EVERY COLUMN IN A TABLE IS ASSIGNED A SPECIFIC

TYPE AND SIZE OF DATA
CATEGORIES OF DATA TYPES
NUMERIC DATA
STRING DATA
DATE / TIME DATA

EACH COLUMN IN A TABLE MUST BE DEFINED

COLUMN DEFINITION MUST INCLUDE THE DATA TYPE AND SIZE
ALL DATA TYPES CAN INCLUDE NULL VALUES.

NUMERIC DATA
SMALLINT :

TWO BYTE BINARY INTEGER , 15 BITS AND SIGN.

INTEGER

FOUR BYTE BINARY INTEGER, 31 BITS AND SIGN.

DECIMAL (P,Q):

PACKED DECIMAL NUMBER HAVING P DIGITS OF

WHICH Q DIGITS ARE AFTER THE ASSUMED DECIMAL
POINT

FLOAT (M)
REAL

IF M IS BETWEEN 1 AND 21 THEN IT IS SINGLE

PRECISION FLOATING POINT AND IT OCCUPIES FOUR
BYTES. IT CAN ALSO BE REFERRED AS REAL

FLOAT (M)
FLOAT

IF M IS BETWEEN 22 AND 53 THEN IT IS SINGLE

PRECISION FLOATING POINT AND IT OCCUPIES EIGHT
BYTES. IT CAN ALSO BE REFERRED AS FLOAT

RANGE OF VALUES
SMALLINT

-32768 to +32767

INTEGER

-2147483648 to +2147483647

DECIMAL (P ,Q)

MAXIMUM 31 DIGITS
0 < P < 32 AND ( 0 <= Q <= P )

REAL
FLOAT

5.4E-79 to 7.2E+75.
5.4E-79 to 7.2E+75.

EXAMPLES OF NUMERIC DATA DECLARATION

SPKZ
DRU
HDNR

DECIMAL(5, 2)
SMALLINT
INTEGER

NULLS

SQL SYSTEMS LIKE DB2 REPRESENT MISSING INFORMATION IN A

COLUMN BY MEANS OF SPECIAL MARKERS CALLED NULLS.

THE PRESENCE OF NULL VALUE IN A COLUMN DEPENDS ON THE

COLUMN DEFINITION .

THREE OPTIONS, SPECIFIED IN COLUMN DEFINITION WHICH DEAL

WITH NULL VALUES ARE
NOT NULL

NULL
NOT NULL WITH DEFAULT

IF A COLUMN IS DECLARED AS NOT NULL THEN DB2 WILL NOT

ALLOW NULL VALUES ON THAT COLUMN

WHEN A COLUMN IS DECLARED AS NULL WHICH IS THE DEFAULT,

DB2 WILL ALLOW NULL VALUE ON THAT COLUMN

NOT NULL WITH DEFAULT MEANS THAT THE COLUMN IN

QUESTION CANNOT CONTAIN NULLS, BUT IT IS STILL LEGAL TO OMIT
A VALUE FOR THE COLUMN

EXAMPLES
SPKZ
DRU
HDNR

DECIMAL(5, 2)
SMALLINT
INTEGER

NULL
NOT NULL
NOT NULL WITH DEFAULT

Nulls
Null values are used in a table when actual values are unknown. Suppose the weight of a
part in the SUPPLIER-PARTS DATABASE is null, then it means that
(1) The part exists
(2) It does have a weight
(3) We do not know what the value is
In other words we do not know a genuine weight value that can sensibly be put in the
weight slot in the row for the part in question. Instead we mark that slot as null and we
interpret that mark to mean precisely that we do not know what the real value is. we can
insert a null value in the WEIGHT column if it is declared as NULL. But if it is declared as
NOT NULL WITH DEFAULT, it is possible to insert a row into the table without
specifying a value for WEIGHT column. In that case the column will contain default values
corresponding to the column data type.
Suppose that NOT NULL is specified for column WEIGHT in the SUPPLIER-PARTS
DATABASE, then this will guarantee that every row in table P will always contain a
genuine (not null) WEIGHT value. In other words a value must always be provided for
column WEIGHT when a row is inserted into the P table.
If a given column is allowed to contain nulls and a row inserted into the table with no value
provided for that column DB2 will automatically place a null in that position. Suppose that
the WEIGHT column in supplier-table database is specified as NULL, then we can insert a
row in the table P without specifying a value for WEIGHT. DB2 will automatically put a
null value in that column.
NOT NULL WITH DEFAULT means the column in question cannot contain nulls but it is
nevertheless still legal to omit a value for the column on insert. If a row is inserted and no
value is provided for some column to which NOT NULL WITH DEFAULT applies DB2
automatically places one of the following non null default values in that position.

Zero for numeric items

Blanks for fixed length string columns
Empty (zero length string) for varying length string columns
The value of CURRENT DATE or CURRENT TIME or CURRENT TIMESTAMP for
variables declared with attributes DATE, TIME or TIMESTAMP.

STRING DATA
CHARACTER FORMAT

CHARACTER(n) : FIXED LENGTH STRING OF n 8 BIT CHARACTERS

OCCUPYING N BYTES
VARCHAR(n) :

VARYING LENGTH STRING UP TO n 8 BIT CHARACTERS

OCCUPYING n+2 BYTES . FIRST TWO BYTES ARE
USED FOR STORING THE LENGTH OF THE VARIABLE

LONG VARCHAR : VARYING LENGTH CHARACTER STRING WHOSE

MAXIMUM LENGTH WILL BE DECIDED BY DB2

RANGE OF VALUES
CHARACTER(n)

1 TO 254

VARCHAR(n)

MUST BE LESS THAN PAGE SIZE (4K)

LONG VARCHAR

MAXIMUM LENGTH IS DETERMINED BY

THE AMOUNT OF SPACE AVAILABLE IN
A PAGE

EXAMPLES OF CHARACTER DATA REPRESENTATION

SPKZ
NUM
VAR

CHAR (20)
VARCHAR (60)
LONG VARCHAR

GRAPHIC FORMAT

GRAPHIC(n) :

FIXED LENGTH STRING OF N 16 BIT CHARACTERS

OCCUPYING 2n BYTES

VARGRAPHIC(n) : VARYING LENGTH STRING UP TO N 16 BIT

CHARACTERS OCCUPYING 2n+2 BYTES . FIRST TWO
BYTES ARE USED FOR STORING THE LENGTH OF THE
VARIABLE
LONG VARGRAPHIC :

VARYING LENGTH 16 BIT CHARACTER STRING

WHOSE MAXIMUM SIZE WILL BE DECIDED BY
DB2

RANGE OF VALUES
GRAPHIC(N)

1 TO 127

VARGRAPHIC(N) :

N MUST BE LESS THAN HALF THE PAGE SIZE

(2K)

LONG VARGRAPHIC:

MAXIMUM LENGTH IS DETERMINED BY THE

AMOUNT OF SPACE AVAILABLE IN A PAGE

EXAMPLES OF GRAPHIC DATA DECLARATIONS

TABKOST
TABID
TEMP

GRAPHIC (10)
VARGRAPHIC (80)
LONG VARRRAPHIC

DATE / TIME DATA

INTERNAL REPRESENTATIONS
DATE

YYYYMMDD

TIME

HHMMSS

TIMESTAMP

YYYYMMDDHHMMSSNNNNNN

DATE IS REPRESENTED AS A SEQUENCE OF EIGHT UNSIGNED PACKED

DECIMAL DIGITS OCCUPYING 4 BYTES

TIME IS REPRESENTED AS A SEQUENCE OF SIX UNSIGNED PACKED

DECIMAL DIGITS OCCUPYING 3 BYTES

TIMESTAMP IS REPRESENTED AS A SEQUENCE OF 20 UNSIGNED

PACKED DECIMAL DIGITS OCCUPYING 10 BYTES
EXAMPLES OF DATE TIME DECLARATIONS
CCTEMP
CCDAT
CCSTAMP

DATE
TIME
TIMESTAMP

Date / Time Data

Columns whose data types are DATE, TIME, OR TIMESTAMP are represented in an
internal form that is transparent to the user of SQL. But DATES, TIMES, AND
TIMESTAMPS can also be represented by DATE/TIME strings. These are character string
representations of date values. When you retrieve date/time values they must be assigned to
properly declared character string variables.
When a date or time is assigned to a variable, the string format is determined by a
precompiler option or subsystem parameter. When a string representation of a datetime
value is used in other operations, it is converted to a datetime value. However, this can be
done only if the string representation is compatible with the date / time value
Example
The ISO date format 1987-10-12 is internally stored in 4 bytes. But you must assign a
variable with 10 bytes as host variable for retrieving the above date.

EQUIVALENT COBOL DECLARATIONS OF DATA TYPES

DATATYPE

CCTEMP SMALLINT

COBOL DECLARATION

01 CCTEMP PIC S9(4) COMP.

CCTEMP INT

01 CCTEMP PIC S9(9) COMP.

CCTEMP DECIMAL(9,3)

01 CCTEMP PIC S9(6)V9(3) COMP-3.

CCTEMP FLOAT(21)

01 CCTEMP COMP-1.

CCTEMP FLOAT(53)

01 CCTEMP COMP-2.

CCTEMP CHAR(10)

01 CCTEMP PIC X(10).

CCTEMP VARCHAR(80)

01 CCTEMP
49 VARLEN PIC S9(4) COMP.
49 CCVAR
PIC X(80).

5.

SQL Programming

IN DB2 operations are done using structured query language. This chapter explains types
of SQL and their usage. SQL statements are divided into
DDL Statements
DML Statements
Control Statements

SQL PROGRAMMING
SQL (STRUCTURED QUERY LANGUAGE ) IS
THE LANGUAGE USED TO ACCESS DATA
IN DB2 TABLES

SQL

DDL

DML

CONTROL
STATEMENTS

DDL (DATA DEFINITION LANGUAGE)

CREATE
ALTER
DROP

DML (DATA MANIPULATION LANGUAGE)

SELECT
UPDATE
INSERT
DELETE

CONTROL STATEMENTS

GRANT
REVOKE
COMMIT
ROLLBACK

5.1.

DDL Statements

Data definition language statements used for creating, changing and dropping DB2 objects.
The following sections explain these statements with suitable examples
5.1.1. Create Database
5.1.2. Create Table Space
5.1.3. Create Table
5.1.3.1.

Keys

5.1.3.2.

Primary Keys

5.1.3.3.

Foreign Keys

5.1.4. Create View

5.1.5. Create Index
5.1.6. Alter Table
5.1.7. Drop

CREATE DATABASE

THE CREATE DATABASE STATEMENT DEFINES A

DB2 DATABASE TO THE DB2 SUBSYSTEM. THE NAME
MUST NOT START WITH DSNDB AND MUST NOT
IDENTIFY AN EXISTING DATABASE
IN THIS STATEMENT YOU CAN SPECIFY THE NAME OF BUFFER
POOL AND STORAGE GROUP FOR TABLE SPACES AND INDEXES
WITHIN THE DATABASE

IF BUFFER POOL IS NOT SPECIFIED IN THE CREATE DATABASE

STATEMENT THEN DEFAULT BUFFER POOL USED IS BP0.
IF STORAGE GROUP IS NOT SPECIFIED IN THE CREATE DATABASE
STATEMENT THEN DEFAULT STORAGE GROUP USED IS SYSDEFLT.
EXAMPLE
CREATE DATABASE "D2110K"
BUFFERPOOL BP2
STOGROUP "SGDB2O";

CREATE TABLESPACE

THE CREATE TABLESPACE STATEMENT ALLOCATES SPACE FOR

TABLES. THIS STATEMENT CREATES A SIMPLE, SEGMENTED,
OR PARTITIONED TABLE SPACE IN THE SPECIFIED DATABASE.
IF DATABASE IS NOT SPECIFIED THEN TABLESPACE IS CREATED
IN THE DEFAULT DATABASE DSNDB04

EXAMPLES
1.

CREATE TABLESPACE "S110K10" IN "D2110K"

USING STOGROUP "SGDB2O"
PRIQTY 100 SECQTY 52
FREEPAGE 0 PCTFREE 5
BUFFERPOOL BP0
LOCKSIZE ANY
CLOSE NO
SEGSIZE 8;

2.

CREATE TABLESPACE "S110L40" IN "D2110L"

USING STOGROUP "SGDB2O"
PRIQTY 100 SECQTY 52
ERASE NO
NUMPARTS 16
FREEPAGE 0 PCTFREE 5
BUFFERPOOL BP2
LOCKSIZE PAGE
CLOSE NO;

Create Table Space

Many parameters can be specified in the CREATE TABLESPACE statement which decides
the type of tablespace, the SIZE of VSAM datasets which hold the tables and indexes, the
amount and distribution of space left free in the datasets, the amount of data covered by
concurrency control locks etc. All of these decisions made during table space creation hold
performance implications. If the developer does not specify choices for any of these
parameters DB2 will use default values.
In the given examples DB2 automatically creates VSAM linear datasets needed for the
tablespace within the specified storage group. Each data set will be defined on a volume of
the storage group specified in the create tableapace statement. The values specified for
PRIQTY and SECQTY determine the primary and secondary allocations for the data set.
Erase parameter Indicates whether the DB2-managed data sets for the tablespace are to be
erased when they are deleted during the execution of a utility or an SQL statement that
drops the table space. ERASE NO does not erase the data sets. ERASE YES erases the
data sets. As a security measure, DB2 overwrites all data in the data sets with zeros before
they are deleted.
FREEPAGE parameter Specifies how often to leave a page of free space when the table
space or partition is loaded or reorganized. The default is FREEPAGE 0, leaving no free
pages. PCTFREE parameter indicates what percentage of each page to leave as free space
when the table is loaded or reorganized. The default is PCTFREE 5.
LOCKSIZE parameter Specifies the size of locks used within the table space . For more
information please refer chapter 9.
NUMPARTS parameter Indicates that the table space will be partitioned and the number of
partitions in that tablespace.
BUFFERPOOL parameter Identifies the buffer pool to be used for the table space and
determines the page size of the table space.
CLOSE parameter specifies whether or not the data sets are eligible to be closed when the
table space is not being used or the limit on the number of open data sets is reached.
CLOSE YES says the dataset is eligible for closing. This is the default. CLOSE NO
specifies that the dataset is not eligible for closing.
SEGSIZE parameter Indicates that the table space will be segmented and specifies, how
many pages are to be assigned to each segment. If SEGSIZE and NUMPARTS parameters
are not given, then the table space will be SIMPLE

CREATE TABLE

CREATE TABLE STATEMENT CREATES A TABLE IN A

TABLESPACE. TABLE NAME IS UNIQUE FOR A USER.
IF USERA CREATES TABLEA THEN FULLY QUALIFIED
NAME WILL BE USERA.TABLEA. USERA CAN SIMPLY USE
THE NAME TABLEA BUT OTHER USERS MUST SPECIFY
FULLY QUALIFIED NAME

EXAMPLES
1.

CREATE TABLE D2110L.SP

(
,S#
CHAR(5) NOT NULL
,P#
CHAR(6) NOT NULL
,QTY INTEGER NOT NULL
,PRIMARY KEY( S# , P# )
,FOREIGN KEY ( S# ) REFERENCES S,
,FOREIGN KEY ( P# ) REFERENCES P
)
IN D2110L.TABSP

(2) CREATE TABLE D2110L.SP LIKE D2110K.TAB IN D2110L.TABSP;

KEYS

A KEY IS ONE OR MORE COLUMNS THAT ARE IDENTIFIED AS

SUCH IN THE DESCRIPTION OF A TABLE, AN INDEX, OR A
REFERENTIAL CONSTRAINT.
S#

SNAME

S1
S2
S3

SMITH
JONES
BLAKE

STATUS
20
10
30

CITY
LONDON
PARIS
PARIS

KEY

A KEY IDENTIFIES A ROW OF DATA

A ROW IN ONE TABLE CAN CARRY THE KEY OF ANOTHER TABLE SO

KEYS ARE USED FOR RELATING TABLES
A KEY COMPOSED OF MORE THAN ONE COLUMN IS CALLED A
COMPOSITE KEY. A COMPOSITE KEY IS AN ORDERED SET OF
COLUMNS OF THE SAME TABLE.
A UNIQUE KEY IS A KEY THAT IS CONSTRAINED SO THAT NO TWO OF
ITS VALUES ARE EQUAL.

PRIMARY KEY
A PRIMARY KEY IS A UNIQUE KEY THAT IS A PART OF THE
DEFINITION OF A TABLE

P#
P1
P2
P3
P4
P5
P6

PNAME
NUT
BOLT
SCREW
SCREW
CAM
COG

COLOR
RED
GREEN
BLUE
RED
BLUE
RED

WEIGHT
12
17
17
14
12
19

CITY
LONDON
PARIS
ROME
LONDON
PARIS
LONDON

PRIMARY KEY

PRIMARY KEY OF A TABLE IS THE UNIQUE IDENTIFIER FOR THAT

TABLE

PRIMARY KEY CAN BE COMPOSITE

A TABLE CANNOT HAVE MORE THAN ONE PRIMARY KEY, AND THE
COLUMNS OF A PRIMARY KEY CANNOT CONTAIN NULL VALUES.

WHEN A PRIMARY KEY IS DEFINED ON A TABLE, A UNIQUE INDEX

MUST BE CREATED ON THAT PRIMARY KEY

FOREIGN KEYS

A FOREIGN KEY IS A COLUMN OR COMBINATION OF COLUMNS

IN ONE TABLE WHOSE VALUES ARE REQUIRED TO MATCH
VALUES OF THE PRIMARY KEY IN SOME OTHER TABLE.
TABLE S
S#

TABLE SP
SNAME

STATUS

S1
S2

SMITH
JONES

20
10

..

PRIMARY KEY IN S

CITY

S#

LONDON
PARIS

S1
S1
S2
.

P#

QTY

P1
P2
P1
.

300
200
300
..

FOREIGN KEY IN SP

A FOREIGN KEY VALUE REPRESENTS A REFERENCE TO THE ROW

CONTAINING THE MATCHING PRIMARY KEY VALUE.

THE TABLE THAT CONTAINS THE FOREIGN KEY IS KNOWN AS THE

DEPENDENT TABLE AND THE TABLE THAT CONTAINS THE PRIMARY
KEY IS KNOWN AS THE PARENT TABLE.

EACH VALUE OF A FOREIGN KEY MUST BE WHOLLY NULL OR WHOLLY

NON NULL. THAT IS IF FOREIGN KEY IS A COMPOSITE KEY THEN ALL
COMPONENTS OF THAT KEY MUST BE NULL OR NON NULL, NOT A
MIXTURE.

CREATE VIEW

THE CREATE VIEW STATEMENT CREATES A

VIEW ON TABLES OR VIEWS. IF THE VIEW NAME
IS UNQUALIFIED THEN THE AUTHORIZATION ID
IS THE IMPLICIT QUALIFIER
BASE TABLE: S
S#

SNAME

STATUS

CITY

VIEW : GOOD_SUPPLIERS
S#

STATUS CITY

IF YOU DO NOT SPECIFY A LIST OF COLUMN NAMES, THE COLUMNS

OF THE VIEW INHERIT THE NAMES OF THE COLUMNS OF THE RESULT
TABLE OF THE SUB SELECT.
EXAMPLE
CREATE VIEW GOOD_SUPPLIERS
AS SELECT S# , STATUS, CITY
FROM S
WHERE STATUS > 15 ;

CREATE INDEX

THE CREATE INDEX STATEMENT CREATES A PARTITIONED

OR NON PARTITIONED INDEX AND AN INDEX SPACE.
INDEX CAN BE CREATED ON ONE OR MORE COLUMNS.
WHEN YOU CREATE UNIQUE INDEX THE KEY CANNOT HAVE
DUPLICATE VALUES. UNIQUE INDEX SHOULD BE CREATED
FOR A PRIMARY KEY.

EXAMPLES
1.

CREATE UNIQUE INDEX D2110K.I11010U1

ON D2110K.S
(S#)
BUFFERPOOL BP0
USING STOGROUP SGDB2O
PRIQTY 40
SECQTY 20
CLOSE NO;

2.

CREATE INDEX D2110P.I11010U2

ON D2110N.P (P# DESC)

3.

CREATE UNIQUE INDEX D2110L.I11010U3

ON D2110L.SP (S#, P#)

ALTER TABLE

THE ALTER TABLE STATEMENT CHANGES THE

DESCRIPTION OF A TABLE
TO ADD MULTIPLE COLUMNS ,CODE MULTIPLE ALTER
STATEMENTS.
ADDED COLUMNS MUST ACCEPT NULL OR NOT NULL
WITH DEFAULT VALUES
THIS COMMAND CANNOT BE USED FOR DELETING A COLUMN
PRIMARY AND FOREIGN KEYS CAN BE CREATED AND DROPPED
USING THIS COMMAND

EXAMPLES
1.

ALTER TABLE D2110.P

ADD PRICE SMALLINT;

2.

ALTER TABLE D2110K.SP

FOREIGN KEY(P#) REFERENCES D2110K.P
ON DELETE CASCADE;

ALTER TABLE D2110K.P

PRIMARY KEY(P#);

ALTER TABLE D2110K.S

DROP PRIMARY KEY(S#);

DROP

THE DROP STATEMENT DELETES AN OBJECT

DROP

FREE

ALIAS
alias name
DATABASE database name
INDEX
index name
STOGROUP stogroup name
SYNONYM synonym name
TABLE
table name
TABLESPACE
table space name
VIEW view name
PACKAGE collection-id.package-id

PLAN

WHEN AN OBJECT IS DROPPED ALL OBJECTS THAT ARE DIRECTLY OR

INDIRECTLY DEPENDENT ON THAT OBJECT ARE DELETED
THE OBJECTS DESCRIPTION IS DELETED FROM THE CATALOG
TABLE.

Drop
The results of dropping various objects are given below.
1. Dropping an alias has no effect on any view or synonym that was defined using the
alias.
2. When you drop the database , the database and all of its table spaces, tables, index
spaces, and indexes are dropped.
3. Whenever an index is directly or indirectly dropped ,its index space is also dropped.
4. When the synonym is dropped, view or alias that defined using the synonym are not
dropped.
5. Whenever a table is directly or indirectly dropped, all privileges on the table, all
referential constraints in which the table is a parent or dependent, and all synonyms,
views, and indexes defined on the table are also dropped.
6. Whenever a table space is directly or indirectly dropped, all tables in the table space are
also dropped.
7. Whenever a view is directly or indirectly dropped, all privileges on the view and all
synonyms and views that are defined on the view are also dropped.
8. when the package version is dropped, all privileges on the package are dropped and all
plans that are dependent on the execute privilege of the package are invalidated.

5.2.

DML Statements

Data manipulation statements are used for retrieving data from DB2 tables. The following
statements together known as data manipulation language.
5.2.1. Select
5.2.1.1.

Comparison Operators

5.2.1.2.

Select Distinct

5.2.1.3.

Multiple Conditions

5.2.1.4.

Order By

5.2.1.5.

In, Between

5.2.1.6.

Partial Search

5.2.1.7.

Aggregate Functions

5.2.1.8.

Group By

5.2.1.9.

Having

5.2.2. Joining Tables

5.2.3. Sub Queries
5.2.4. Union
5.2.5. Insert
5.2.6. Update
5.2.7. Delete

DML STATEMENTS
SELECT
SQL SELECT
REQUIRED SEQUENCE
SELECT
FROM
WHERE
ORDER BY

EXAMPLE
Q:

GET SUPPLIER NUMBERS AND STATUS FOR

SUPPLIERS IN PARIS, IN DESCENDING ORDER OF STATUS

QUERY
SELECT S# , STATUS
-TELLS WHICH COLUMNS TO USE
FROM S
-TELLS WHICH TABLES TO USE
WHERE CITY = PARIS
-TELLS WHICH ROWS TO USE
ORDER BY STATUS DESC ;
-TELLS HOW TO SEQUENCE THE RESULT
RESULT
S#

STATUS

S3
S2

30
10

COMPARISON OPERATORS

EQUAL

^=

NOT EQUAL

<>

NOT EQUAL

>

GREATER THAN

^>

NOT GREATER THAN

>=

GREATER THAN OR EQUAL

<

LESS THAN

^<

NOT LESS THAN

<=

LESS THAN OR EQUAL

SELECT DISTINCT

SELECT DISTINCT IS TO ELIMINATE DUPLICATE ROWS

Q

QUERY

RESULT
P#
P1
P2
P3
P4
P5
P6

GET PART NUMBERS FOR ALL PARTS SUPPLIED

WITH REDUNDANT DUPLICATES ELIMINATED
:

SELECT DISTINCT P#
FROM SP;

MULTIPLE CONDITIONS

MULTIPLE CONDITION RETRIEVAL

AND

OR

Q1 :

GET SUPPLIER NUMBERS AND SUPPLIER

NAMES OF SUPPLIERS LOCATED IN
LONDON AND HAVING STATUS CODE 20

Q2 :

GET SUPPLIER NUMBERS AND SUPPLIER

NAMES OF SUPPLIERS WHOSE STATUS IS 10
OR 20.

QUERY 1 :

SELECT S#, SNAME

FROM S
WHERE STATUS = 20
AND CITY = LONDON ;

QUERY 2 :

SELECT S#, SNAME

FROM S
WHERE STATUS = 10
OR STATUS = 20 ;

RESULT 1

RESULT 2

S#

SNAME

S#

SNAME

S1
S4

SMITH
CLARK

S1
S2
S4

SMITH
JONES
CLARK

ORDER BY

SPECIFY COLUMN NAME AND TELL WHETHER

ASCENDING OR DESCENDING SEQUENCE
THE DEFAULT SEQUENCE IS ASCENDING
QUERY:

SELECT P# , WEIGHT IN GRAMS = , WEIGHT * 454

FROM P
ORDER BY 3, P# ;

RESULT
P#
P1
P5
P4
P2
P3
P6

WEIGHT IN GRAMS
WEIGHT IN GRAMS
WEIGHT IN GRAMS
WEIGHT IN GRAMS
WEIGHT IN GRAMS
WEIGHT IN GRAMS

=
=
=
=
=
=

5448
5448
6356
7718
7718
8448

IN, BETWEEN

IN

TO MATCH ONE OF A LIST OF VALUES

BETWEEN:

TO SELECT A RANGE OF VALUES

CAN USE NOT

IN AND NOT BETWEEN

Q1

GET PART NUMBERS , PNAME AND WEIGHT OF

PARTS WHOSE WEIGHT IS ANY ONE OF THE
FOLLOWING: 12 ,16 ,17

Q2

GET PART NUMBERS , PNAME AND WEIGHT OF

PARTS WHOSE WEIGHT IS IN THE RANGE 16 TO
19 INCLUSIVE

QUERY 1

SELECT P# , PNAME , WEIGHT

FROM P
WHERE WEIGHT IN ( 12 , 16 , 17 ) ;

QUERY 2

SELECT P# , PNAME , WEIGHT

FROM P
WHERE WEIGHT BETWEEN 16 AND 19 ;

RESULT 1
P#

PNAME

P1
P2
P3
P5

NUT
BOLT
SCREW
CAM

RESULT 2
WEIGHT
12
17
17
12

P#
P2
P3
P6

PNAME

BOLT
SCREW
COG

17
17
19

WEIGHT

PARTIAL SEARCH

TO SEARCH ON A SUBSET OF CHARACTERS :

LIKE

NOT TO SEARCH ON A SUBSET OF CHARACTERS :

LIKE
QUERY 1 :

SELECT S# , SNAME , CITY

FROM S
WHERE CITY LIKE L% ;

QUERY 2 :

SELECT S# , SNAME , CITY

FROM S
WHERE SNAME LIKE %S ;

QUERY 3 :

SELECT S# , SNAME , CITY

FROM S
WHERE CITY NOT LIKE %A% ;

QUERY 4 :

SELECT S# , SNAME , CITY

FROM S
WHERE CITY LIKE %DON ;

QUERY 5 :

SELECT S# , SNAME , CITY

FROM S
WHERE SNAME LIKE _L% ;

NOT

RESULT 1
S#

SNAME

CITY

S1
S4

SMITH
CLARK

LONDON
LONDON

S#

SNAME

CITY

S2
S5

JONES
ADAMS

PARIS
ATHENS

RESULT 2

RESULT 3
S#

SNAME

S1
S4

SMITH
CLARK

CITY
LONDON
LONDON

RESULT 4
S#

SNAME

CITY

S1
S4

SMITH
CLARK

LONDON
LONDON

S#

SNAME

CITY

S3
S4

BLAKE
CLARK

PARIS
LONDON

RESULT 5

AGGREGATE FUNCTIONS

COUNT

NUMBER OF VALUES IN THE COLUMN

SUM

SUM OF VALUES IN THE COLUMN

AVG

AVERAGE OF VALUES IN THE COLUMN

MAX

MAXIMUM OF VALUES IN THE COLUMN

MIN

MINIMUM OF VALUES IN THE COLUMN

Q1

GET THE TOTAL NUMBER OF SUPPLIERS.

Q2

GET THE TOTAL QUANTITY, AVERAGE QUANTITY,

MAXIMUM QUANTITY AND MINIMUM QUANTITY OF
PART P2 SUPPLIED

QUERY 1

SELECT COUNT(*)
FROM S;

QUERY 2
(QTY)

SELECT SUM (QTY) , AVG (QTY) , MAX (QTY) , MIN

FROM SP
WHERE P# = P2 ;

RESULT 1

RESULT 2

1000

250

400

200

GROUP BY

WITH GROUP BY, A COLUMN FUNCTION RESULTS

IN A SINGLE VALUE FOR EACH GROUP

FOR EACH PART SUPPLIED GET THE PART

NUMBER AND THE TOTAL SHIPMENT QUANTITY
FOR THAT PART

QUERY

SELECT P# , SUM (QTY)

FROM SP
GROUP BY P# ;

RESULT
P#
P1
P2
P3
P4
P5
P6

600
1000
400
500
500
100

HAVING

HAVING IS USED TO GET SOME SPECIFIC ROWS, FROM THE ROWS

OBTAINED BY GROUP BY CLAUSE, WHICH SATISFY THE
CONDITION
GIVEN IN THE HAVING CLAUSE.
HAVING IS USED TO ELIMINATE GROUPS JUST AS WHERE IS USED
TO ELIMINATE ROWS.
Q:

QUERY

GET PART NUMBERS FOR ALL PARTS SUPPLIED BY

MORE THAN ONE SUPPLIER

RESULT
P#
P1
P2
P4
P5

SELECT P#
FROM SP
GROUP BY P#
HAVING COUNT (*) > 1.

JOINING TABLES

IT IS A QUERY IN WHICH DATA IS RETRIEVED FROM MORE

THAN ONE TABLE
Q:

GET ALL COMBINATIONS OF SUPPLIER AND PART

INFORMATION SUCH THAT THE SUPPLIER CITY
FOLLOWS THE PART CITY IN ALPHABETICAL ORDER

QUERY :

SELECT S.* , P.*

FROM S , P
WHERE S.CITY > P.CITY

RESULT
S# SNAME STATUS S.CITY P#
S2
S2
S2
S3
S3
S3

JONES
JONES
JONES
BLAKE
BLAKE
BLAKE

10
10
10
30
30
30

PARIS
PARIS
PARIS
PARIS
PARIS
PARIS

P1
P4
P6
P1
P4
P6

PNAME COLOR WEIGHT P.CITY

NUT
SCREW
COG
NUT
SCREW
COG

RED
RED
RED
RED
RED
RED

12
14
19
12
14
19

LONDON
LONDON
LONDON
LONDON
LONDON
LONDON

SUB QUERIES

A SUB QUERY IS A SELECT-FROM-WHERE EXPRESSION

THAT IS NESTED INSIDE ANOTHER SUCH EXPRESSION
MAXIMUM 15 LEVELS ARE POSSIBLE IN A NESTED SUB
SELECT
Q:

GET SUPPLIER NAMES FOR SUPPLIERS WHO SUPPLY

PART P2.

QUERY :

RESULT
SNAME
SMITH
JONES
BLAKE
CLARK

SELECT SNAME
FROM S
WHERE S# IN
( SELECT S#
FROM SP
WHERE P# = P2 ) ;

UNION

THE RESULTS OF ONE OR MORE RELATIONS ARE

MIXED TO FORM A SINGLE RELATION USING UNION .
Q:

GET PART NUMBERS FOR PARTS THAT EITHER

WEIGH MORE THAN 16 POUNDS OR ARE
SUPPLIED BY SUPPLIER S2

QUERY :

SELECT P#
FROM P
WHERE WEIGHT > 16
UNION
SELECT P#
FROM SP
WHERE S# = S2 ;

RESULT
P1
P2
P3
P6

INSERT

THE INSERT STATEMENT INSERTS A NEW ROW INTO

THE TABLE. YOU CAN EITHER INSERT VALUES FOR
ALL COLUMNS OR OMIT VALUES. BUT OMITTING A
A VALUE FOR SOME COLUMN DEPENDS ON THE
WAY THE COLUMN WAS DEFINED
Q1 :

ADD PART P8 (A SPROCKET , COLOR PINK ,

WEIGHT 14 , CITY NICE ) TO TABLE P

Q2 :

ADD PART P7 (CITY ATHENS , WEIGHT 24 ) NAME

AND COLOR AT PRESENT UNKNOWN. ASSUME
THAT THE COLUMNS PNAME AND COLOR ARE
CREATED WITH NULL ATTRIBUTE SPECIFICATION.

QUERY 1

INSERT
INTO P
VALUES ( P8, SPROCKET, PINK, 14, NICE ) ;

QUERY 2

INSERT
INTO P ( P#, CITY, WEIGHT )
VALUES ( P7, ATHENS, 24 );

P#

P8
P7

PNAME
.
SPROCKET
?

COLOR WEIGHT

CITY

PINK
?

.
NICE
ATHENS

....
14
24

RESULT 1
RESULT 2

UPDATE

THE UPDATE STATEMENT UPDATES THE VALUES

OF SPECIFIED COLUMNS IN ROWS OF A TABLE OR
VIEW. UPDATING A ROW OF A VIEW UPDATES A
ROW OF THE TABLE ON WHICH THE VIEW IS BASED.
Q:

QUERY

CHANGE THE COLOR OF PART P1 TO YELLOW ,

INCREASE ITS WEIGHT BY 5 , AND SET ITS CITY
TO UNKNOWN. ASSUME THAT THE DEFINITION
OF P.CITY ALLOWS NULL VALUES.

UPDATE P
SET COLOR = YELLOW ,
WEIGHT = WEIGHT + 5
CITY = NULL
WHERE P# = P1 ;

RESULT
P#

P1

PNAME

NUT

COLOR WEIGHT
CITY

YELLOW
17
?

DELETE

THE DELETE STATEMENT DELETES ROWS FROM

A TABLE OR VIEW. DELETING A ROW FROM A
VIEW DELETES THE ROW FROM THE TABLE ON
WHICH THE VIEW IS BASED.
SINGLE ROW DELETE
Q1:

DELETE SUPPLIER S5

MULTIPLE ROW DELETE

Q2 :

DELETE ALL SHIPMENTS WITH QUANTITY

GREATER THAN 300

QUERY 1

DELETE
FROM S
WHERE S# = S5 ;

QUERY 2

DELETE
FROM SP
WHERE QTY > 300 ;

5.3.

Control Statements

Statements other than DDL and DML are explained in this section. They are
5.3.1. Grant
5.3.2. Revoke
5.3.3. Commit
5.3.4. Roll Back

CONTROL STATEMENTS
GRANT

TO PERFORM ANY OPERATION ON ANY OBJECT THE

USER MUST HOLD THE APPROPRIATE PRIVILEGE
FOR THE OPERATION AND THE OBJECT IN QUESTION .
THE GRANT STATEMENT GRANTS PRIVILEGES ON AN
OBJECT TO AUTHORIZATION IDS.

TABLE PRIVILEGES
GRANT SELECT ON TABLE S TO CHARLY ;
GRANT SELECT , UPDATE (STATUS , CITY ) ON TABLE S
TO JUDY, JACK, JOHN ;
GRANT ALL PRIVILEGES ON TABLE S TO PUBLIC ;

PACKAGE AND PLAN PRIVILEGES

GRANT EXECUTE ON PLAN PLANB TO CHARLY ;

COLLECTION PRIVILEGES
GRANT CREATE IN EWSK TO JOHN ;

DATABASE PRIVILEGES
GRANT CREATETAB ON DATABASE DBX TO NANCY ;

USE PRIVILEGES
GRANT USE OF TABLESPACE DBX.TS76 TO TOM ;

SYSTEM PRIVILEGES

GRANT CREATEDBC TO ARNOLD ;

REVOKE

USED TO REVOKE PREVIOUSLY GRANTED PRIVILEGES ON AN

OBJECT FROM USERS. GENERAL FORMAT OF REVOKE IS
SIMILAR TO THAT OF GRANT. REVOKE CAN BE USED TO
REVOKE ALL PRIVILEGES EXPLAINED IN THE GRANT COMMAND

EXAMPLES
REVOKE SELECT ON TABLE S FROM CHARLY ;
REVOKE UPDATE ON TABLE S FROM JOHN ;
REVOKE CREATETAB ON DATABASE DBX FROM NANCY ;

COMMIT

COMMIT OPERATES ON A UNIT OF RECOVERY

AFTER EXECUTING THIS STATEMENT

ALL CHANGES WILL BE DONE PERMANENTLY

ROW LOCKS WILL BE RELEASED
DEFAULT COMMIT IS AT PROGRAM TERMINATION

IF AN APPLICATION DETERMINES THAT A UNIT OF WORK IS

SUCCESSFUL IT CAN INDICATE THAT TO THE DATABASE MANAGER
VIA A COMMIT. THE DATABASE MANAGER CAN MAKE THE CHANGES
PERMANENT
CURSORS ARE CLOSED EXCEPT THOSE DECLARED WITH HOLD
OPTION
EXAMPLE
UPDATE TABLE S
SET STATUS = 20
WHERE S# = S1;
COMMIT;

ROLLBACK

A UNIT OF WORK IS UNDONE IF ANY ABNORMAL

CONDITION OCCURS . WHEN THIS STATEMENT
IS EXECUTED
ALL CHANGES IN THAT UNIT OF WORK
WILL BE BACKED OUT
ALL LOCKS ARE RELEASED
ALL OPEN CURSORS ARE CLOSED

WHEN YOU ISSUE A ROLLBACK THEN THE DATABASE MANAGER WILL

RE-ESTABLISH THE STATE OF THE DATABASE AT THE LAST
COMPLETED UNIT OF WORK
ROLLBACK WILL BE DONE EITHER BY THE PROGRAM OR BY THE
SYSTEM.
EXAMPLE
ROLLBACK WORK ;

6.

Program Structure

This section gives an over view of a DB2 application program .Different sections to be
included in an application are explained briefly.
6.1.

Host Variables

6.1.1. Declaring Host Variables

6.2.

Indicator Variables

6.3.

SQLCA

6.4.

Cobol Structure Of SQLCA

6.5.

SQLCA Return Codes

6.6.

SQLCA Warnings

6.7.

Important SQL codes

6.8.

Static SQL

6.9.

Dynamic SQL

6.10. Example For A DB2 Application Program

PROGRAM STRUCTURE
STRUCTURE OF A PROGRAM THAT ACCESSES DB2

SQLCA
HOST VARIABLE DECLARATIONS
DECLARE TABLE STATEMENTS
DECLARE CURSOR
SQL STATEMENTS WITHOUT
FETCH
OPEN CURSOR
FETCH CURSOR
CLOSE CURSOR

DIFFERENT SECTIONS TO BE INCLUDED IN A DB2 PROGRAM ARE

SHOWN IN THE ABOVE FIGURE.
IF THE HOST LANGUAGE IS COBOL, THEN HOST VARIABLE
DECLARATION, SQLCA, AND DECLARE TABLE STATEMENTS SHOULD
BE IN THE WORKING STORAGE SECTION AND CURSOR
DECLARATIONS SHOULD BE JUST ABOVE THE PROCEDURE DIVISION.
ALL OTHER SECTIONS ARE IN PROCEDURE DIVISION.

Program Structure
Programs that access DB2 are written in a number of host languages - COBOL, PL/1, C ,
ASSEMBLER , FORTRAN, BASIC etc. These programs can contain SQL statements that
retrieves or updates database.
The start and end of SQL statements must be indicated by delimiters. The delimiters used in
COBOL are EXEC SQL and END-EXEC.
SQL statements must be coded with in these delimiters. Even if multiple SQL statements
appear sequentially, each SQL statement should be indicated by delimiters.
Pre compiler uses delimiters to identify SQL statements from the host language.
EXAMPLE OF USING DELIMITERS IN COBOL
EXEC SQL
UPDATE S
SET STATUS = 10
WHERE CITY = ATHENS
END-EXEC.

HOST VARIABLES

HOST VARIABLES ARE USED TO IDENTIFY THE SYMBOLIC

NAME OF STORAGE, THAT HAS BEEN DECLARED USING
THE APPLICATION PROGRAM LANGUAGE DEFINITION STATEMENT
SQL STATEMENT
SELECT SNAME INTO :TMPNAME WHERE S# = S1
HOST VARIABLE

HOST VARIABLES ARE OPTIONAL

HOST LANGUAGE VARIABLES IN SQL STATEMENT MUST BE
PRECEDED BY A COLON
HOST VARIABLE MUST MATCH COLUMN DATA TYPE
CAN BE USED ANYWHERE A VALUE IS REQUIRED IN AN SQL
STATEMENT

EXAMPLE(1)
SQL STATEMENT 1
INSERT INTO S
( S#, SNAME )
VALUES ( S6 , GEORGE )
SQL STATEMENT 2
INSERT INTO S
( S#, SNAME )
VALUES ( :SUPCODE, :SUPNAME )
In SQL statement 1 the values to be inserted are hard coded .Second SQL statement shows
the use of host variables in an embedded SQL .This statement could be included in a
processing loop with the programs logic assigning various values to the host variables.
EXAMPLE (2)
SQL STATEMENT
UPDATE S
SET STATUS = STATUS * :PERCENT
WHERE S# = :SUPCODE
In this example host variables are used to update a table .

DECLARING HOST VARIABLES

THERE ARE TWO METHODS OF HOST VARIABLE DECLARATION

(1)

DECLARE HOST VARIABLES IN THE WORKING STORAGE SECTION

(2)

EXEC SQL

INCLUDE (member name which contains all host variable declarations

and declare table statements)
END EXEC.

we cant access data to other application prgograms from db2 directly.

so we need to create dummy variable as we defined variables in application
program , by using those variables we can access data.
dummy variables also called as host variables need not be created manually as
they are default generated by dclgen when we create it.

Declaring Host Variables

You can declare all host variables in the working storage section of the COBOL program.
The host variable declaration should match with the corresponding column definition
The host variable names must not begin with SQL or EXEC.
Another method of declaring host variables is using the verb INCLUDE. All the host
variables are declared in a partitioned dataset member and that member is included in the
source program using verb INCLUDE.

INDICATOR VARIABLES

INDICATOR VARIABLE INDICATES THE PRESENCE

OF NULL VALUE IN A COLUMN
SELECT SNAME INTO :SUPNAME:SUPNAMIND
FROM S
HOST VARIABLE
INDICATOR VARIABLE

INDICATOR VARIABLE IS REQUIRED IF THE SELECTED COLUMNS

ALLOWS NULL
IF COLUMN CONTAINS NULL VALUE THEN THE INDICATOR VARIABLE
IS SET TO NEGATIVE VALUE, HOST VARIABLE IS UNTOUCHED
INDICATOR VARIABLE IS ASSOCIATED WITH A HOST VARIABLE

Indicator Variables
When the program is to receive a value from a column that allows nulls, the program can
get either a value or null. So the program requires two variables, a host variable to receive
value and an indicator variable to indicate the presence of null value in the selected column.
If DB2 attempts to indicate the presence of a null and the program does not provide an
indicator variable an error occurs.
If the value returned is null then the null indicator indicates that by a negative value and the
value in the host variable remains unchanged. The program should have an indicator
variable for each column that allows null.
In EXAMPLE1 when the selected column contains a null value then the program logic is
coded in such way to tackle it.
Example 2 shows that indicator variables are used for UPDATE operations also. Before
updating the table, the indicator variable is made negative and DB2 sets the column to null
ignoring the value in the host variable.
Indicator variable should be declared like you declare a host variable. Data type of an
indicator variable is SMALLINT and corresponding cobol declaration is given below
01 SUPNAMIND PIC S9(4) COMP.

Examples
1.

EXEC SQL
SELECT SNAME , CITY
INTO :SUPNAME:SUPNAMIND , :PGMCITY
FROM S
WHERE S# = S1
END EXEC.
IF SUPNAMIND < 0
PERFORM NONAME-SECTION
ELSE
PERFORM NAME-SECTION.

2.

IF ( some condition )
SUPNAMIND = -1
ELSE
SUPNAMIND = 0.
EXEC SQL
UPDATE S
SET SNAME = :SUPNAM:SUPNAMIND
WHERE S# = S1
END EXEC.

SQLCA ( SQL COMMUNICATION AREA)

THE SUCCESS OR FAILURE OF THE LAST EXECUTED SQL

STATEMENT IS DESCRIBED IN SQLCA

PROGRAM
STATUS OF EXECUTED SQL
SQLCA

SQL STATEMENTS

DB2

AFTER EACH SQL STATEMENT, SQLCA CODES MUST BE CHECKED BY

THE PROGRAM TO FIND WHETHER THE SQL WAS SUCCESSFUL OR
NOT
SQLCA IS INCORPORATED IN THE PROGRAM USING INCLUDE
STATEMENT.

SQLCA
The SQL communication area (SQLCA) is a data structure that must be included in any
host language program using SQL .The SQLCA provides a way for DB2 to pass feedback
about its operations to the program .After executing an SQL DB2 returns via the
SQLCA ,codes indicating the execution was successful or identifying errors and special
conditions. The program can then test for these codes and react according to their content.
The SQLCA structure contains variables for a number of codes and messages.
Programmers can code the necessary structure(explained in next page) , copy it from a
source library or have DB2 generate it.
An include statement allows the source program to include SQLCA structure from the copy
library and is shown below.
EXEC SQL
INCLUDE SQLCA
END EXEC.

COBOL STRUCTURE OF SQLCA

01 SQLCA.
05 SQLCAID
PIC X(8).
05 SQLCABC
PIC S9(9) COMP-4.
05 SQLCODE
PIC S9(9) COMP-4.
05 SQLERRM.
49 SQLERRML PIC S9(4) COMP-4.
49 SQLERRMC PIC X(70).
05 SQLERRPPIC X(8).
05 SQLERRD
OCCURS 6 TIMES
PIC S9(9) COMP-4.
05 SQLWARN.
10 SQLWARN0 PIC X.
10 SQLWARN1 PIC X.
10 SQLWARN2 PIC X.
10 SQLWARN3 PIC X.
10 SQLWARN4 PIC X.
10 SQLWARN5 PIC X.
10 SQLWARN6 PIC X.
10 SQLWARN7 PIC X.
05 SQLEXT.
10 SQLWARN8 PIC X.
10 SQLWARN9 PIC X.
10 SQLWARNA PIC X.
10 SQLSTATE PIC X(5).

MOST IMPORTANT SQLCA CODES ARE SQLCODE AND SQLWARN0

SQLCA RETURN CODES

CONDITION
STATUS

INTEGER
SQLCODE

ERROR

<0

WARNING

>0 & <>100

NOT FOUND

+100

SUCCESS

CHAR(1)
SQLWARN0

REQUEST
FAILED

OR W

SATISFIED
WITH SPECIAL
CONDITION
DATA NOT
FOUND

AND

SUCCESS

IF SQLCODE CONTAINS A NEGATIVE VALUE THEN IT IS AN ERROR

ALL POSITIVE SQLCODES NOT EQUAL TO 100 ARE CONSIDERED
WARNINGS
A W IN SQLWRN0 INDICATES A WARNING EVEN IF SQLCODE = 0.

SQLCA WARNINGS

SQL WARNING

DESCRIPTION

SQLWARN0

THIS FIELD IS BLANK IF ALL SQL WARNINGS

FROM SQLWARN1 TO SQLWARNA ARE BLANKS.
CONTAINS W IF ONE OR MORE SQL WARNINGS
CONTAINS W.

SQLWARN1

CONTAINS W IF THE VALUE OF A STRING COLUMN

WAS TRUNCATED WHEN ASSIGNED TO HOST
VARIABLE.

SQLWARN2

CONTAINS W IF NULL VALUES WERE ELIMINATED

FROM THE ARGUMENT OF A COLUMN FUNCTION

SQLWARN3

CONTAINS W IF THE NUMBER OF RESULT COLUMNS

IS LARGER THAN THE NUMBER OF HOST VARIABLES.

SQLWARN4

CONTAINS W IF A PREPARED UPDATE OR DELETE

STATEMENT DOES NOT INCLUDE A WHERE CLAUSE.

SQLWARN5

CONTAINS W IF THE SQL STATEMENT WAS NOT

EXECUTED BECAUSE IT IS NOT A VALID SQL
STATEMENT IN DB2 FOR MVS/ESA.

SQLCA WARNINGS..

SQL WARNING

DESCRIPTION

SQLWARN6

CONTAINS W IF THE ADDITION OF A MONTH OR YEAR

DURATION TO A DATE OR TIMESTAMP VALUE
RESULTS IN AN INVALID DAY. AN INVALID DAY (FOR
EXAMPLE, JUNE 31). INDICATES THAT THE VALUE OF
THE DAY WAS CHANGED TO THE LAST DAY OF THE
MONTH TO MAKE THE RESULT VALID.

SQLWARN7

CONTAINS A W IF ONE OR MORE NON ZERO DIGITS

WERE LIMITED FROM THE FRACTIONAL PART OF
A NUMBER USED AS THE OPERAND OF A DECIMAL
MULTIPLY OR DIVIDE OPERATION.

SQLWARN8

CONTAINS A W IF A CHARACTER THAT COULD NOT

BE CONVERTED WAS REPLACED WITH A
SUBSTITUTE CHARACTER.

SQLWARN9

CONTAINS A W IF ARITHMETIC EXCEPTIONS WERE

IGNORED DURING COUNT DISTINCT PROCESSING.

SQLWARNA

CONTAINS A W IF AT LEAST ONE CHARACTER FIELD

OF THE SQLCA OR THE SQLDA NAMES OR LABELS IS
INVALID DUE TO A CHARACTER CONVERSION ERROR.

Important SQL codes

-102

LITERAL STRING IS TOO LONG. STRING BEGINS string

-107

THE NAME name IS TOO LONG. MAXIMUM ALLOWABLE SIZE IS size

-117 THE NUMBER OF INSERT VALUES IS NOT THE SAME AS THE NUMBER
OF OBJECT COLUMNS
-119 A COLUMN IDENTIFIED IN A HAVING CLAUSE IS NOT INCLUDED IN
THE GROUP BY CLAUSE
-125 AN INTEGER IN THE ORDER BY CLAUSE DOES NOT IDENTIFY A
COLUMN OF THE RESULT
-150 THE OBJECT OF THE INSERT, DELETE, OR UPDATE STATEMENT IS A
VIEW FOR WHICH THE REQUESTED OPERATION IS NOT PERMITTED
-204

name IS AN UNDEFINED NAME

-205

column-name IS NOT A COLUMN OF TABLE table-name

-303 A VALUE CANNOT BE ASSIGNED TO OUTPUT HOST VARIABLE NUMBER

position-number BECAUSE THE DATA TYPES ARE NOT COMPARABLE
-401 THE OPERANDS OF AN ARITHMETIC OR COMPARISON OPERATION ARE
NOT COMPARABLE
-407 AN UPDATE OR INSERT VALUE IS NULL, BUT THE OBJECT COLUMN
column-name CANNOT CONTAIN NULL VALUES
-501 THE CURSOR IDENTIFIED IN A FETCH OR CLOSE STATEMENT IS NOT
OPEN
-502

THE CURSOR IDENTIFIED IN AN OPEN STATEMENT IS ALREADY OPEN

-503 A COLUMN CANNOT BE UPDATED BECAUSE IT IS NOT IDENTIFIED IN

THE UPDATE CLAUSE OF THE SELECT STATEMENT OF THE CURSOR
-504

THE CURSOR NAME cursor-name IS NOT DEFINED

-540 THE DEFINITION OF TABLE table-name IS INCOMPLETE BECAUSE IT

LACKS A PRIMARY INDEX OR A REQUIRED UNIQUE INDEX

-551 auth-id DOES NOT HAVE THE PRIVILEGE TO PERFORM OPERATION

operation ON OBJECT object-name
-603 A UNIQUE INDEX CANNOT BE CREATED BECAUSE THE TABLE
CONTAINS ROWS WHICH ARE DUPLICATES WITH RESPECT TO THE VALUES
OF THE IDENTIFIED COLUMNS
-623

A CLUSTERING INDEX ALREADY EXISTS ON TABLE table-name

-661 INDEX index-name CANNOT BE CREATED ON PARTITIONED TABLE

SPACE tspace-name BECAUSE THE NUMBER OF PART SPECIFICATIONS IS NOT
EQUAL TO THE NUMBER OF PARTITIONS OF THE TABLE SPACE
-672

OPERATION DROP NOT ALLOWED ON TABLE table_name

-719

BIND ADD ERROR

USING auth-id AUTHORITY
PACKAGE package-name
ALREADY EXISTS

-805 DBRM or PACKAGE NAME location-name.collection-id.dbrm-name.consistency

-token NOT FOUND IN PLAN plan-name. REASON reason
-811 THE RESULT OF AN EMBEDDED SELECT STATEMENT IS A TABLE OF
MORE THAN ONE ROW, OR THE RESULT OF THE SUBQUERY OF A BASIC
PREDICATE IS MORE THAN ONE VALUE
-904 UNSUCCESSFUL EXECUTION CAUSED BY AN UNAVAILABLE
RESOURCE. REASON reason-code, TYPE OF RESOURCE resource-type, AND
RESOURCE NAME resource-name
-911 THE CURRENT UNIT OF WORK HAS BEEN ROLLED BACK DUE TO
DEADLOCK OR TIMEOUT. REASON reason-code, TYPE OF RESOURCE resourcetype, AND RESOURCE NAME resource-name
-913 UNSUCCESSFUL EXECUTION CAUSED BY DEADLOCK OR TIMEOUT.
REASON CODE reason-code, TYPE OF RESOURCE resource-type, AND RESOURCE
NAME resource-name

CODING AIDS
WHENEVER STATEMENT

EXEC SQL
WHENEVER Condition Action
END-EXEC
CONDITION:
SQLERROR
-- NEGATIVE SQLCODE
SQLWARNING
-- POSITIVE SQLCODE ( NOT +100 )
-- OR SQLWARN0 = W
NOT FOUND
-- SQLCODE = +100
ACTION:
GO TO :SECTA
-- CONTROL TRANSFERRED TO STATEMENT LABELED
SECTA
CONTINUE
-- PROGRAM CONTINUES WITH NEXT STATEMENT
-- USED TO CANCEL THE EFFECT OF PRIOR WHENEVER

PHYSICAL PLACEMENT OF WHENEVER STATEMENT DETERMINES

THE SQL STATEMENTS UNDER ITS EFFECT
THE USE OF COLON BEFORE THE LABEL IS OPTIONAL
GO TO AND GOTO ARE EQUIVALENT

Whenever Statement
WHENEVER statements help programmers to avoid checking SQLCODE after every SQL
statement. WHENEVER statements are SQL STATEMENTS that can be embedded in one
or more times in the host language program for branching to a paragraph depending on the
content of SQLCODE.
Each WHENEVER statement applies to all of the SQL statements that follow it in the
program listing, regardless of order in which the statements are actually executed. This
happens because COBOL precompiler puts appropriate branching instruction after every
SQL statement that follows the whenever statement.
WHENEVER statements can be used for three different conditions and these are similar to
IF THEN statements. IF SQLcode satisfies some condition then the program performs the
branching .
EXAMPLE
EXEC SQL
WHENEVER NOT FOUND CONTINUE
END-EXEC
EXEC SQL
WHENEVER SQLERROR PERFORM ERR-SECTION
END-EXEC
EXEC SQL
WHENEVER SQLWARNING PERFORM WARN-SECTION
END-EXEC

INCLUDE STATEMENT

THE INCLUDE STATEMENT INSERTS DECLARATIONS

OR CODE INTO A SOURCE PROGRAM.

SOURCE PROGRAM

EXEC SQL

SQLCA (TO BE INCLUDED IN SOURCE

PROGRAM )
01SQLCA
05 SQLCAID
05 SQLCABC

PIC X(8).
PIC S9(9) COMP-4.

INCLUDE SQLCA
END-EXEC.

THE INCLUDE STATEMENT INSERTS SOURCE CODE INTO A SOURCE

PROGRAM AT PRE COMPILE TIME.
THE INCLUDE STATEMENT CANNOT REFER TO SOURCE STATEMENTS
THAT THEMSELVES CONTAIN INCLUDE STATEMENTS.

USING CURSORS
PROCESSING MULTIPLE ROWS
QUERY:

SELECT STATUS, CTTY INTO :RANK, :CITY

FROM S WHERE STATUS < 30 ;

STATUS
2
10
20

CITY
LONDON
PARIS
LONDON
RANK

STATUS

CITY

20
10
20

LONDON
PARIS
LONDON

CITY

RANK

CITY

RANK

CITY

STATUS CITY
20
10
20

LONDON
PARIS
LONDON

Processing Multiple Rows

In previous example the result of the query gives multiple rows. But there is no method to
determine the number of rows satisfying the condition before actually receiving data from
DB2.Therefore it is not possible to allocate storage in the application program to receive an
entire set of data.
When we are using host variables for retrieving data and if the result is a single row the
query will work and SQL return code will be set to zero. But in the given example the
result of the query gives multiple rows and the host language can deal with only at a time
Now the program is in error, SQLCODE will be set to a negative value and the values of
the host variables will be unpredictable.
DB2 provides the use of cursors to process SETS of data. The cursor is used to retrieve all
rows in the SET one by one. Each fetch of the cursor retrieves the next row in the set of
data that meets the condition.

SELECT WITH FETCH

DEFINE A CURSOR
EXEC SQL
DECLARE CURSOR K10 FOR
SELECT SNAME, CITY
FROM S
WHERE STATUS < 30
END-EXEC

DEFINITION

OPEN THE CURSOR

EXEC SQL
OPEN K10
END-EXEC

FETCH RESULT ROWS ONE AT A TIME

EXEC SQL
FETCH K10 INTO :SUPNAME, :CITY
END-EXEC

EXECUTION

CLOSE CURSOR WHEN FINISHED

EXEC SQL
CLOSE K10
END-EXEC

THE DECLARE CURSOR STATEMENT RELATES A CURSOR TO A SELECT

STATEMENT
OPEN CURSOR STATEMENT GENERATES EXECUTABLE CODE.
FETCH CURSOR STATEMENT RETRIEVES A ROW FROM A SET OF DATA
CLOSE CURSOR STATEMENT DEACTIVATES THE CURSOR

Select With Fetch

DECLARE cursor statement defines a cursor with the specified name with an associated
query as specified by the select that forms part of that declare. The declare cursor statement
is not an executable code, but a purely declarative statement. A program can use any
number of DECLARE CURSOR statements, and each of which must be of a different
name.
Open cursor statement generates executable code. The select clause used in the DECLARE
CURSOR statement is effectively executed when the cursor is opened. This is done using
the current value of the host variable (if used).
This executable code will allow subsequent fetch statements to access the set of data that
meets the definition of the DECLARE CURSORs underlying SELECT statement.
Opening the cursor is a must and DB2 will not open it on the first fetch.
The FETCH statement will retrieves a row of data from the set made accessible by the
open statement. Data is retrieved in host variables specified after the INTO clause of
FETCH statement. After the first FETCH statement which retrieves the first row, the
cursor will be advanced to the next row during the second FETCH operation and then
assigns values from that row to host variables.
After retrieving the required rows the CURSOR can be closed. The CLOSE CURSOR
statement releases the cursor from the set of data.

UPDATE USING A CURSOR

EXEC SQL
DECLARE CURSOR K10 FOR
SELECT SNAME, CITY
FROM S
WHERE STATUS = :RANK
FOR UPDATE OF CITY
END-EXEC
EXEC SQL
OPEN K10
END-EXEC
EXEC SQL
FETCH K10 INTO :SUPNAME, :CITY
END-EXEC
EXEC SQL
UPDATE S
SET CITY = :NEWCITY
WHERE CURRENT OF K10
END-EXEC
EXEC SQL
CLOSE K10
END-EXEC

DECLARE CURSOR HAS AN ADDITIONAL FOR UPDATE OF

CLAUSE.

DECLARE, OPEN, FETCH and CLOSE CURSOR LOGIC IS NOT CHANGED

UPDATE WHERE CURRENT OF cursor name UPDATES THE ROW
PRESENTLY IDENTIFIED BY THE CURSOR

Update Using A Cursor

The usual logic of cursors is used for updating a row which is present in the set of data,
satisfying the select statement in the DECLARE CURSOR. The columns that may be
updated are specified using FOR UPDATE OF clause in the DECLARE CURSOR
statement.
The update operation is done after fetching a row from the SET of data. This type of
update is useful where the retrieved row is required for the program before updating it.
UPDATE WHERE CURRENT OF CURSOR clause updates the row where the cursor is
presently positioned. The next row can be updated only after issuing another FETCH.
Requirement of specifying FOR UPDATE OF clause for updating a table using CURSORS
depends on the pre compiler option given. If pre compiler NOFOR option is specified then
FOR UPDATE OF clause is not required. If NOFOR is not specified FOR UPDATE OF
CLAUSE is required and an attempt to update a column not mentioned in that column will
fail at run time.

DELETE USING A CURSOR

EXEC SQL
DECLARE CURSOR K10 FOR
SELECT SNAME, CITY
FROM S
WHERE STATUS = :RANK
FOR UPDATE OF CITY
END-EXEC
EXEC SQL
OPEN K10
END-EXEC
EXEC SQL
FETCH K10 INTO :SUPNAME, :CITY
END-EXEC
EXEC SQL
DELETE FROM S
WHERE CURRENT OF K10
END-EXEC
EXEC SQL
CLOSE K10
END-EXEC

THE DECLARE, OPEN, FETCH and CLOSE CURSOR LOGIC IS NOT

CHANGED
DELETE WHERE CURRENT OF cursor DELETES THE ROW PRESENTLY
POSITIONED BY THE CURSOR
THIS FORM OF DELETE WILL BE USED IF THE DATA CONTAINED IN A
ROW IS NEEDED BY THE APPLICATION BEFORE IT IS DELETED.

STATIC SQL

PLAN

TO SELECT DATA

PROGRAM
PLAN
* SELECT
CALL
RESULT

SELECT

DB2

TABLE

PROGRAM HANDLES THE RESULT

STATEMENT
PROGRAMMER KNOWS THE SQL STATEMENT TO BE USED
AND ALWAYS DOES THE SAME FUNCTION ON THE SAME
TABLES AND COLUMNS.

BIND

ON ALL SQL STATEMENTS

BEFORE PROGRAM EXECUTION
BUILDS A STORED PLAN

 AUTHORIZATION
HELD BY THE PLAN BINDER

DYNAMIC SQL

PLAN

TO EXECUTE USERS REQUEST

PROGRAM

PLAN

PREPARE

DB2

EXECUTE
CALL

EXECUTE

TABLE

RESULT
PROGRAM HANDLES THE RESULT

STATEMENT
SQL STATEMENTS ARE PREPARED AT RUN TIME AND
EXECUTED. TARGET TABLE OR COLUMN CAN BE SPECIFIED
AT RUN TIME

BIND

ON SINGLE STATEMENT
AT STATEMENT EXECUTION
ACCESS STRATEGY NOT SAVED

AUTHORIZATION

HELD BY THE PROGRAM EXECUTOR

Example For Dynamic SQL

01 STMT
49 LEN PIC S9(4) COMP.
49 TEXT PIC X(200).
01 X PICX(6).
01 Y PICX(6).
01 Z PIC X(6).

EXEC SQL DECLARE SS STATEMENT END-EXEC

EXEC SQL DECLARE CC CURSOR FOR SS END-EXEC

MOVE WS-TEXT TO TEXT:

MOVE LENGTH-OF-TEXT TO LEN
(SELECT CL1,CL2,CL3 FROM T1 WHERE CL1 = 1932)
EXEC SQL PREPARE SS FROM :STMT END-EXEC
EXEC SQL OPEN CC END-EXEC
EXEC SQL FETCH CC INTO :X, :Y, :Z END-EXEC
( repeat fetch until sqlcode 100)

.
EXEC SQL CLOSE CC END-EXEC

Example For A Db2 Application Program

IDENTIFICATION DIVISION.
******************************************************************
* IDENTIFICATION DIVISION.
*
*
*
******************************************************************
PROGRAM-ID. SXD11018.
******************************************************************
*
*
******************************************************************
ENVIRONMENT DIVISION.
******************************************************************
*
*
* ENVIRONMENT DIVISION.
*
*
*
******************************************************************
CONFIGURATION SECTION.
******************************************************************
*
* CONFIGURATION SECTION.
*
*
*
******************************************************************
SPECIAL-NAMES.
DECIMAL-POINT COMMA.
INPUT-OUTPUT SECTION.
******************************************************************
*
*
* INPUT-OUTPUT SECTION.
*
*
*
******************************************************************
FILE-CONTROL.
DATA DIVISION.
******************************************************************
*
*
* DATA DIVISION.
*
*
*
******************************************************************
FILE SECTION.
******************************************************************
*
*
* FILE SECTION.
*
*
***********************************************************

WORKING-STORAGE SECTION.
******************************************************************
*
*
* WORKING-STORAGE SECTION.
*
*
*
******************************************************************
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-**
*
DB2-COMMUNICATION-AREA DECLARATIONS
*
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*EXEC SQL INCLUDE SQLCA
END-EXEC.
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-**
*
SQL-TABLE DECLARATIONEN
*
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*EXEC SQL INCLUDE VT11018
( OUTPUT OF DCLGEN )
END-EXEC.
/

( WORKING STORAGE
VARIABLES )

LINKAGE SECTION.
******************************************************************
* L I N K AG E S E C T I O N
*
******************************************************************
*
.

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-**
*
SQL-CURSOR DECLARATIONS
*
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*EXEC SQL
DECLARE T11018_ALL_ROW CURSOR FOR
SELECT
TAB_INDEX
, DAHWV
, DAHWB
, DART
FROM
VT11018
ORDER BY TAB_INDEX
END-EXEC.
PROCEDURE DIVISION
******************************************************************
*
*
* PROCEDURE DIVISION
*
*
*
******************************************************************
*
******************************************************************
******************************************************************
*
.
.

/
******************************************************************
8100-OPEN-T11018-CURSOR SECTION.
******************************************************************
EXEC SQL
OPEN T11018_ALL_ROW
END-EXEC
******************************************************************
.
.

..

8100-FETCH-T11018-ROW SECTION. ( THIS SECTION SHOULD BE IN A

LOOP TO FETCH ALL ROWS)
******************************************************************
EXEC SQL
FETCH T11018_ALL_ROW
INTO
:TAB-INDEX
, :DAHWV
, :DAHWB
, :DART
END-EXEC
******************************************************************
.

.
8100-CLOSE-T11018-CURSOR SECTION.
******************************************************************
EXEC SQL
CLOSE T11018_ALL_ROW
END-EXEC
STOP RUN.

7.

Program Preparation

This chapter explains the steps involved in executing a db2 application program.
Control information required for each step and examples are also provided
The topics discussed in this chapter are
7.1.

Steps In Program Preparation

7.2.

DCLgen (Declarations Generator )

7.3.

Precompile

7.4.

Bind

7.4.1. Binding A DBRM To A Package

7.4.2. Binding An Application Plan
7.5.

Compile And Linkedit

7.6.

Overview Of DB2 Application Program Preparation And Execution

7.7.

Associating Load Modules And Packages

PROGRAM PREPARATION
STEPS IN PROGRAM PREPARATION

DCLGEN
PROGRAM PRE COMPILE
BIND
COMPILE AND LINK EDIT
EXECUTION

DB2 APPLICATION PROGRAM SHOULD GO THROUGH ALL THE ABOVE

STEPS.

DCLGEN (DECLARATIONS GENERATOR )

INPUT

OUTPUT
DECLARE TABLE
STATEMENT

CONTROL STATEMENTS
WHICH INCLUDE TABLE OR
VIEW NAME AND NAME OF
THE HOST LANGUAGE

DCLGEN
HOST LANGUAGE
DATA STRUCTURE

DCLGEN USES DB2

CATALOG TABLES

DCLGEN SHOULD BE DONE BEFORE PRE COMPILING THE SOURCE

MODULE
DCLGEN GENERATES BOTH DECLARE TABLE STATEMENT AND
DATA STRUCTURE IN THE SPECIFIED HOST LANGUAGE.
DECLARE TABLE STATEMENT USED FOR APPLICATION PROGRAM
DOCUMENTATION AND PRELIMINARY SYNTAX CHECKING FOR THE
PRE COMPILER
USE DCLGEN OR CODE DECLARE TABLE AND HOST LANGUAGE
DATA STRUCTURE MANUALLY

DCLGEN (Declarations Generator )

The DECLARATIONS GENERATOR supplied with DB2 produces DECLARE TABLE
statements for tables and views. It also generates host language data structure that
corresponds to the DB2 tables and views to be accessed by the program. The output of
DCLGEN will be created in a partition dataset member This member should be included in
the working storage section of the application program using INCLUDE statement.
The purpose of having DECLARE TABLE statement in the source code is to allow the pre
compiler to check the syntax of the SQL statements referring to the tables and views.
Having the table and view declarations in the source code allows the pre compiler to
uncover syntactical errors, which otherwise would not be found until DB2 binds the plan or
package.
Host language data structure produced by DCLGEN, is the HOST LANGUAGE
DECLARATIONS of tables or views. These can be used as host variables in the application
program. DCLGEN prevents us from manually coding host variable declarations and
declare table statements.

EXAMPLE
INPUT FOR DCLGEN
DCLGEN TABLE(S)
LIBRARY(NTCI.PTAB.DCL(S))
ACTION(REPLACE)
LANGUAGE(COBOL)
STRUCTURE(S)
QUOTE
OUT PUT FROM DCLGEN IN NTCI.PTAB.DCL(S)
******************************************************************
*
DCLGEN TABLE(S)
*
*
LIBRARY(NTCI.PTAB.DCL(S))
*
*
ACTION(REPLACE)
*
*
LANGUAGE(COBOL)
*
*
STRUCTURE(S)
*
*
QUOTE
*
*
IS THE DCLGEN COMMAND THAT MADE THE FOLLOWING
*
STATEMENTS
*
******************************************************************
EXEC SQL DECLARE S TABLE
(S#
CHAR(5) NOT NULL,
SNAME
CHAR(20),NOT NULL WITH DEFAULT
STATUS
SMALLINT NOT NULL WITH DEFAULT,
CITY
CHAR(15) NOT NULL WITH DEFAULT
) END-EXEC
******************************************************************
* COBOL DECLARATION FOR TABLE VT11010
*
******************************************************************
01
S.
10 S#
PIC X(5).
10 SNAME
PIC X(20).
10 STATUS
PIC S9(4) COMP.
10 CITY
PIC X(15).
******************************************************************
* THE NUMBER OF COLUMNS DESCRIBED BY THIS DECLARATION IS 4*
******************************************************************

PRECOMPILE

SOURCE MODULE

SOURCE LISTING
DIAGNOSTICS
CROSS REFERENCES

PRE COMPILE

MODIFIED
SOURCE CODE
(CONTAINS
CONSISTENCY
TOKEN)

DBRM
(CONTAINS
CONTOKEN )

PRE COMPILER INPUT

HOST LANGUAGE PROGRAM WHICH CONTAINS SQL STATEMENTS
SQL STATEMENTS ARE COMMENTED OUT ARE REPLACED BY HOST
LANGUAGE CALL STATEMENTS
PRE COMPILER OUTPUT
MODIFIED SOURCE CODE WHICH CONTAINS PRE COMPILER
CONSISTENCY TOKEN (CONTOKEN) WHICH IS AN INTERNAL
REPRESENTATION OF TIMESTAMP.

DATABASE REQUEST MODULE WHICH CONTAINS EDITED

FORM OF SQL STATEMENTS AND CONSISTENCY TOKEN

ERROR MESSAGES AND OTHER DIAGNOSTIC INFORMATION

Pre Compile
DB2 application programs include SQL statements and you cannot compile those programs
until you change the SQL statements into the language recognized by your compiler. Hence
you must use a pre compiler whose function is to analyze the host language source module,
stripping all SQL statements it finds and replacing them by host language call statements.
PRE COMPILER also creates a DBRM from the SQL statements it encountered. DBRM
communicates your SQL requests to DB2 during BIND process.
One DBRM is created for a program, the name of the DBRM and program will be the
same. DBRM contains SQL statements and host variable information extracted from the
source program. The DBRM also contains a consistency token that identifies the program
and ties the DBRM to the modified source statements by using the same consistency token
present in the modified source code.
The pre compiler does a syntax checking using the definition given by the DECLARE
TABLE statement on all SQL statements in the program. Pre compiler gives error ,
warnings and other diagnostic messages depending on the result of syntax checking .

BIND

DBRMS DIRECTLY BOUND TO THE PLAN

INPUT

OUTPUT

DBRM1
BIND

PLAN

DBRM2

DBRMS BOUND TO THE PACKAGE AND PACKAGES BOUND TO THE PLAN

DBRM1

BIND

PACKAGE1
BIND

DBRM2

BIND

PACKAGE2

THERE ARE TWO TYPES OF BIND

BIND PACKAGE
BIND PLAN

PLAN

BIND

BIND CONVERTS HIGH LEVEL SQL STATEMENTS PRESENT IN DBRM

TO EXECUTABLE MACHINE INSTRUCTION
BIND THE DBRM TO A PLAN OR PACKAGE BEFORE EXECUTING THE
APPLICATION PROGRAM.
BIND INVOLVES

CHECKING THE STATUS OF THE REFERENCED OBJECTS TO

DETERMINE IF AN SQL STATEMENT IS EXECUTABLE

CREATING AN OPTIMIZED FORM OF THE SQL STATEMENTS

FOR IMPROVED PERFORMANCE AND COMPACTNESS

IDENTIFYING MOST EFFICIENT PATH FOR EACH SQL

STATEMENT

BIND CHECKS THE AUTHORIZATION TO PERFORM

OPERATIONS REQUESTED BY THE SQL STATEMENT

THE CONSISTENCY TOKEN PRESENT IN THE DBRM WILL BE CARRIED

FORWARD TO PACKAGE AND PLAN

Bind
The out put of the precompiler contains extracted SQL statements from the source module.
But DB2 has to do the syntax checking and should determine the best access strategy for
each SQL. DB2 records all these information in the PACKAGE.
If a DBRM is thought of as an SQL source module then the package produced by binding
that DBRM can be thought of as the corresponding object module. In other words, a
package consists of a set of internal control structures , representing the compiled form of
the original SQL statements in the corresponding DBRM
Each package is assigned to exactly one collection when it is bound. When you bind a
package, you specify the collection to which the package belongs. The collection is not a
physical entity, and you do not create it; the collection name is merely a convenient way of
referring to a group of packages. Usually all of the packages used in a given application
would be assigned to the same collection
There are two types of bind. First method is to bind DBRMS to an application plan. In the
second method DBRMS are bound to the package and packages to the PLAN. Plan
contains pointers to the packages.
Bind examines the SQL statements in the input DBRM an checks whether all the necessary
elements of a statement are present and syntactically correct. It also checks that the
individual binding the plan is authorized to perform the operations requested by the SQL
statement.
Optimizer component of bind interrogates catalog tables, chooses the access path and
generates the machine code calls needed to execute the statement.

BINDING A DBRM TO A PACKAGE

DBRM

CATALOG

PACKAGE BIND

LISTING
DIAGNOSTICS

PACKAGE

EACH PACKAGE CONTAINS ONLY ONE DBRM.

PACKAGES ARE OPTIONAL, ALL MEMBERS CAN BE DIRECTLY BOUND
TO A SINGLE PLAN

INPUT TO THE PACKAGE BIND IS DBRM AND OUTPUT IS THE PACKAGE.

PACKAGE MUST BE BOUND TO THE PLAN
CON-TOK FROM THE DBRM WILL BE CARRIED ON TO PACKAGE

Binding A DBRM To A Package

Bind Package Is Explained Using The Following Example
BIND PACKAGE
MEMBER
OWNER
QUALIFIER
VALIDATE
EXPLAIN
ISOLATION
RELEASE
ACTION

(EWSK)
(SXD11010)
(AM1240)
(SYSADMK )
(BIND)
(NO)
(CS)
(COMMIT)
(REPLACE)

When you BIND a package specify the collection to which the package belongs. The
collection is not a physical entity and you do not create it.
In the example collection name is EWSK and the package name produced by this bind is
EWSK.SXD11010
The owner of the package is AM1240.The owner of an object has all privileges on that
object. If no value is entered the default is the use of the primary AUTHID of the binder.
The qualifier parameter will be used as the qualifier of all unqualified tables and views
referenced in the application program.
Validate parameter is used to specify the method DB2 will use to validate the package or
plan. Validation can be performed during bind or when the program runs, indicated by the
choices of BIND or RUN with the VALIDATE parameter.
VALIDATE (RUN) is the default value.
EXPLAIN indicates whether to provide information to the user about the access strategy
decided by the bind. Default is EXPLAIN(NO)
ACTION parameter indicates whether the package is new or a replacement. ACTION
(ADD) will result in an error if the object already exists. The default value of REPLACE
will add the object or replace it if it already exists.
ISOLATION specifies the locking strategy while using cursors. Default is RR (repeatable
read) , can be over ridden using CS (cursor stability): For more information on
ISOLATION parameter please refer chapter 9
RELEASE parameter indicates when the locks should be released while using a cursor.

BINDING AN APPLICATION PLAN

LIST OF PACKAGES
OR
DBRMS
OR
BOTH

PLAN BIND

LISTING
DIGNOSTIC
MESSAGES

PLAN

DBRMS CAN BE BOUND TO A PLAN

A LIST OF PACKAGES CAN BE BOUND TO A PLAN
DBRMS AND PACKAGES TOGETHER CAN BE BOUND TO A SINGLE
APPLICATION PLAN
PLAN CONTAINS POINTERS TO THE PACKAGES

Binding An Application Plan

BIND PLAN IS EXPLAINED USING THE FOLLOWING EXAMPLE
BIND PLAN (A610 )
MEMBER(W41600, w710009)
OWNER(SYSADM)
QUALIFIER(SYSADM)
PKLIST(EWS.A61000
EWS.SXD11053 ,
EWSA.ANLZDB2)
ACTION(REPL) RETAIN
VALIDATE(BIND)
ISOLATION(CS)
CACHESIZE(0)

In the above example name of the plan is A610, two DBRMS, and three packages are
bound to the plan.
Parameters used in this example have the same meaning as in the bind package statement.
The parameter ACTION indicates whether a new package is to be added or replaced.
ACTION(REPL)RETAIN can be used only for BIND PLAN. RETAIN parameter
preserves EXECUTE privileges when you replace the plan. If RETAIN is specified then
those users who had been using the plan earlier will have the authority to use it after the
bind.
Determines the size (in bytes) of the authorization cache acquired in the EDM pool for the
plan. At run time, the authorization cache stores user IDs authorized to run. Consulting the
cache can avoid a catalog lookup for checking authorization to run the plan.

COMPILE AND LINKEDIT

MODIFIED
SOURCE MODULE
(CONTAINS CONTOKEN)

COMPILER

OBJECT MODULE

LINK EDITOR

OTHER
OBJECT MODULES

LOAD MODULE
(CONTAINS CONTOKEN)

MODIFIED SOURCE FROM THE PRE COMPILER IS COMPILED USING

HOST LANGUAGE COMPILER WHICH PRODUCES OBJECT MODULE.
LINKAGE EDITOR IS USED TO MAKE AN EXECUTABLE LOAD MODULE
WHICH CONTAINS MAIN PROGRAM, SUB PROGRAMS, LANGUAGE
INTERFACE ROUTINES, AND SYSTEM ROUTINES.
TIMESTAMP PRESENT IN THE MODIFIED SOURCE IS CARRIED ON TO
THE LOAD MODULE

OVERVIEW OF DB2 APPLICATION PROGRAM

PREPARATION AND EXECUTION
SOURCE
MODULE
MODIFIED
SOURCE
MODULE

PRECOMPILER

DBRM

COMPILER

BIND

OBJECT
MODULE

PACKAGE

LINKAGE
EDITOR

LOAD
MODULE

OTHER
OBJECT
MODULES

LIST OF
PACKAGES

LOAD MODULE
PLAN / PACKAGES

MAIN MEMORY

BIND

APPLICATION
PLAN

ASSOCIATING LOAD MODULES AND PACKAGES

CT

CT
PRE COMPILE

MODIFIED
SOURCE

DBRM

CT

CT

LOAD
MODULE

PLAN
CONTOKENS
SHOULD MATCH
TO EXECUTE

Associating Load Modules And Packages

During PRECOMPILE a CONSISTENCY TOKEN is placed in both the modified source
and the DBRM. When DBRM is directly bound to the plan then the CONSISTENCY
TOKEN is carried on to the plan from the DBRM. When DBRM is bound to the package
then the same CONSISTENCY TOKEN will be present in the package and plan contains
pointers to the package. An executable load module can be linked to its plan or package
using the CONSISTENCY TOKEN field present in them. CONSISTENCY TOKEN is
used to ensure that the resultant load module and package were derived from the same
original source.
Assume that the plan of an application program contains only DBRMS. When this program
executes the CONSISTENCY TOKEN present in the load module and the corresponding
DBRM should be the same . Otherwise the program will not be executed and gives an
SQLCOSE OF -805.
Now the DBRM of an application program is bound to the package and a set of packages
are bound to the plan. When this program is executed the load module and the package
which the program wants to execute should have the same CONSISTENCY TOKEN,
failure of this will give an SQLCODE -805.

8.

Security Features

DB2 provides data integrity by using different security mechanisms. Data access is
controlled by using authorization IDs and privileges given to that ID. This chapter briefly
explains these security features and DB2s referential integrity support.
8.1.

Privileges

8.2.

Referential Integrity

8.2.1. DB2 Enforcement Of Referential Integrity

8.2.2. Referential Integrity Enforcement Rules
8.2.3. Example For Referential Integrity Violation
8.3.

Database Recovery In Case Of Failure

8.3.1. Unit Of Recovery

8.3.2. Data Recovery

SECURITY FEATURES

SECURITY IN DATABASE MEANS THE PROTECTION OF ALL OBJECTS

IN DATABASE AGAINST UNAUTHORIZED DISCLOSURE, ALTERATION
OR DESTRUCTION.
DB2 USES TWO INDEPENDENT FEATURES TO PROVIDE SECURITY TO
ITS OBJECTS

THE AUTHORIZATION SUB SYSTEM

THE VIEW MECHANISM

THE SYSTEM ADMINISTRATOR PROVIDES AUTHORIZATION IDS TO

ITS USERS. THIS ID IS USED TO LOG ON TO THE SYSTEM AND THE
ACTIVITIES USER CAN PERFORM IN DB2 DEPENDS ON THE
PRIVILEGES GRANTED TO THIS ID.
THERE ARE TWO TYPES OF AUTHORIZATION IDS

PRIMARY AUTHORIZATIONS IDS

SECONDARY AUTHORIZATION IDS

VIEW MECHANISM CAN BE USED TO PROTECT SENSITIVE DATA FROM

USERS BY CREATING A VIEW ON COLUMNS OF THE BASE TABLE THAT
ARE NOT SENSITIVE. NOW THE USER ARE ALLOWED TO USE THIS
VIEW , PROTECTING SENSITIVE DATA.

Security Features
Authorization IDS are provided to users of DB2 to prevent unauthorized use of DB2
objects. Users are known to DB2 by this authorization identifier given by the system
administrator and it is users responsibility to identify themselves to by supplying that ID
when they sign on to the system.
Two types of authorization IDs DB2 uses to control and track system utilization are
primary and secondary AUTHIDs.
Each individual is assigned a PRIMARY AUTHID that is used to sign on to the system.
Generally it is the primary authorization ID that identifies a process in DB2. When
unqualified tables, views, indexes are used in the application program, this AUTHID
becomes the qualifier of the object. The operations which can be performed by this
AUTHID depends on the privileges granted to it by system administrator or other users.
System administrator may provide a secondary authid to a group of developers who need a
set of privileges associated with that id. Now the user has all the privileges of both primary
and secondary authid. The secondary authorization ID is optional .
A user can use DB2 under either a primary AUTHID or secondary AUTHID or both.
Suppose you are using primary id and want to shift to secondary authid for some operation
to perform . This shift can be achieved by using the command
SET CURRENT SQLID = (name of secondary id).

PRIVILEGES

SYSTEM ADMINISTRATOR DECIDES WHICH SPECIFIC PRIVILEGE

SHOULD BE GIVEN TO WHICH SPECIFIC USERS
DATABASE ADMINISTRATOR HAS IMPLICIT RIGHT TO GRANT OR
REVOKE PRIVILEGES FROM THE USER.
DATABASE ADMINISTRATOR CAN GIVE INDIVIDUAL OR A
COLLECTION OF PRIVILEGES TO USERS
CREATOR OF AN OBJECT HAS IMPLICIT RIGHT TO DROP OR ALTER
THE OBJECT

SYSTEM ADMINISTRATOR HAS THE AUTHORITY TO TAKE ANY

POSSIBLE ACTION WITHIN THE DB2 SYSTEM.

PRIVILEGES ARE GIVEN AND TAKEN BACK USING GRANT AND

REVOKE COMMANDS

Privileges
SYSTEM ADMINISTRATOR has the authority on all objects in DB2. In order to
perform any operation in DB2, the user must hold appropriate privilege for the operation
and the object in question, Otherwise the request will be rejected. System administrator
grants single or group (bundled) privileges to users.
Group of privileges (BUNDLED PRIVILEGES) used in DB2 are shown below
SYSADM
SYSTEM ADMINISTRATOR AUTHORITY allows the holder to execute any operation
that the system supports.
SYSCTRL
SYSTEM CONTROL AUTHORITY allows the holder to execute any operation, except
for operation that access database contents.
Example: CREATE STOGROUP
DBADM
DATABASE ADMINISTRATOR AUTHORITY on a specific database allows the holder to
execute any operation that the system supports on the database
Example: SELECT, UPDATE etc
DBCTRL
DATABASE CONTROL AUTHORITY on a specific database allows the holder to execute
any operation that system supports except for data manipulation operation
Example: RECOVER DATABASE
DBMAINT
DATABASE MAINTENANCE AUTHORITY on a specific database allows the holder to
execute read only maintenance functions on the database
Example: DISPLAY DATABASE, START DATABASE etc
SYSOPR
SYSTEM OPERATOR AUTHORITY allows the holder to carry out console operator
functions on the system.
Example: STARTING AND STOPPING SYSTEM TRACE ACTIVITIES
PACKADM
package administrator authority on a specific collection allows the holder to create
packages in that collection and gives the holder all package privileges in that collection

REFERENTIAL INTEGRITY
DB2S REFERENTIAL INTEGRITY SUPPORT

THERE ARE TWO GENERAL INTEGRITY RULES IN DB2 FOR

MAINTAINING DATA INTEGRITY

ENTITY INTEGRITY RULE

NO COMPONENT OF PRIMARY KEY OF A BASE TABLE IS
ALLOWED TO ACCEPT NULLS.

REFERENTIAL INTEGRITY RULE

REFERENTIAL INTEGRITY RULE STATES THAT ALL NON
NULL VALUES OF FOREIGN KEY MUST APPEAR AS A
VALUE OF THE PRIMARY KEY OF SOME SPECIFIC TABLE

BY DEFINITION FOREIGN KEY IN ONE TABLE MATCHES A PRIMARY

KEY.

A PRIMARY KEY MUST BE UNIQUE AND CANNOT BE NULL

A FOREIGN KEY VALUE MUST MATCH A PRIMARY KEY VALUE OR BE

NULL

DB2S Referential Integrity Support

Referential integrity consists of a set of rules used in DB2 to provide accuracy , validity or
correctness of data in database. Maintaining integrity is of paramount importance and this
task is handled by the system rather than the user . For this the system needs to be aware of
integrity rules, it should monitor all operations and should ensure that they do not violate
any of those rules.
DB2 supports ENTITY INTEGRITY RULE by enforcing the programmer to make the
column declaration of the primary key not null. If the primary key is composite then all the
columns in that composite key should be declared as not null. The justification for this is
basically that the primary key values in base tables serve to identify entities in the real
world. Primary keys are used for direct row level retrieval and relating one table to another
in relational database. Therefore an unknown value in primary column will be meaningless.
DB2 enforces that values of a given foreign key must match the values of the
corresponding primary key. But the converse is not a requirement. ie the primary key
corresponding to some given foreign key might contain a value that currently does not
appear as a value of that foreign key. Table which contains the primary key is the parent
table and table containing foreign key is the dependent table.
This referential integrity rule can be violated during data manipulation like update, delete,
insert. DB2 will monitor all operations and it will not allow any violation in referential
integrity rules.

DB2 ENFORCEMENT OF REFERENTIAL INTEGRITY

DB2 ENFORCES REFERENTIAL CONSTRAINTS WHEN

AN INSERT STATEMENT IS APPLIED TO THE DEPENDENT

TABLE

AN UPDATE STATEMENT IS APPLIED TO A FOREIGN KEY OF A

DEPENDENT TABLE OR AN UPDATE OF THE PRIMARY KEY OF
THE PARENT TABLE

A DELETE STATEMENT IS APPLIED TO A PARENT TABLE

AN INSERT INTO A PRIMARY KEY TABLE CANNOT VIOLATE

REFERENTIAL INTEGRITY AND NO CHECKING IS REQUIRED
DELETION OF A FOREIGN KEY VALUE CANNOT VIOLATE
REFERENTIAL INTEGRITY AND NO CHECKING IS REQUIRED

REFERENTIAL INTEGRITY ENFORCEMENT RULES

INSERT RULE

THE INSERTION OF ANY FOREIGN KEY VALUE IN THE

DEPENDENT TABLE IS ALLOWED ONLY IF THE MATCHING VALUE
EXISTS IN THE PRIMARY KEY OF THE PARENT TABLE

UPDATE RULE

CHANGES IN THE PRIMARY KEY VALUES ARE ALLOWED ONLY

FOR THOSE VALUES THAT DO NOT HAVE MATCHING FOREIGN
KEY VALUES

UPDATING A FOREIGN KEY VALUE IS ALLOWED ONLY IF SUCH A

VALUE EXISTS IN THE PRIMARY KEY

DELETE RULE

DELETION OF A PRIMARY KEY VALUE WHEN A CORRESPONDING

VALUE EXISTS

WILL BE BARRED IF THE FOREIGN KEY CONSTRAINT HAS

BEEN SPECIFIED AS RESTRICT
WILL CAUSE DELETION OF THE CORRESPONDING FOREIGN
KEY VALUES IF THE CONSTRAINT HAS BEEN SPECIFIED AS

CASCADE
WILL SET THE CORRESPONDING FOREIGN KEY VALUES TO
NULL IF THE CONSTRAINT HAS BEEN SPECIFIED SET

NULL

Referential Integrity Enforcement Rules

When integrity constraints are in effect, a few data manipulations like INSERT, UPDATE,
DELETE) hold the potential for integrity violations or for unpredictable or anomalous
results. DB2 detects some of these situations when it attempts to bind SQL statements that
result in problems. Instead of completing such a bind, DB2 issues an error message.
Insertion of rows containing new primary key values of the parent table do not require
checks of associated foreign keys because additions pose no threat to referential integrity.
Values added to foreign key columns of depended table through inserts, on the other hand
must have corresponding primary key values.
Updating the primary key of the parent table will be restricted if matching foreign keys are
found in dependent table. While updating the dependent table the new foreign key value
must be present in the parent table. Otherwise the request will be rejected.
The delete rule of a referential constraint applies when a row of the parent table is deleted.
The effect of this delete on dependent tables will dependent on the ON DELETE clause of
FOREIGN KEY DEFINITION. The possible specifications of ON DELETE clause are
RESTRICT, CASCADE, SET NULL.
When the deleting a primary key value, assume that the delete rule is RESTRICT, then the
delete is restricted to the case where there are no matching rows in the dependent table. If
matching rows exist then the delete request will be rejected.
The delete rule CASCADE deletes all matching rows. Ie This deletes the row
corresponding to the primary key in parent table and the matching rows in dependent table.
For using the delete rule SET NULL the foreign key must have nulls allowed.
Here row corresponding to the primary key value in the parent table will be deleted and the
foreign key value will be set to null in all matching rows of the primary key in dependent
table.

Example For Referential Integrity Violation

TABLE S
S#
S1
S2
S3
S4
S5

TABLE SP

SNAME
SMITH
JONES
BLAKE
CLARK
ADAMS

STATUS
20
10
30
20
30

CITY
LONDON
PARIS
PARIS
LONDON
ATHENS

S#

S1

P#

S1 P1
S1 P2
S1 P3
S1 P4
P5
100
S1 P6
S2 P1
S2 P2
S3 P2
S4
P2
S4
P4
S4
P5

QTY
300
200
400
200
100
300
400
200
200
300
400

Consider tables S and SP for explaining the implications of REFERENTIAL INTEGRITY

concept
PRIMARY KEY; FOREIGN KEY clauses of the create table statements for these tables are
given below
TABLE SP

TABLE S

PRIMARY KEY ( S#, p# )

FOREIGN KEY SFK ( S# )
REFERENCES S
ON DELETE CASCADE
FOREIGN KEY PFK ( P# )
REFERENCES P
ON DELETE RESTRICT

PRIMARY KEY ( S# )

In this example table S is the parent table and table SP is the dependent table. PFK and SFK
are constraint names that will be used by DB2 in diagnostic messages relating to the foreign
keys S# and P#. If the user does not specify the name DB2 will create one derived from the
name of the first column participating in the foreign key.

Four different cases of potential referential integrity violations for these tables are explained
below
CASE1
An insert on the SP table might introduce a shipment for which there is no matching
supplier. For example
INSERT
INTO SP (S#, P#, QTY )
VALUES ( S20, ) ;
CASE2
An update on column SP.S# of the SP table might introduce a shipment supplier number for
which there is no matching supplier. For example
UPDATE SP
SET S# = S20
WHERE.;
CASE3
A deletion on the S table might remove a supplier for which there exists a matching
shipment. For example
DELETE
FROM S
WHERE S# = S1 ;
CASE4
An update on column S.S# of the S table might remove a supplier for which there exists a
matching shipment . For example
UPDATE S
SET
S# = S20
WHERE S# = S1 ;
In order to enforce referential constraint, the system must deal with all four of these cases.

Explanation
CASE1
This situation is prevented by the virtue of the fact that SP.S# is a foreign key in table SP
matching the primary key S.S# of table S. Such an insert will simply be rejected. But an
insert that introduces a shipment for a supplier that does already exist in table S will be
accepted.
CASE2
In this case also the update will be rejected . But an update that introduces an SP.S# value
that does already exist in table S will be accepted.
CASE3
This situation is handled by the delete rule CASCADE. In general RESTRICT would mean
that the delete will be accepted only if there no such matching shipments. CASCADE
would mean that any such matching shipments will de removed anyway. And SET NULL
would mean that any such matching shipments will not be removed but will be updated so
that they are no longer matching.
CASE4
This situation is handled by the implicit update rule restrict, which means that the update
will be accepted only If no such matching shipments exist.

DATABASE RECOVERY IN CASE OF FAILURE

UNIT OF RECOVERY
POINT OF
CONSISTENCY

NEW POINT OF
CONSISTENCY

OLD

DATA UPDATES

UPDATED

DATA

UNIT OF RECOVERY

DATA
COMMIT

POINT OF
CONSISTENCY

NEW POINT OF
CONSISTENCY
ABNORMAL
TERMINATION

DATA UPDATES

BACK OUT UPDATES

OLD

OLD

DATA

DATA

SUCCESSFUL EXECUTION OF MULTIPLE SQL STATEMENTS MAY BE

NECESSARY TO COMPLETE A LOGICAL UNIT OF RECOVERY
THE APPLICATION PROGRAMMER MUST DETERMINE THE LOGICAL
UNIT OF RECOVERY
DATABASE RECOVERY IS DONE TO THE LAST POINT OF CONSISTENCY

Unit Of Recovery
A unit of recovery is the work done by a DB2 for an application, that changes DB2 data
from one point of consistency to another. A point of consistency is a time when all
recoverable data that an application program accesses is consistent with other data.
A unit of recovery begins with the first change to the data after the beginning of the job or
following the last point of consistency and ends at a later point of consistency. If failure
occurs within a unit of recovery, DB2 backs out any changes to data, returning the data to
its state at the start of the unit of recovery; that is, DB2 undoes the work.

DATA RECOVERY

BACKUP
DATA BASE
UPDATED
DATABASE
COMMIT

UPDATE1

UPDATE2

F
A
I
L
U
R
E

LOG

BACKUP
RECOVERED
DATABASE
RESTORE
UPDATE
LOG

Data Recovery
Backups are maintained by database administration for the data in DB2 subsystem.
Backups may be of the entire database or of one or more tablespaces. In case of failure
database recovery is done using these backups.
All data changes and other significant activities are recorded in logs by DB2. Database
manager may use the backup copies and the logs to re-establish the data base to the last
committed unit of work. Changes that were not committed before the failure are not
recovered in any case
In the given example, the backup is made for a database by DB2. After that the database is
changed , and that is made permanent by issuing a commit. Again the application program
tries to do another update and before its completion a failure occurs
Now we want to recover the data in the database. The database is recovered from he
backup and the changes that were made in that database till the last commit were done. and
the database is restored.

9.

Concurrency

Objects in DB2 can be used by many users at the same time. This is achieved by the using
proper locking system. This chapter explains how DB2 uses these locks and how much
control the programmer has over the concurrency in DB2.
9.1.

Concurrency

9.2.

Locking Strategy

9.3.

Lock Sizes And Types

9.4.

Acquire Release Parameters

9.5.

Isolation Parameter

CONCURRENCY
DB2 ALLOWS ANY NUMBER OF USERS TO ACCESS THE SAME TABLE AT
THE SAME TIME .THIS IS CALLED CONCURRENCY

DB2 USES A CONCURRENCY CONTROL MECHANISM TO AVOID ERRORS

AND INCONSISTENCIES IN DATA WHEN MULTIPLE USERS ACCESS THE
SAME DATABASE.

DB2

MANAGES CONCURRENCY CONTROL WITH SEVERAL TYPES OF

LOCKS THAT RESTRICT ACCESS TO DATA WHILE THEY ARE BEING
USED

CONCURRENCY

CONTROL ELIMINATES THE POSSIBILITY OF ONE

USER CHANGING DATA WHILE ANOTHER IS IN THE PROCESS OF USING
OR CHANGING THEM WHICH CAN LEAD TO ERRORS OR
INCONSISTENCIES IN DATA.

Concurrency
DB2 is a shared system, that is a system that allows any number of users to access the same
database at the same time. Any such system requires some kind of concurrency control
mechanism to ensure that concurrent transactions do not interfere with each other
operation. The absence of such a mechanism will lead to errors and inconsistencies in data
DB2 uses locks to control access to same database by multiple users. The basic idea of
locking is simple, when a transaction needs an assurance that some object that is interested
in, will not change in some unpredictable manner by another user. An exclusive lock on the
object will provide this assurance. The effect of the lock is to lock other transactions out of
the object, and thereby to prevent them from changing it. The first transaction is thus able
to carry out its processing in the certain knowledge that the object in question will remain
in a stable state for as long as the transaction wishes to.
If a transaction requests a lock that is not currently available, then the transaction simply
waits until it gets it. In practice the installation can specify a maximum wait time; If a
transaction ever reaches that threshold in waiting for a lock, it times out and the lock
request is failed.

LOCKING STRATEGY

DB2 DETERMINES ITS LOCKING STRATEGY FOR EACH PROGRAM

WHEN IT BINDS THE APPLICATION PLAN. THE LOCKING STRATEGY
DEPENDS ON SEVERAL FACTORS

THE LOCK SIZES DECLARED IN THE LOCKSIZE PARAMETER

OF CREATE TABLESPACE STATEMENT

TYPE OF SQL STATEMENTS

THE PRESENCE OF EXPLICIT LOCK TABLE STATEMENTS

THE ACQUIRE AND RELEASE OPTIONS CHOSEN BY THE

DEVELOPER AT BIND TIME

THE ISOLATION LEVEL CHOSEN AT BIND TIME.

THE ACCESS PATH CHOSEN

Locking Strategy
DB2 allows multiple users to access same object at same time, but they are controlled by
locks. DB2 selects appropriate locking mechanism based on concurrency control
requirements inherent in the application program. They are called implicit locks.
In addition to the implicit locking mechanism, DB2 provides certain explicit facilities.
These explicit facilities are
1.
2.
3.
4.

LOCKSIZE parameter of CREATE TABLESPACE statement.

ISOLATION parameter
ACQUIRE / RELEASE parameter
SQL statement LOCKTABLE.

Lock table statement can be coded in the application program to acquire an explicit lock on
an object on behalf of the application program. Other parameters are explained in the
following pages.
Example
LOCK TABLE SP IN EXCLUSIVE MODE;

LOCK SIZES AND TYPES

THE SIZE (SCOPE) OF A LOCK ON DATA IN A TABLE DESCRIBES THE

AMOUNT OF DATA CONTROLLED
THE SIZE IS SPECIFIED IN THE LOCKSIZE PARAMETER OF CREATE
TABLESPACE STATEMENT
LOCKSIZE TABLESPACE
THIS MEANS THAT ALL LOCKS ACQUIRED ON DATA IN THE
TABLE SPACE WILL BE AT THE TABLE SPACE LEVEL

LOCK SIZE TABLE

THIS MEANS THAT LOCKS ACQUIRED ON DATA IN THE TABLE
SPACE WILL BE AT THE TABLE LEVEL

LOCKSIZE PAGE
THIS MEANS THAT LOCKS ACQUIRED ON DATA IN THE TABLE
SPACE WILL BE AT TABLE LEVEL

LOCKSIZE ROW
THIS MEANS THAT THE LOCKS ACQUIRED ON DATA IN THE
TABLE SPACE WILL BE AT THE ROW LEVEL

LOCKSIZE ANY
THIS MEANS THAT DB2 WILL DECIDE THE APPROPRIATE
PHYSICAL UNIT OF LOCKING FOR THE TABLESPACE

DB2 ALWAYS REQUIRES A TABLE OR TABLESPACE LOCK BEFORE

ACCESS TO DATA IS PERMITTED .
DB2 MAY USE TABLE OR TABLESPACE LOCK ALONE TO ACCESS DATA
ACCORDING TO THE LOCKSIZE PARAMETER
IF THE LOCKING STRATEGY INCLUDES ROW OR PAGE LOCKING
THEN DB2 LOCKS TABLE OR TABLE SPACE BEFORE LOCKING ROW
OR PAGE

Lock Sizes And Types

Proper selection of lock size is important for better performance and concurrency of the
database. A locksize of tablespace allows a process to lock the tablespace which controls all
tables inside the table space. On the other hand row lock will only lock the row which the
application program wants.
In a simple tablespace locking table space means locking all tables inside that table space
which will reduce concurrency. But a page lock will lock only those rows of tables present
in that page and other users can access other rows in that tablespace concurrently.
Locking larger or smaller amounts of data allows you to trade performance for
concurrency. When you use page or row locks instead of table or tablespace locks
concurrency usually improves, meaning better response times .When you use only table or
tablespace locks then processing time and storage used is reduced. But concurrency is also
reduced , meaning longer response times for some users.
For maximum concurrency, locks on a small amount of data held for a short duration are
better than locks on a large amount of data held for a long duration of time. However
acquiring a lock requires processor time, and holding a lock requires storage. These things
should be kept in mind while deciding a lock size.

ACQUIRE RELEASE PARAMETERS

ACQUIRE AND RELEASE ARE BIND OPTIONS WHICH WILL DETERMINE

WHEN TO ACQUIRE AND RELEASE ITS LOCKS
ACQUIRE ( ALLOCATE )
ACQUIRES THE LOCK WHEN THE PLAN IS ALLOCATED
ACQUIRE (USE )
ACQUIRES THE LOCK WHEN THE OBJECT IS FIRST ACCESSED.
RELEASE (DEALLOCATE)
RELEASES THE LOCKS WHEN THE PLAN IS DE ALLOCATED
RELEASE(COMMIT)
RELEASES THE LOCK AT THE NEXT COMMIT POINT. IF THE
APPLICATION ACCESSES THE OBJECT AGAIN IT MUST ACQUIRE
THE LOCK AGAIN

ISOLATION PARAMETER

ISOLATION PARAMETER SPECIFIES THE LOCKING STRATEGY

FOR CURSORS
THE ISOLATION LEVEL CHOSEN FOR AN APPLICATION CAN
IMPACT BOTH THE LOCK STRATEGY AND THE DURATION OF
ROW LOCKS
THE ISOLATION LEVEL CAN BE SPECIFIED DURING BIND TIME
DIFFERENT ISOLATION LEVELS ARE

REPEATABLE READ(RR)
READ STABILITY(RS)
CURSOR STABILITY(CS)
UNCOMMITTED READ(UR)

DEFAULT VALUE FOR ISOLATION PARAMETER IS REPEATABLE

READ(RR)

ISOLATION SPECIFIES THE DEGREE TO WHICH OPERATIONS ARE

ISOLATED FROM THE POSSIBLE EFFECTS OF OTHER OPERATIONS
ACTING CONCURRENTLY.
BASED ON THIS INFORMATION, DB2 CHOOSES TABLE AND TABLE
SPACE LOCKS AS NONRESTRICTIVE AS POSSIBLE, AND RELEASES S
AND U LOCKS ON ROWS OR PAGES AS SOON AS POSSIBLE.

Isolation parameter
If an SQL statement embedded in a host language program will return multiple rows, the
developer must declare in the program a cursor that presents them to the host program one
at a time, usually with in a repeatedly executed block. DB2 can handle locking for these
cursors using different ISOLATION levels.
ISOLATION(RR)
Repeatable read: A row or page lock is held for all accessed rows,
qualifying or not, at least until the next commit point. If the application process returns to
the same page and reads the same row again, the data cannot have changed and no new
rows can have been inserted.
ISOLATION (RS)
Read stability: A row or page lock is held for pages or rows that are
returned to an application at least until the next commit point. If a row or page is rejected
during stage 2 processing, its lock is still held, even though it is not returned to the
application.
If the application process returns to the same page and reads the same row again, the data
cannot have changed, although additional rows might have been inserted by another
application process. A similar situation can also occur if a row or page that is not returned
to the application is updated by another application process. If the row now satisfies the
search condition, it appears.
ISOLATION(CS)
Cursor stability: A row or page lock is held only long enough to
allow the cursor to move to another row or page. For data that satisfies the search
condition of the application, the lock is held until the application locks the next row or
page. For data that does not satisfy the search condition the lock is immediately released.
ISOLATION(UR)
Uncommitted read: The application acquires few locks and can run
concurrently with most other operations. But the application is in danger of reading data
that was changed by another operation but not yet committed.

10.

DB2I (DB2 Interactive )

DB2I is an interactive facility available in DB2 . Almost all of the functions of DB2 are
available in DB2I , Which can be used by developers .This chapter contains
10.1. DB2I
10.2. SPUFI

DB2I (DB2 INTERACTIVE )

THE DB2 INTERACTIVE INTERFACE IS A TSO ONLINE APPLICATION

WHICH WORKS UNDER THE CONTROL OF ISPF(INTERACTIVE SYSTEM
PRODUCTIVITY FACILITY) WHICH IS A SCREEN /DIALOG MANAGER
FOR TSO
DB2I PROVIDES OPTIONS FOR ALL THE DB2 FUNCTIONS THAT
DEVELOPERS ARE LIKELY TO NEED
DB2 FUNCTIONS THAT ARE AVAILABLE THROUGH DB2I ARE SHOWN IN
THE DB2PRIMARY OPTION MENU

DB2 PRIMARY OPTION MENU

===>
select one of the following db2 functions and press enter
1 SPUFI
2 DCLGEN

(Process SQL statements)

(Generate SQL and sorce language
declarations)
3 PROGRAM PREPARATION
(Prepare a DB2 application program
to run)
4 PRE COMPILE
(Invoke DB2 pre compiler)
5 BIND/REBIND/FREE
(Bind rebind or free appl. Plans or
packages)
6 RUN
(RUN an SQL program)
7 DB2 COMMANDS
(Issue DB2 commands)
8 UTILITIES
(Invoke DB2 utilities)
9 CATALOG VISIBILITY
(Invoke catalog dialogs)
d DB2I DEFAULTS
(set global parameters)
x EXIT
( leave DB2)

DB2I
DB2 provides a number of commands for use in readying a program for execution that
programmers can use to perform the functions required to convert code from source to
executable modules. A convenient alternative is to work through DB2I , which provides a
menu interface to the necessary command processor . If you develop programs using TSO
and ISPF, you can prepare them to run using the DB2 Program Preparation panels. These
panels guide you step by step through the process of preparing your application to run.
There are other ways to prepare a program to run, but using DB2I is the easiest, as it leads
you automatically from task to task.
DB2I primary option menu lists the functions it can perform. The user can select any one of
these functions according to his requirements
SPUFI (SQL processor using file input) supports the online execution SQL statements from
a TSO terminal. SPUFI is intended basically for application programmers who wish to
perform SQL portions of their programs.
The DCLGEN menu allows users to invoke the declarations generator program, which
produces the DECLARE TABLE statements and host language data structure.
Other options like PRECOMPILE, BIND, RUN are used for preparing and executing DB2
application program.
UTILITIES menu helps the user to invoke DB2 online utilities like LOAD, REORG,
RECOVER etc. The necessary utility control statements to direct the operation of the
specific utility must be created before the utility is invoked.

SPUFI

INPUT SQL
STATEMENTS

SPUFI

OUTPUT
RESULTS

DB2

SPUFI PROCESSES INCLUDE

PREPARING INPUT FILE FOR SPUFI

DB2I SUBMITS THE SQL TO DB2

SUCCESSFUL JOBS ARE AUTOMATICALLY COMMITTED

EXAMINING THE RESULTS OF SQL

11.

Utilities

For analyzing and managing physical data present in data base, DB2 offers a number of
utilities . This chapter gives a brief explanation of these utilities
11.1.

Load

11.2.

Runstats

11.3.

Reorg

UTILITIES

DB2 OFFERS A NUMBER OF UTILITIES FOR ANALYZING

AND MANAGING THE PHYSICAL STORAGE OF DATA .
THERE ARE TWO TYPES OF DB2 UTILITIES.

ONLINE UTILITIES

STAND ALONE UTILITIES

DB2 ONLINE UTILITIES RUN AS STANDARD MVS BATCH

JOBS, AND THEY REQUIRE DB2 TO BE RUNNING

THE STAND-ALONE UTILITIES EXECUTE AS BATCH JOBS

INDEPENDENT OF DB2. THEY CAN BE INVOKED ONLY BY
MEANS OF MVS JCL.

IMPORTANT ONLINE UTILITIES ARE

LOAD
REORG
RECOVER
RUNSTATS
IMPORTANT STAND ALONE UTILITIES ARE

DSNJU003
DSNJU004
DSN1CHKR

LOAD

THE LOAD UTILITY LOADS DATA FROM A SEQUENTIAL

FILE TO ONE OR MORE TABLES IN A TABLESPACE

INPUT
DATA

LOAD UTILITY

CORRECT DATA DB2 TABLE

EXAMPLE
CONTROL INFORMATION FOR LOAD UTILITY
LOAD DATA
RESUME NO
LOG NO
inddn ddname
INTO TABLE D2110K.S
( S# POSITION (1)
P# POSITION (6:11)
QTY POSITION (12:15)

CHAR 5
CHAR 6
INTEGER );

Load
Load utility is used to load data from a sequential file to a TABLE in a table space.
In the previous example the TABLE S is loaded from the dataset specified in the load jcl.
ddname of the input dataset that is used in the LOAD JCL is given in INDDN parameter.
Each fields and their positions are also specified.
If the table space already contains data, you can choose whether you want to add new data
to existing data or replace the existing data. This can be done using the parameter
RESUME.
There are three options for RESUME.
RESUME NO: Indicates that the dataset is to be empty. This is the default option.
RESUME NO REPLACE: This causes the utility to over write the existing data.
RESUME YES: This allows the utility to add new rows to the existing table.
The LOG NO command instructs the utility not to record data in the log as they are
loaded .IF the user does not specify LOG NO , the utility records the changes which can be
used for recovery purpose. Default is LOG YES. Recording data in the log during a load
can increase the time required for the load significantly.

RUNSTATS

RUNSTATS UTILITY COLLECTS STATISTICS OF TABLESPACE

AND UPDATES CATALOG TABLES
RUNSTATS SHOULD BE EXECUTED IMMEDIATELY AFTER A
TABLE AND ITS INDEXES ARE CREATED AND THE DATA IS LOADED
DB2 OPTIMIZER CAN TAKE ADVANTAGE OF THESE UPDATED
CATALOG TABLES TO SELECT BEST ACCESS STRATEGY

EXAMPLE
CONTROL INFORMATION FOR RUNSTATS UTILITY
RUNSTATS TABLESPACE D2110K.TABSP
TABLE(ALL)
INDEX(ALL) ;

Runstats
The RUNSTATS utility reads tablespaces and indexes to collect statistics describing the
data. The main statistics collected include number of rows in the table, number of pages
that contain the rows of the table, number of distinct values of indexed column , percentage
of space occupied by rows etc. RUNSTATS utility uses this information to update
CATALOG tables.
In the previous example RUNSTATS utility is used for table space TABSP in database
D2110K. All tables in the tablespace are specified by TABLE(ALL) keyword. Here you can
specify the table name in parentheses after keyword TABLE on which the utility has to run.
You can obtain statistics on all indexes on all tables in the named table space by specifying
INDEX(ALL).The user can get statistics of one more specific indexes by specifying them in
parentheses after the keyword INDEX .
The RUNSTATS utility is useful for finding out the free space remaining in a tablespace and
we use that information for reorganizing the tablespace.

REORG
REORG UTILITY IS USED TO REORGANIZE DATA ON
PHYSICAL STORAGE OF TABLES. DIFFERENT PHASES
OF REORG UTILITY ARE
UNLOADS ROWS FROM A TABLE SPACE
RELOADS ROWS IN A NEATER ARRANGEMENT
WITH FREE SPACE
REBUILDS INDEXES
DOES NOT VALIDATE DATA

CONTROL STATEMENTS FOR REORG UTILITY

REORG TABLESPACE D2110K.TABSP
LOG NO;

Reorg
The REORG online utility reorganizes a table space or index to improve access
performance and reclaim fragmented space. In addition, the utility can reorganize a single
partition of either a partitioned index or a partitioned table space.
REORG utility reorganizes table space or index as you specify in control statements. When
an index space only is reorganized then the data pages are not processed. Only leaf pages
which contains indexes are scanned.
Proper scheduling of reorganizations significantly improves performance of all application
programs.
In the given example REORG utility is run on tablespace TABSP in database D2110K. If
you want to reorganize an index then specify REORG INDEX (index name) . LOG NO
parameter is specified in the example to avoid writing data records in the log while loading
the tablespace.

12.

Advanced DB2

This section explains some of the advanced concepts in DB2. The detailed discussions on
indexes and DB2 locks are included. Advanced topics present in this section are
12.1. More About Indexes
12.1.1. Example Of An Index
12.1.2. Clustered Indexes
12.1.3. Non Clustered Indexes
12.2. Special Registers
12.3. More About Locks
12.3.1. Modes Of Table And Tablespace Locks
12.3.2. Modes Of Row And Page Locking
12.3.3. Lock Mode Compatibility Of Table And Table Space Locks
12.3.4. Lockmode Compatibility Of Row And Page Locks
12.4. Invoking Online Utilities

More About Indexes

DB2 uses indexes not only to enforce uniqueness on column values, as for primary keys,
but also to cluster data, partition tables, and to provide access paths to data for queries.
Understanding some of the structure of DB2 indexes can be important for achieving your
best performance.
A table can have more than one index, and an index key can use one or more columns. An
index key is a column or an ordered collection of columns on which an index is defined. A
composite key is a key built on 2 to 64 columns.
The usefulness of an index depends on its key. Columns that you use frequently in
performing selection, join, grouping, and ordering operations are good candidates for use
as keys
DB2 allows you to enter duplicate values in a key column. If you do not want duplicate
values, use CREATE UNIQUE INDEX. If a table has a primary key, its entries should be
unique. Its uniqueness is enforced by defining a unique index on the primary key columns,

EXAMPLE OF AN INDEX
25

17

25

61

33

86

40

ROOT PAGE

61

70

75

86 INTERMEDIATE
PAGES
LEAF
PAGES

. . 17

. . 25

. . 33

40

. 61

. . 70

. . 75 . . 86

POINTERS TO DATA RECORDS

DATA
PAGES

THE INDEX IS STRUCTURED AS A B-TREE

A RECORD IS LOCATED USING ROOT PAGE, INTERMEDIATE PAGES
AND LEAF PAGES
THE PAGE SIZE OF AN INDEX IS 4KB

Example Of An Index
Indexes in DB2 are based on a structure known as B-Tree. Indexes can have more than one
level of pages. Index pages that point directly to the data in the tables are called leaf pages.
If the index has more than one leaf page, it must have at least one non leaf page, containing
entries that point to leaf pages. If it has more than one non leaf page, the non leaf pages
whose entries point directly to leaf pages are said to be on the first level; there must be a
second level of non leaf pages to point to the first, and so on. The highest level contains a
single page, called the root page.
A typical index is shown in the figure, which is a multilevel, tree structured index with the
property that the tree is always balanced, that is that is all leaf entries in the structure are
equidistant from the root of the tree. and this property is maintained as new entries are
inserted into the tree and existing entries are deleted
The root page is the top of the structure. The root page will contain an entry for each non
leaf or immediate page. The entry in the root page consists of the high value contained on
the intermediate page and a pointer to that page.
The immediate pages are similar in structure to the root page, expect that the range of
values addressed is more specific. The immediate page contains an entry for each of the leaf
pages addressed. The entry consists of the high value contained on the leaf page and a
pointer to this leaf page.
The leaf pages contain the RID, using which the record can be located in a table space. The
leaf pages collectively address the entire table.

CLUSTERED INDEXES

25

17

61

ROOT PAGE

33

40

INTERMEDIATE
PAGES

LEAF
PAGES

DATA
PAGES

A CLUSTERING INDEX IS ONE IN WHICH THE RECORDS ARE

PHYSICALLY STORED IN DATA PAGES IN THE SEQUENTIAL ORDER OF
THEIR INDEX VALUES
HIGH PERFORMANCE BECAUSE OF REDUCED I/O OPERATIONS
EACH TABLE CAN HAVE ONLY ONE CLUSTERING INDEX
CLUSTERING INDEXES ARE EXTREMELY IMPORTANT FOR
OPTIMIZATION PURPOSES. OPTIMIZER WILL TRY TO CHOOSE AN
ACCESS PATH BASED ON THE CLUSTERING INDEX

Clustered Index
A clustering index is one for which the sequence defined by the index is the same as or
close to the physical sequence. The clustering holds the most potential for performance
gains. With a clustering index DB2 takes responsibility for maintaining rows in sequence on
the clustering index columns as long as there is free space. DB2 maintains clustering by
placing inserted rows in the indexed columns sequence on available free space in the data
pages.DB2 can then process the table in that order efficiently. If it is a non clustering index
then DB2 has to reread data pages to identify all the qualifying rows, which will reduce
performance.
Clustering is valuable when DB2 must process a columns values in sequence. The SQL
statements ORDER BY, GROUP BY, and DISTINCT require such processing. If a column
specified in these operation and there is not a suitable index on the column, DB2 must sort
it to put it in sequence before returning even one row to the user. If there is a clustering
index on that column DB2 uses this column to retrieve the rows in sequence and return the
rows immediately one by one.
To specify a clustering index, use the CLUSTER clause in the CREATE INDEX statement.
CREATE INDEX STATEMENT FOR A CLUSTERED INDEX
CREATE UNIQUE INDEX D2110N.I11010U1
ON D2110N.T11010
(TAB_INDEX)
BUFFERPOOL BP0
USING STOGROUP SGDB2O
PCTFREE 20
FREEPAGE 10
PRIQTY 40
SECQTY 20
CLOSE NO
CLUSTER;

NON CLUSTERED INDEXES

25

17

61

ROOT PAGE

33

40

INTERMEDIATE
PAGES

LEAF
PAGES

DATA
PAGES

IN A NON CLUSTERED INDEX THE DATA ROWS DO NOT CORRESPOND

TO THE ORDER OF THE INDEX ENTRIES

SPECIAL REGISTERS

A SPECIAL REGISTER IS A STORAGE AREA THAT DB2 DEFINES FOR A

PROCESS
SPECIAL REGISTERS USED IN DB2 ARE

CURRENT DATE
CURRENT DEGREE
CURRENT PACKAGESET
CURRENT RULES
CURRENT SERVER
CURRENT SQLID
CURRENT TIME
CURRENT TIMESTAMP
CURRENT TIMEZONE
USER

Special Registers
DB2 supports a number of special registers. A special register is a storage area that DB2
defines for a process. Wherever its name appears in an SQL statement, the name is replaced
by the register's value when the statement is executed. Thus, the name acts like a function
that has no arguments. (zero argument built in scalar functions)
You can use the SET statement to change the current value of a register. Where the
register's name appears in other SQL statements, the current value of the register replaces
the name when the statement executes. A commit or rollback operation has no effect on the
values of special registers. Nor does any SQL statement, other than SET statement can
change a register value
CURRENT DATE, specifies the current date. The data type is DATE. The date is derived
by the DB2 that executes the SQL statement that refers to the special register.
Example: Display the average age of employees.
SELECT AVG(YEAR(CURRENT DATE - BIRTHDATE))
FROM DSN8410.EMP;
CURRENT PACKAGESET specifies a string of blanks or the collection ID of the package
or packages that will be used to execute SQL statements. The data type is CHAR(18).
EXAMPLE
Example: For executing a program, identify the collection ID for its package as EWSA.
SET CURRENT PACKAGESET = 'EWSA';
CURRENT SQLID specifies the SQL authorization ID of the process. The data type is
CHAR(8). This SET statement is used to change the authorization id for a process
Example: Set the SQL authorization ID to 'GROUP34' (one of the authorization IDs of the
process).
SET CURRENT SQLID = 'GROUP34';
CURRENT TIME, specifies the current time. The time is derived by the DB2 that executes
the SQL statement that refers to the special register. ,
Example: Display information about all project activities and include the current date and
time in each row of the result.
SELECT DSN8410.PROJACT.*, CURRENT DATE, CURRENT TIME
FROM DSN8410.PROJACT;

CURRENT TIMESTAMP, specifies the current timestamp. The data type is TIMESTAMP.
The timestamp is derived by the DB2 that executes the SQL statement that refers to the
special register.
Example: Display information about the full image copies that were taken
in the last week.
SELECT * FROM SYSIBM.SYSCOPY
WHERE TIMESTAMP > CURRENT TIMESTAMP - 7 DAYS;
CURRENT USER specifies the primary authorization ID of the process. The data type is
CHAR(8).
Example: Display information about tables, views, and aliases that are owned by the
primary authorization ID of the process.
SELECT * FROM SYSIBM.SYSTABLES WHERE CREATOR = USER;

MORE ABOUT LOCKS

MODES OF TABLE AND TABLESPACE LOCKS

IS

INTENT SHARE

IX

INTENT EXCLUSIVE

SHARE

UPDATE

SIX

SHARE WITH INTENT EXCLUSIVE

EXCLUSIVE

IS :
S

THE LOCK OWNER CAN READ ANY DATA IN THE TABLE IF AN

LOCK CAN BE OBTAINED ON THE TARGET ROW OR PAGE

IX :

THE LOCK OWNER CAN READ OR CHANGE ANY DATA IN THE

TABLE PROVIDED AN X LOCK CAN BE OBTAINED ON ROWS
OR PAGES TO BE CHANGED AND A U OR S LOCK CAN BE
OBTAINED ON ROWS TO BE READ

SIX:

THE LOCK OWNER CAN READ ANY DATA IN THE TABLE AND
CHANGE ROWS IN THE TABLE PROVIDED IT CAN OBTAIN AN
X LOCK ON THE TARGET ROW OR PAGE FOR CHANGE. ROW
LOCKS ARE NOT OBTAINED FOR READING.

S :

THE LOCK OWNER CAN READ ANY DATA IN THE TABLE AND
WILL NOT OBTAIN ROW OR TABLE LOCKS

U :

THE LOCK OWNER CAN READ ANY DATA IN THE TABLE AND
MAY CHANGE DATA IF AN X LOCK ON THE TABLE CAN BE
OBTAINED. NO ROW OR PAGE LOCKS ARE OBTAINED

X :

THE LOCK OWNER CAN READ OR UPDATE ANY DATA IN THE

TABLE. ROW LOCKS ARE NOT OBTAINED

Modes Of Table And Tablespace Locks

The locking modes IS IX SIX are used at the TABLE OR TABLESPACE level to support
row or page locks. They permit row or page level locking while preventing more exclusive
locks on the table by other applications.
When an application obtains an IS lock on a table, that application may acquire a lock on a
row or page for read only. Other applications can also read the same row. In addition other
applications can change data on other rows in the table.
An application having an IX lock on a table can change a row after acquiring a row or
page lock. Other applications can READ/CHANGE data on other rows in the table.
When an application has an SIX lock on a table, that application may acquire a lock on a
row for change. Other application can only read other rows in the table.
The modes S U and X are used at the table level to enforce the strict table locking
strategy. No row or page level locking is used by application that possess one of these
locking modes.
When an application obtains an S lock on a table, that application can read any data in that
table. It will allow other applications to obtain locks that support read only requests for any
data in the entire table. No application can change any data in the table until s lock is
released.
When an application obtains a U lock on a table , that application can read any data from
that table and may eventually change data in that table by obtaining an X lock. Other
applications can only read data In that table.
When an application obtains an X lock on a table that application can read and change any
or all data in the table or tablespace . No other application can access data in the entire
table or tablespace for READ or CHANGE

MODES OF ROW AND PAGE LOCKING

ROW/PAGE LOCK

MINIMUM SUPPORTING
TABLE/TABLE SPACE LOCK

SHARE

IS

UPDATE

IX

EXCLUSIVE

IX

S :

THE ROW IS BEING READ BY ONLY ONE APPLICATION AND IS

AVAILABLE FOR READ ONLY BY OTHER APPLICATIONS

U :

THE ROW IS BEING READ BY ONE APPLICATION BUT IS

POSSIBLY TO BE CHANGED BY THAT APPLICATION. THE ROW
IS AVAILABLE FOR READ ONLY BY OTHER APPLICATIONS

X :

THE ROW IS BEING CHANGED BY ONE APPLICATION AND IS

NOT AVAILABLE FOR OTHER APPLICATION

ROW LEVEL LOCKS ARE ONLY REQUESTED BY APPLICATIONS THAT

HAVE SUPPORTING LOCKS AT THE TABLE LEVEL

LOCK MODE COMPATIBILITY OF TABLE AND TABLE

SPACE LOCKS
MODE OF
LOCK A

MODE OF LOCK B
IS

IX

SIX

IS

YES

YES

YES

YES

YES

NO

YES

YES

NO

NO

YES

NO

IX

YES

NO

YES

NO

NO

NO

SIXYES

NO

NO

YES

YES

NO

NO

NO
NO
NO

NO

NO

NO

NO

NO

NO

NO

NO

THE SYMBOLS A AND B IN THE ABOVE DIAGRAM ARE USED TO

REPRESENT TWO DIFFERENT APPLICATIONS
THIS CHART IS USEFUL TO DETERMINE IF TWO APPLICATION CAN
RUN CONCURRENTLY IF THEY ARE ACCESSING SAME TABLE WITH
THE GIVEN LOCK MODE AT THE SAME TIME.

Lock Mode Compatibility Of Table And Table Space Locks

If application A obtains an IS lock against a given table application B could obtain an IS, S,
IX, SIX or U lock against the same table at the same time. However an X lock would not
be permitted at the same time.
This particular example illustrates the concept of IS lock acting as supporting lock for a
lower level of locking. The only table lock that is not compatible is X lock which would
require exclusive lock use of the table. The presence of IS lock indicates that a lower level
of locking is required for this table and X lock is not given.
Study of the chart reinforces the definitions of table and row lock modes presented on
previous pages. Review the row for IX under application A. Assume that application A
obtains an IX lock on table Y. This lock indicates that the application intends to obtain
locks to support change at the row level. The application will allow other rows to be read
and updated but will prevent access to the target rows Examine each of the possible
competing table locks that application B might request
IS-- Intent to lock for read only at row level. This lock is compatible. There may be
contention at the row level if application A is changing the same row that application B
wants to read.
S-- Share lock at the table level. This lock is not compatible since the S lock states that the
entire table is available for read only by the application possessing the lock and all other
applications. The IX lock states that an intent to change data at the row level which
contradicts the requirement for read only. Therefore application B could not obtain the S
lock
IX-- Intent to lock for change at the row level. This lock is compatible. There may be lock
contention at the row level if application A is changing the same row that application B
wants to change.
SIXThe SIX lock states that lock request for changing data may be required at the row
level for the application processing the lock. In addition the rest of the table is available for
read only applications. The IX lock implies change at the row level as well. Application B
could obtain six lock on the table
U-- Read with intent to update. This table level lock states that the application processing
the lock may read any data and may potentially exchange the U lock for an X lock.
However until this exchange is done other applications can obtain locks supporting read
only. Application B would not be able to obtain the U lock at the same time that application
a possessed an IX lock on the same table.
X-- The application possessing this mode of lock on the table requires exclusive use of the
table. No other access is permitted. The ix lock possessed by an application A would
prevent application B from obtaining x lock
The same type of statements can be logically derived for the other rows in the chart

LOCK MODE COMPATIBILITY OF ROW AND PAGE LOCKS

MODE
OF
LOCK A

MODE OF LOCK B
S

YES YES

NO

YES NO

NO

NO

NO

NO

THIS CHART IS USEFUL TO DETERMINE IF TWO APPLICATION CAN

RUN CONCURRENTLY IF THEY ARE ACCESSING SAME ROW WITH THE
GIVEN LOCK MODE AT THE SAME TIME.
CONSIDER AN APPLICATION A HAVING AN S LOCK ON ROW Y. THEN
ANOTHER APPLICATION B CAN ONLY GET LOCKS AND U ON THAT
ROW
IF AN APPLICATION A HAS A SHARE LOCK ON A ROW IT, WILL ALLOW
OTHER APPLICATIONS TO READ THE SAME ROW. SO APPLICATION B
CAN GET AN S LOCK ON THE SAME ROW AT THE SAME TIME
AN APPLICATION B CAN GET AN UPDATE LOCK ON A ROW WHICH IS
CURRENTLY LOCKED BY AN S LOCK OF APPLICATION A. IF THE
APPLICATION B WANTS TO CHANGE THAT ROW DB2 WILL WAIT UNTIL
THE S LOCK IS REMOVED AND IT WILL PROMOTE THE U LOCK TO AN
X LOCK.
NO TWO APPLICATION CAN HAVE AN EXCLUSIVE LOCK ON THE SAME
ROW AT THE SAME TIME
THE SAME TYPE OF STATEMENTS CAN BE LOGICALLY DERIVED
FROM OTHER ROWS OF ABOVE CHART.

Invoking Online Utilities

Creating utility control statements is the first step required to run an online utility. Utility
control statements define the function the utility job performs. Utility control statements are
read from the SYSIN input stream. The SYSIN stream can contain multiple utility control
statements. Control statements are different for each utility and are explained in chapter 11
There are different methods of invoking DB2 online utilities. Commonly used methods are
using DB2I and IBM supplied JCL procedure DSNUPROC.
When you use DB2I (DB2 interactive ) panel for executing a utility you must specify the
name of the utility , the dataset which contains the control information and other datasets
needed by the the utility. Then you can execute the utility from that panel.
DB2 on line utilities can be invoked using DSNUPROC procedure, For that you must write
and submit JCL, in your JCL, the EXEC statement invokes the DSNUPROC procedure.
You must give the control statements as input to DSNUPROC and use the necessary
datasets required for the execution of the utility.

Sample JCL For Invoking Online Utilities

/EX6216X JOB SW301709,'I65000 XT01DL1',
// NOTIFY=&SYSUID,
// MSGCLASS=8,REGION=6M,
// TIME=15,LINES=200
//*
//PROCLIB JCLLIB ORDER=NTTU.SYS.PROCLIB
//*===============================================================
======
//*

//*
DB2 LOAD
//*

//*=============================================================
//*
//*------------------------------------------------------------------*/
//*
T00101
//* -------------------------------------------------------------------/*
//T00101R EXEC DSNUPROC,PARM='DB2O,I650001T001012'
//DSNUPROC.SYSIN DD *
RUNSTATS TABLESPACE D20015.S001501
TABLE (ALL) INDEX (ALL)
/*
//*