You are on page 1of 198

Table Of Contents

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


1.1. USERS OF THE DOCUMENT....................................................................................
1.2. ASSOCIATED DOCUMENTS......................................................................................
2. INTRODUCTION....................................................................................................
2.1. DATABASE MANAGEMENT SYSTEMS (DBMS)............................................................
2.2. TYPES OF DBMS..............................................................................................
2.2.1. Relational DBMS......................................................................................
2.2.2. HIERARCHICAL DBMS...........................................................................
2.2.3. Net Work DBMS.......................................................................................
2.3. SAMPLE DB2 DATABASE.......................................................................................
3. STRUCTURE OF DB2...........................................................................................
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.................................................................................................
4. DATA TYPES..........................................................................................................
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...................................................
5. SQL PROGRAMMING...........................................................................................
5.1. DDL STATEMENTS..............................................................................................
5.1.1. Create Database......................................................................................
5.1.2. Create Table Space.................................................................................
5.1.3. Create Table.............................................................................................
5.1.4. Create View..............................................................................................
5.1.5. Create Index.............................................................................................
5.1.6. Alter Table................................................................................................
5.1.7. Drop.........................................................................................................
5.2. DML STATEMENTS..............................................................................................
©Case Consult (India) Pvt. Ptd. 03/1998 1 DB2 Fundamentals

C:\Documents and Settings\Subramanyam\Local Settings\Temporary Internet Files\OLK142\DB21.doc


5.2.1. Select.......................................................................................................
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.......................................................................................................
5.3. CONTROL STATEMENTS.........................................................................................
5.3.1. Grant........................................................................................................
5.3.2. Revoke.....................................................................................................
5.3.3. Commit.....................................................................................................
5.3.4. Roll Back..................................................................................................
6. PROGRAM STRUCTURE.....................................................................................
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........................................................
7. PROGRAM PREPARATION..................................................................................
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...........................................................
8. SECURITY FEATURES.........................................................................................
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.........................................................................................
9. CONCURRENCY...................................................................................................
9.1. CONCURRENCY...................................................................................................
9.2. LOCKING STRATEGY.............................................................................................
9.3. LOCK SIZES AND TYPES.......................................................................................
9.4. ACQUIRE RELEASE PARAMETERS.............................................................................
9.5. ISOLATION PARAMETER..........................................................................................

2
10. DB2I (DB2 INTERACTIVE ).................................................................................
10.1. DB2I.............................................................................................................
10.2. SPUFI..........................................................................................................
11. UTILITIES.............................................................................................................
11.1. LOAD..............................................................................................................
11.2. RUNSTATS........................................................................................................
11.3. REORG............................................................................................................
12. ADVANCED DB2.................................................................................................
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.................................................................................

©Case Consult (India) Pvt. Ptd. 03/1998 3 DB2 Fundamentals

C:\Documents and Settings\Subramanyam\Local Settings\Temporary Internet Files\OLK142\DB21.doc


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 it’s 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
DB2 FOR OS/2
AIX

DB2 FOR DB2 FOR DB2 FOR


HP-UX SOLARIS WINDOWS /NT

DB2 FOR
SINIX

DB2 FOR
MVS DB2 FOR
OS/400

DB2 FOR
VSE & VM

5
DATA

ATABASE

2.1. Database Management Systems (DBMS)


ROGRAM
DATABASE MANAGEMENT SYSTEMS deal with the problem of storing and
retrieving large amounts of data. DBMS provides an environment to share data
among it’s users. Preserving the correctness of data and restoring the database in
failure are major concerns for DBMS.

DBMS

STORAGE MANAGER

♦ 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. I.e. 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

TABLES TABLE SP

S# SNAME STATUS CITY S# P# QTY

S1 SMITH 20 LONDON S1 P1 300


S2 JONES 10 PARIS S1 P2 200
S3 BLAKE 30 PARIS S1 P3 400
S2 P1 300
S2 P2 400
TABLE P S3 P2 200

P# PNAME COLOR WEIGHT CITY

P1 NUT RED 12 LONDON


P2 BOLT GREEN 17 PARIS
P3 SCREW BLUE 17 ROME
P4 SCREW RED 14 LONDON

7
♦ 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

9
Net Work DBMS

SUPPLIER PART RECORD


RECORD SET 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 CITY S# P# QTY

S1 SMITH 20 LONDON S1 P1 300


S2 JONES 10 PARIS S1 P2 200
S3 BLAKE 30 PARIS S1 P3 400
S4 CLARK 20 LONDON S1 P4 200
S5 ADAMS 30 ATHENS S1 P5 100
S1 P6 100
S2 P1 300
TABLE P S2 P2 400
S3 P2 200
P# PNAME COLOR WEIGHT CITY S4 P2 200
S4 P4 300
P1 NUT RED 12 LONDON S4 P5 400
P2 BOLT GREEN 17 PARIS
P3 SCREW BLUE 17 ROME
P4 SCREW RED 14 LONDON
P5 CAM BLUE 12 PARIS
P6 COG RED 19 LONDON

♦ 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#

11
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 Table space

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 USER’S 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

13
DATABASE D1

TABLE SPACE S1
STORAGE GROUP G1
TABLE T1 TABLE T2
HIERARCHY OF DATA STRUCTURES
VOLUME 1
(DASD)
INDEX X1
STORAGE
GROUP G2
VOLUME 2
INDEX X2 VOLUME2
(DASD)
(3380)

TABLE T3
PARTITIONED PART 1
TABLESPACE
S2 TABLE T3
PART 2

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.

15
DATA BASES TABLESPACE1

INDEX 1 TABLE 1
DATABASE1 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 IT’S 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
VOLUME 1 VOLUME 2
DB2 STORAGE GROUPS

STORAGE GROUP 1

♦ 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

17
TABLE
TABLE 12

TABLE SPACES

TABLESPACE 1

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 VSAM 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 table space belongs and table space
type. As the amount of data in tables grows storage will be acquired from
appropriate storage groups and added to the table space.

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 table space simple, segmented, or partitioned can
drastically affect the performance.

19
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 Table space

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.

21
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 Table space

In a SEGMENTED TABLESPACE the table space 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 table space.

Each segment in the segmented table space contains rows from only one table.
But the table space 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.

23
PARTITIONED TABLESPACE

A—F PARTITION1

G—P PARTITION2

Q—Z 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 Table space

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 it’s 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.

25
TABLES

TABLE S

KEY COLUMNS

S# SNAME STATUS CITY

ROWS S1 SMITH 20 LONDON


S2 JONES 10 PARIS
S3 BLAKE 30 PARIS
S4 CLARK 20 LONDON
S5 ADAMS 30 ATHENS

♦ A RELATIONAL DATABASE STORES DATA IN THE FORM OF


TABLES.

♦ TABLE CONSISTS OF A NUMBER OF RECORDS.

♦ RECORD CONTAINS COLUMNS, ROWS, and 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 VIEW AS THE PROGRAM’S


STORAGE 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 OR VIEWS OR A


COMBINATION OF VIEWS AND TABLES.

♦ VIEWS ARE LOGICAL REPRESENTATION OF DATA THAT EXISTS IN


BASE TABLES.

♦ VIEWS ARE USED FOR SIMPLICITY AND SECURITY.

27
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 IS PARTITIONED.

29
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 table’s columns and a pointer to
the record in a data that matches the index value. DB2 will find data more
efficiently by scanning the index and following the pointer than by scanning the
entire table space.

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.

31
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 BETA’S ALIAS ZTEST to refer to ALPHA’S
SAMPLE table.

SELECT * FROM
BETA.ZTEST

33
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 creates 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.

35
DB2 CATALOG

DB2 CATALOG CONSISTS OF TABLES WHICH CONTAIN

INFORMATION ABOUT OBJECTS DEFINED UNDER THE

DB2 SYSTEM. WHEN A NEW TABLE IS CREATED

4 CATALOG TABLES ARE 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 ID’s THAT 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.
This information is essential, if the system is 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 table space, tables and indexes are in a database
♦ An index’s 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.

37
DB2 DIRECTORY

DB2 DIRECTORY CONTAINS INFORMATION

REQUIRED 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 THE RBA


(RELATIVE BYTE ADDRESS) THE LOG DATASET

♦ SYSTEM UTILITIES TABLE SPACE (SYSUTILX) CONTAINS THE


INFORMATION ABOUT RUNNING UTILITIES

♦ 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.

39
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, and 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.

41
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.

43
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) IF M IS BETWEEN 1 AND 21 THEN IT IS SINGLE


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

FLOAT (M) IF M IS BETWEEN 22 AND 53 THEN IT IS SINGLE


FLOAT 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 5.4E-79 to 7.2E+75.


FLOAT 5.4E-79 to 7.2E+75.

EXAMPLES OF NUMERIC DATA DECLARATION

SPKZ DECIMAL (5, 2)


DRU SMALLINT
HDNR 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 DECIMAL (5, 2) NULL


DRU SMALLINT NOT NULL
HDNR INTEGER NOT NULL WITH DEFAULT

45
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 would automatically place a null in that
position. Suppose that the WEIGHT column in supplier-table database is specified
as NULL, and 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 STRINGS 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 CHAR (20)


NUM VARCHAR (60)
VAR LONG VARCHAR

47
GRAPHIC FORMAT

GRAPHIC (n): FIXED LENGTH STRING HAVE N 16 BIT CHARACTERS


OCCUPYING 2n BYTES

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


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 GRAPHIC (10)


TABIDVARGRAPHIC (80)
TEMP 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 DATE
CCDAT TIME
CCSTAMP TIMESTAMP

49
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
date time value is used in other operations, it is converted to a date time 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 COBOL DECLARATION

CCTEMP SMALLINT 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).

51
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

53
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";

55
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 tablespace 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

57
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 STATUS CITY

S1 SMITH 20 LONDON
S2 JONES 10 PARIS
S3 BLAKE 30 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.

59
PRIMARY KEY

♦ A PRIMARY KEY IS A UNIQUE KEY THAT IS A PART OF THE


DEFINITION OF A TABLE

P# PNAME COLOR WEIGHT CITY

P1 NUT RED 12 LONDON


P2 BOLT GREEN 17 PARIS
P3 SCREW BLUE 17 ROME
P4 SCREW RED 14 LONDON
P5 CAM BLUE 12 PARIS
P6 COG RED 19 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 TABLE SP

S# SNAME STATUS CITY S# P#


QTY

S1 SMITH 20 LONDON S1 P1 300


S2 JONES 10 PARIS S1 P2 200
S2 P1 300
….. ……… … …… …. …. …..

PRIMARY KEY IN S 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.

61
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#)

63
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;

3 ALTER TABLE D2110K.P


PRIMARY KEY (P#);

4 ALTER TABLE D2110K.S


DROP PRIMARY KEY (S#);
DROP

THE DROP STATEMENT DELETES AN OBJECT

ALIAS alias name


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

FREE PLAN

♦ WHEN AN OBJECT IS DROPPED ALL OBJECTS THAT ARE


DIRECTLY OR INDIRECTLY DEPENDENT ON THAT OBJECT ARE
DELETED

♦ THE OBJECT’S DESCRIPTION IS DELETED FROM THE CATALOG


TABLE.

65
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, it’s 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

67
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 30
S2 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

69
SELECT DISTINCT

SELECT DISTINCT IS TO ELIMINATE DUPLICATE ROWS

Q : GET PART NUMBERS FOR ALL PARTS SUPPLIED


WITH REDUNDANT DUPLICATES ELIMINATED

QUERY : SELECT DISTINCT P#


FROM SP;

RESULT

P#

P1
P2
P3
P4
P5
P6
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 SMITH S1 SMITH
S4 CLARK S2 JONES
S4 CLARK

71
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 WEIGHT IN GRAMS = 5448


P5 WEIGHT IN GRAMS = 5448
P4 WEIGHT IN GRAMS = 6356
P2 WEIGHT IN GRAMS = 7718
P3 WEIGHT IN GRAMS = 7718
P6 WEIGHT IN GRAMS = 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 RESULT 2

P# PNAME WEIGHT P# PNAME WEIGHT

P1 NUT 12 P2 BOLT 17
P2 BOLT 17 P3 SCREW 17
P3 SCREW 17 P6 COG 19
P5 CAM 12

73
PARTIAL SEARCH

TO SEARCH ON A SUBSET OF CHARACTERS : LIKE

NOT TO SEARCH ON A SUBSET OF CHARACTERS : NOT 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%’ ;
RESULT 1
S# SNAME CITY

S1 SMITH LONDON
S4 CLARK LONDON

RESULT 2

S# SNAME CITY

S2 JONES PARIS
S5 ADAMS ATHENS

RESULT 3

S# SNAME CITY

S1 SMITH LONDON
S4 CLARK LONDON

RESULT 4

S# SNAME CITY

S1 SMITH LONDON
S4 CLARK LONDON

RESULT 5

S# SNAME CITY

S3 BLAKE PARIS
S4 CLARK LONDON

75
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 : SELECT SUM (QTY) , AVG (QTY) , MAX (QTY) , MIN (QTY)
FROM SP
WHERE P# = ‘P2’ ;

RESULT 1 RESULT 2

5 1000 250 400 200


GROUP BY

WITH GROUP BY, A COLUMN FUNCTION RESULTS


IN A SINGLE VALUE FOR EACH GROUP

Q : 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 600
P2 1000
P3 400
P4 500
P5 500
P6 100

77
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: GET PART NUMBERS FOR ALL PARTS SUPPLIED BY


MORE THAN ONE SUPPLIER

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

RESULT

P#

P1
P2
P4
P5
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# PNAME COLOR WEIGHT P.CITY

S2 JONES 10 PARIS P1 NUT RED 12 LONDON


S2 JONES 10 PARIS P4 SCREW RED 14 LONDON
S2 JONES 10 PARIS P6 COG RED 19 LONDON
S3 BLAKE 30 PARIS P1 NUT RED 12 LONDON
S3 BLAKE 30 PARIS P4 SCREW RED 14 LONDON
S3 BLAKE 30 PARIS P6 COG RED 19 LONDON

79
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 : SELECT SNAME


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

RESULT

SNAME

SMITH
JONES
BLAKE
CLARK
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

81
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# PNAME COLOR WEIGHT CITY

… …. … .... …….
P8 SPROCKET PINK 14 NICE RESULT 1
P7 ? ? 24 ATHENS 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: CHANGE THE COLOR OF PART P1 TO YELLOW ,


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

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

RESULT

P# PNAME COLOR WEIGHT CITY


… … … … …
P1 NUT YELLOW 17 ?
… … … … …

83
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

85
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 TABLES 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;

87
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;

89
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.

91
Program Structure

Programs that access DB2 are written in a number of host languages - COBOL,
PL/1, C, ASSEMBLER, FORTRAN, and 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

93
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 program’s 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.

95
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

97
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.

99
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 it’s 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 SQLERRP PIC 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

101
SQLCA RETURN CODES

INTEGER CHAR(1)
CONDITION SQLCODE SQLWARN0 REQUEST
STATUS

ERROR <0 FAILED

WARNING >0 & <>100 OR ‘W’ SATISFIED


WITH SPECIAL
CONDITION

NOT FOUND +100 DATA NOT


FOUND

SUCCESS 0 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.

103
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

105
-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 THAT 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

-803 UNIQUE INDEX VIOLATION.

-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

-818 TIME STAMP ERROR.THE SOURCE MODULE AND DBRMS AFTER


PRECOMPILATION HAS NOT REACHED THE MAIN MEMORY FOR
EXECUTION AT THE SAME TIME.

-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
resource-type, 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

-922 AUTHORIZATION ERROR


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 IT’S EFFECT

♦ THE USE OF COLON BEFORE THE LABEL IS OPTIONAL

♦ ‘’ GO TO ‘’ AND ‘’ GO TO ’’ ARE EQUIVALENT

107
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 SQLCA (TO BE INCLUDED IN SOURCE


PROGRAM )

01SQLCA
EXEC SQL 05 SQLCAID PIC X(8).
05 SQLCABC 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.

109
USING CURSORS

PROCESSING MULTIPLE ROWS

QUERY: SELECT STATUS, CTTY INTO :RANK, :CITY


FROM S WHERE STATUS < 30 ;

STATUS CITY

2 LONDON
10 PARIS
20 LONDON
RANK CITY

STATUS CITY

20 LONDON
10 PARIS
20 LONDON

RANK CITY

STATUS CITY

20 LONDON
10 PARIS
20 LONDON

RANK CITY
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.

111
SELECT WITH FETCH

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

♦ OPEN THE CURSOR


EXEC SQL
OPEN K10
END-EXEC

♦ FETCH RESULT ROWS ONE AT A TIME


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

♦ 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 Cursor’s 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.

113
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 that 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.

115
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 SELECT

RESULT

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

117
DYNAMIC SQL

PLAN TO EXECUTE USER’S 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

119
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.
******************************************************************
* LINKAGE SE CTION *
******************************************************************
*
………………………………………………………………….
…………………………………………………………………
…………………………………………………………

121
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
*
* 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.

123
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.

125
DCLGEN (DECLARATIONS GENERATOR)

INPUT OUTPUT
DECLARE TABLE
STATEMENT
CONTROL STATEMENTS
WHICH INCLUDE TABLE OR DCLGEN
VIEW NAME AND NAME OF
THE HOST LANGUAGE 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.

127
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 PRE COMPILE
CROSS REFERENCES

MODIFIED
SOURCE CODE DBRM
(CONTAINS (CONTAINS
CONSISTENCY CONTOKEN )
TOKEN)

♦ 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

129
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 PLAN

DBRM2 BIND PACKAGE2

♦ THERE ARE TWO TYPES OF BIND


• BIND PACKAGE
• BIND PLAN

131
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.

133
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 (EWSK) -


MEMBER (SXD11010) -
OWNER (AM1240) -
QUALIFIER (SYSADMK ) -
VALIDATE (BIND) -
EXPLAIN (NO) -
ISOLATION (CS) -
RELEASE (COMMIT) -
ACTION (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.

135
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.

137
COMPILE AND LINKEDIT

MODIFIED
SOURCE MODULE
(CONTAINS CONTOKEN)

COMPILER

OBJECT MODULE

OTHER
LINK EDITOR OBJECT MODULES

LOAD MODULE

(CONTAINS CONTOKEN)

♦ MODIFIED SOURCE FROM THE PRE COMPILER IS COMPILED USING


HOST LANGUAGE COMPILER THAT PRODUCES OBJECT MODULE.

♦ LINKAGE EDITOR IS USED TO MAKE AN EXECUTABLE LOAD MODULE


THAT 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
MAIN MEMORY
PREPARATION AND EXECUTION

SOURCE
MODULE

MODIFIED
SOURCE PRECOMPILER DBRM
MODULE

COMPILER BIND

OBJECT PACKAGE
MODULE

OTHER
LINKAGE OBJECT LIST OF BIND
EDITOR MODULES PACKAGES

LOAD LOAD MODULE APPLICATION


MODULE PLAN
PLAN / PACKAGES

139
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 it’s 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.

141
8. Security Features

DB2 provides data integrity by using different security mechanisms. Data access
is controlled by using authorization ID’s and privileges given to that ID. This
chapter briefly explains these security features and DB2’s 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


IT’S OBJECTS

• THE AUTHORIZATION SUB SYSTEM


• THE VIEW MECHANISM

♦ THE SYSTEM ADMINISTRATOR PROVIDES AUTHORIZATION ID’S TO IT’S


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 ID’S

• 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.

143
Security Features

Authorization ID’S 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 user’s responsibility to identify themselves to by
supplying that ID when they sign on to the system.

Two types of authorization ID’s 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 that can
be performed by this AUTHID depend 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

145
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

DB2’S 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

147
DB2’S 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. i.e. 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 and 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

149
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 and 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. i.e. 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.

151
Example For Referential Integrity Violation

TABLE S TABLE SP

S# SNAME STATUS CITY S# P# QTY

S1 SMITH 20 LONDON S1 P1 300


S2 JONES 10 PARIS S1 P2 200
S3 BLAKE 30 PARIS S1 P3 400
S4 CLARK 20 LONDON S1 P4 200
S5 ADAMS 30 ATHENS S1 P5 100
S1 P6 100
S2 P1 300
S2 P2 400
S3 P2 200
S4 P2 200
S4 P4 300
S4 P5 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#) PRIMARY KEY ( S# )


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

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.

153
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 would 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 NEW POINT OF


CONSISTENCY CONSISTENCY

OLD DATA UPDATES UPDATED

DATA UNIT OF RECOVERY DATA

COMMIT

POINT OF NEW POINT OF


CONSISTENCY 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

155
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

F
COMMIT A
I
L
U
UPDATE1 UPDATE2 R
E

LOG

BACKUP

RECOVERED
DATABASE

RESTORE

UPDATE

LOG

157
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 tablespace.
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
database 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 it’s 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

159
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.

161
LOCKING STRATEGY

♦ DB2 DETERMINES IT’S 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. LOCKSIZE parameter of CREATE TABLESPACE statement.


2. ISOLATION parameter
3. ACQUIRE / RELEASE parameter
4. 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;

163
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 lock size of tablespace allows a process to lock the tablespace
which controls all tables inside the table space. On the other hand rowlock will
only lock the row that 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.

165
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.

167
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

169
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 (Process SQL statements)


2 DCLGEN (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.

171
SPUFI

INPUT SQL SPUFI OUTPUT


STATEMENTS 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 database, DB2 offers a
number of utilities. This chapter gives a brief explanation of these utilities

11.1. Load

11.2. Runstats

11.3. Reorg

173
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 LOAD UTILITY CORRECT DATA DB2 TABLE


DATA

EXAMPLE

CONTROL INFORMATION FOR LOAD UTILITY

LOAD DATA
RESUME NO
LOG NO
inddn ddname
INTO TABLE D2110K.S
( S# POSITION (1) CHAR 5
P# POSITION (6:11) CHAR 6
QTY POSITION (12:15) INTEGER );

175
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 IT’S 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) ;

177
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 REORGANIZES 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;

179
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

181
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 61 86 ROOT PAGE

8 17 25 33 40 61 70 75 86
INTER-

MEDIATE

PAGES

LEAF

PAGES

. . 8 . . 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

183
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 61 ROOT PAGE

8 17 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

185
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
column’s 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 column’s 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 61 ROOT PAGE

8 17 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

187
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;

189
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

S SHARE

U UPDATE

SIX SHARE WITH INTENT EXCLUSIVE

X EXCLUSIVE

♦ IS : 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

191
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

S SHARE IS

U UPDATE IX

X 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

193
LOCK MODE COMPATIBILITY OF TABLE AND TABLE
SPACE LOCKS

MODE OF MODE OF LOCK B


LOCK A
IS S IX SIX U X

IS YES YES YES YES YES NO

S YES YES NO NO YES NO

IX YES NO YES NO NO NO

SIX YES NO NO NO NO NO

U YES YES NO NO NO NO

X 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.

SIX—The 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

195
LOCK MODE COMPATIBILITY OF ROW AND PAGE LOCKS

MODE MODE OF LOCK B


OF
LOCK A S U X

S YES YES NO

U YES NO NO

X 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.

197
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)
/*
//*