DB2

-1-

DB2

TABLE OF CONTENTS

1. INTRODUCTION TO A RELATIONAL DATABASE

2. DB2 OBJECTS
3. COMPONENTS OF DB2
4. DATATYPES ,FUNCTIONS AND OPERATORS
5. EMBEDDED SQL
6. INDICATOR VARIABLE
7. CURSORS
8. ERROR/EXCEPTION HANDLING
9. TRANSACTION PROCESSING
10. CONCURRENCY AND LOCKING
11. DB2 INTERACTIVE INTERFACE
11.1 SPUFI
11.2 DCLGEN
11.3 CATALOG MANAGER
12. SQLCA AND SQLCODES
12. APPENDIX A : ASSIGNMENTS
13. APPENDIX B : STANDARDS
14. APPENDIX C : BIBLOGRAPHY

-2-

05
08
12
18
26
30
35
42
44
47
58
59
63
65
70
76
79
82

DB2

DAY-WISE SCHEDULE

DAY 1
INTRODUCTION TO A RELATIONAL DATABASE
COMPONENTS OF DB2
DATATYPES, FUNCTIONS AND OPERATORS
SPUFI

DAY 2
EMBEDDED SQL
HOST VARIABLES
INDICATOR VARIABLES
DCLGEN AND SAMPLE PROGRAM

DAY 3
CURSORS
ERROR /EXCEPTION HANDLING
SAMPLE PROGRAMS ON CURSOR

DAY 4
TRANSACTION PROCESSING
CONCURRENCY AND LOCKING
STANDARDS

-3-

DB2

INTRODUCTION TO A RELATIONAL
DATABASE

-4-

DB2

What is a Data base Management System.

A Database management system (DBMS) is a software package that manages data stored
in databases. You use a DBMS to control and use the information stored on your computer
system more effectively and efficiently than you can with standard file processing. The
DBMS is an additional layer of software between the program and the stored data .Its the
DBMS rather than the application program that has a complete picture of the physical and
the logical structure of the data stored.

In a relational system

Data is perceived by users as a collection of tables called relations

Operators generate new tables from old ones
The rows are referred to as tuples
Columns are referred to as attributes
Each row in a relation is distinct i.e duplicate rows are not allowed
Each relation must have a primary key, an attribute or a combination of attributes
whose value uniquely identifies the rows.
A relation may also contain foreign keys which reference other relations in a database.
Entire information content of the database is represented as explicit data values (as
explicit values in column positions within rows of a table)

DB2
IBMS Database 2 , commonly referred to as DB2, became generally available in the fall
of 1983. DB2 was marketed as a relational database management system for the MVS
operating system. It uses tables to represent the data that it manages .

HOW DOES DB2 ORGANIZE AND ACCESS INFORMATION.

Db2 is a database management system. A more complete description is that db2 is a
relational database management system that uses the industry standard Structured Query
Language (SQL) as a central component . A relational database system presents all
information in the form of tables. A table is just a two dimensional array with horizontal
rows and vertical columns. The intersection of a row and a column is a value .A value
may be a text string , a number or nothing (null value).
The name relational database comes from the technical term for a table , a relation . In
addition , the formal names for the elements of a relation are tuple (row) and
attribute(column). But these arent the only terms. A row is called a record and a column
is called a field.
Although files and tables have similar structures ,they are processed differently . in
standard file processing , the unit of processing is a an individual record while in db2 it is
an entire table ,which may have one ,many or no rows.

-5-

D4

DB2

DB2 ARCHITECTURE
DB2 as perceived by an individual User
user
SQL

Virtual

VIEW1

VIEW2

Real
Base
Table B1

B2

B3

B4

Stored
VSAM
Dataset
D1

D3

D2

-6-

D4

DB2

DB2 OBJECTS

-7-

DB2

STORAGE STRUCTURE
The total collection of stored data is divided up into a number of disjoint databases . Each
database is divided into a number of disjoint spaces several table spaces and index
spaces. A space is a dynamically extendable collection of pages ,where a page is a block of
physical storage (it is a unit of i/o i.e the unit transferred between primary and secondary
storage in a physical i/o operation. The pages are given size of either 4k or 32 k. Each
table space contains one or more stored tables . a stored table is is a physical representation
of a base table .

DATABASE:
A Database in DB2 is a collection of logically related objects that is a logical collection
of stored tables that belong together in some way ,together with their associated indexes
and the various spaces that contain those tables and indexes . it thus contains a set of table
spaces (each containing one or more stored tables ) together with a set of index spaces
(each containing exactly one index). A given stored table and all its associated indexes
must be wholly contained within a single database. Objects are grouped together into the
same database primarily for operational reasons .Tables can be moved from one database
to another without having any logical impact on user or user programs.

TABLE SPACES:
A table space can be thought of as a logical address space on secondary storage that is use
to hold one or more stored tables (logical because it is typically not just a set of physically
adjacent areas) . As the amount of data in those table grows (or as the number increases),
so storage will be acquired from the appropriate storage group and added to the table space
accordingly. One table space can be approx. 64 billion bytes in size and there is effectively
no limit to the number of table spaces in a database ,nor to the no. of databases .
Fundamentally the table space is the storage unit for recovery and re-organization
purposes; i.e. it is the unit that can be recovered via the recover utility . If the table space
is very large , however , recovery and re-organization could take a very long time.DB2
therefore provides the option to partition a large table space into simple , partitioned and
segmented forms.
A simple table space can contain more than one stored table , though one is usually the
best option. One reason for having more than one is that stored records for different stored
tables can be clustered together in such a way as to improve access times to logically
related data. In particular , certain join queries would then be handled more efficiently
since the I/O operations would be reduced.
Partitioned table spaces are intended for stored tables that are sufficiently large. A
partitioned table space thus contains exactly one stored table , partitioned in accordance
with value ranges of a partitioning columns or column combination. Individual partitions
of a partioned table space are independent of each other in the sense that they can be
independently recovered or reorganized.
They can also be associated with different storage groups i.e. it is possible to store
different partitions on different devices and thereby spread the table space I/O load.

-8-

DB2

SEGMENTED TABLE SPACE:

Like simple table spaces, they can contain any number of stored tables ;unlike simple table
spaces , however, segmented table spaces do not support any kind of cross table clusteringthat is they do not allow records for different stored tables to be interleaved on a single
page. Instead , they keep the tables physically separated.

INDEX SPACE
An index space is to an index what a table space is to a stored table. However, since the
correspondence between indexes between indexes and index spaces is always one to one,
there are no data definition statements for index spaces; instead, the necessary index space
parameters are specified on the corresponding index definition statements. Thus for e.g.
there is no create index space; instead the index space is created automatically when the
corresponding index is created. Like Table spaces ,index spaces can be reorganized and
recovered independently.

INDEX
Index in db2 are based on a structure known as B-tree. A b-tree is a multilevel, tree
structured index with the property that the tree is always balanced; i.e. all its 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. As a result, the index
provides uniform and predictable performance for retrieval operations. A given table can
have any number of associated indexes. Also if the installation follows our
recommendation that every base table have a primary key, then every stored table will
have at least one index, namely the primary index.
To perform an exhaustive search on a given stored table according to a given index, the
data manager will access all records in that stored table in the sequence defined by that
index and since that sequence may be quite different from the stored tables physical
sequence, a given data page might be accessed many times. It follows that an exhaustive
search via a physical sequence unless the index concerned is a clustering index for which
the sequence defined by the index is the same as, or close to, the physical sequence. The
index is used to control the physical placement of the indexed records. Clustering indexes
are extremely important for optimization purpose. The optimizer will try to choose an
access path that is based on a clustering index, if one is available, and if clustering
sequence is appropriate for the sql under consideration.

-9-

DB2

STORAGE GROUPS:
A storage group is a named collection of direct access volumes, all of which are the same
device type. Each table space and each index space normally has an associated storage
group. When storage is needed for the space or partition , it is taken from the specified
storage group. Within each Storage group, spaces and partitions are stored using VSAM
linear data sets .

SYNONYM:
Is an alternate name for a base table or view. Each user can assign his or her own
synonyms for any table or view that was created by some other fully qualified name.

VIEW:
It is a predefined selection of data in base tables. It is a virtual table that does not
physically exist but is processed as a table. It is derived from one or more base tables, or
views or combinations of views and tables. The view definition is stored in the DB2
catalog. Changes to the data in the view can change the data in the base table.

CATALOG :
Contains information about every DB2 object that is maintained by it. Whenever a DB2
object is created, dropped or altered by any ddl statement or whenever control over the
object is changed by any dcl statement of sql, an entry is made in the appropriate catalog
table. Catalog table can be accessed using sql, they however cannot be updated by a
user(but done so by the system).
To retrieve information from the DB2 catalog, the select privilege on the catalog is needed.
Some of the catalog tables are :
SYSTABLES
SYSSTOGROUP
SYSTABLESPACE

- 10 -

DB2

COMPONENTS OF DB2

- 11 -

DB2

SYSTEM STRUCTURE:
The major components of DB2 are
SYSTEM SERVICES
LOCKING SERVICES
DATABASE SERVICES

RELATIONAL DATABASE SYSTEM

MVS OPERATING SYSTEM
TSO
Subsystem

CICS
Subsystem

IMS
Subsystem
DB2 Subsystem

RESOURCE
LOCK
MANAGER
Isolate Users
Locking Services

DATABASE
SERVICES

SYSTEM
SERVICES

Access Data
Create Objects
DB2 Catalog

Perform logging
Manage Log
Inventory Manage
Threads

- 12 -

DB2

SYSTEM SERVICES:
This component handles all system wide tasks including connections to other MVS
subsystems.
It also handles system startup and shut down operator communication.
Managing the system log : The system log is a set of predefined disk data sets that are
used to record information for recovering user and system data in the event of a failure.
When an active log data set becomes full (or on operator command ), DB2 switches to
a new data set and copies the old one to an archive log data set on disk or tape. When
the active data sets are full, they are recycled. Information regarding the data sets
themselves is recorded in the BOOT STRAP DATA SET (BSDS).
Gathering system wide statistics, performance and accounting information.

LOCKING SERVICES:
Provided by an MVS subsystem called the IMS Resource Lock Manager (IRLM). Despite
the IMS in its name , the IRLM does not really have anything to do with it. It is a
general purpose lock manager which controls the concurrent access to db2 data.

DATABASE SERVICES:
The primary purpose of the database component is to support the definition , retrieval and
update of database data- to implement the functions of the sql. The necessary support is
provided by a series of five sub components :
Precompile
Bind
Runtime Supervisor
Data Manager
Buffer Manager
Together these components support the preparation of the application programs for
execution and the subsequent execution of those programs. The functions of the individual
components are as follows:

PRECOMPILER
This component is a preprocessor for the host language. Its function is to analyse the host
language source module stripping out all the sql statements it finds and replaces them by
the host language CALL statements. From the sql it encounters, the precompiler constructs
a database request module which becomes the input to the bind component.

- 13 -

DB2

THE PROCESS:

Searches for and expands DB2 related include members .

Searches for sql statement in the body of the programs source code .
Creates a modified version of the source program in which every sql statement in the
program is commented out and a call to the db2 runtime interface module along with
applicable parameters , replaces each original sql statement.
Extracts all sql statements from the program and places them in a dbrm to ensure that
these two items are inextricably tied.
Reports on the success or failure of the precompile process.
The precompiler searches for sql statements embedded in EXEC SQL and ENDEXEC.

PRECOMPILATION
COBOL SOURCE
MODULE P
- Source listing
- Diagnostics
- Cross-References
etc.

PRECOMPILER

CALL Long-Interface
Modified -COBOL
Source Module
P.

- DBRM for P
(SQL statements, etc.)

It uses the SQL statements to build a DBRM for P, which it

stores away as a member of an MVS partitioned data set
DBRM contains a copy of the original SQL statements,
together with additional information

- 14 -

DB2

BIND:
This component is the compiler for the sql statements. It reads the sql statements from the
DBRMS and produces a mechanism to access data as directed by the sql statements being
bound. The bind plan accepts as input one or more DBRMs produces from the previous
DB2 program precompilation. The output of the bind plan is an application plan containing
executable logic representing optimized access paths to DB2 data. An application plan is
executable only with a corresponding module. Before u can run a DB2 program, regardless
of the environment, an application plan name must be specified.
The major functions of bind are:
Parsing and syntax checking
Optimization
Authorization
Check that DB2 tables and columns being accessed conforms to the corresponding
DB2 catalog information.
BIND PLAN vs. BIND PACKAGE:
In some cases however, a DBRM may not be bound directly into a plan. Instead it may
first be bound into a package and then finally, the packages may be bound into a plan.
There are certain disadvantages of directly binding the DBRMs into an application plan :

If an individual DBRM needed to be recompiled for any reason(for eg some index was
dropped),the entire plan had to be recompiled and rebound.
If multiple plans involved the same DBRM , that same DBRM had to be compiled
multiple times and , if that DBRM ever needed to be recompiled , then all relevant
plans had to be recompiled and rebound in their entirety.
Adding a new DBRM to an existing plan required (again) a recompilation and rebind
of the entire plan.
Partly as a consequence of the foregoing points, bind and rebind times are becoming
unacceptably high in some DB2 installations and availability was suffering as a result.

The package concept was introduced to remedy these deficiencies. If a given DBRM
needs to be recompiled, all that has to be done is an appropriate package bind it is not
necessary to recompile the entire plan. Indeed, it may not be necessary to do a new plan
bind to incorporate the new package either.

- 15 -

DB2

RUNTIME SUPERVISOR:
The runtime supervisor is resident in main memory when the application program is
executing. Its job is to oversee that execution. When the application program requests
some database operation to be performed (wishes to execute some sql), control first goes
to the runtime supervisor, which uses control information in the application plan to request
the appropriate operations on part of the data manager.

DATA MANAGER:
The data manager can be thought of as a very sophisticated access method. It performs all
of the normal access method functioning such as search, retrieval, update , index
maintenance etc. Broadly speaking, the data manager is the component that manages the
physical database(s). It invokes other system components as necessary in order to perform
detailed functions such as locking, logging, I/O operations etc during the performance of
its basic task.

BUFFER MANAGER:
The buffer manager is the component responsible for physically transferring data between
external storage and virtual memory. It employs sophisticated techniques to get the best
performance out of the buffer pools under its care and to minimize the amount of physical
I/O actually performed.

DB2 Application Programs Preparation & Execution :(Control Flow Diagram Overview)
Source
Module
Modified
Source
Module

DBRM

Precompiler

Compiler

Object
Module
Linkage
Editor

BIND
(Load Module)
application plan
Runtime
Supervisor
Data
Manager

Load
Module

Appln.
Plan

Buffer
Manager

- 16 -

DB

DB2

DATATYPE FUNCTIONS
AND
OPERATORS

- 17 -

DB2

INTRODUCTION:
The basic data object is the scalar value ;the object appearing at the intersection of a given
row and a given column of a given table. Each scalar value is of some scalar data type. For
each such data type, there is also an associated format for writing literals of that type.
Scalar objects can be operated upon by means of certain scalar operators. DB2 also
provides certain scalar functions which can be regarded as scalar operators. Scalar objects
and operators can be combined to form scalar expressions.

DB2 DATATYPES
DATA TYPE

DESCRIPTION

Full word
binary integer
SMALL INT
Half word
binary integer
DECIMAL(p,q)
p-total no. of
digits
q - digits to right
of decimal point
FLOAT
long floating
point
CHARACTER(n) Fixed length
string

VALURANGE

STORAGE
REQUIRED

1 - 2 billion

4 bytes

1-32767
0<P<16
0<Q<P

2 bytes
packed
decimal
format

5.4E - 79 to
7.2E + 75
0<n<255

8 bytes

INTEGER

- 18 -

upto 254
bytes

DB2

DB2 DATATYPES
DATA TYPE

DESCRIPTION

VARCHAR(n)
string
GRAPHIC(n)

Variable length

DATE

TIME

TIMESTAMP

STORAGE
REQUIRED
0<n4097

Fixed length
0<n<123
string of exactly n
16-bit character
Year
0001-9999
Month
1 - 12
Day
1-n
HOUR
0 - 24
MINUTES
0 - 59
SECONDS
0 - 59
Seven Part value contains
Data, TIME and Microseconds
YYYY mmddnhmmssnnnnnn

- 19 -

RANGE
VALUE
upto
4096
upto 254
bytes
4 bytes

3 bytes

10 bytes

DB2 D

DB2

CONSTANTS & LITERALS

Integer
Eg
Decimal
Eg
Float

Eg

Character
string

Eg

Graphic:
string

Eg

: Signed or unsigned decimal

integer with no decimal point
: 4 -15 +364
0
: Signed or unsigned decimal
number with decimal point
: 40 -95.7 +364.05 0.0007
: Written as a decimal constant,
followed by a character E,
followed by an integer constant
: 4E3 -95.7E46 +364E.5 07E1

: Written either as a string of characters

enclosed in a single quotes or a string of pairs
hexadecimal digits enclosed in single quotes
preceded by letter X.
: 123MAIN St.
PIGON
X FIF2F3F40D156247
: Written as a string of double byte characters
preceded by the character < and followed
by > the whole enclosed in single quotes and
preceded by letter G.
: G <STRING>

- 20 -

DB2

NUMERIC OPERATORS:
ARE : +,-,*,/

FUNCTIONS:

CONCATENATION ( ): can be used to concatenate two character strings or two

graphic strings. E.g (INITIALS || LASTNAME)

CHAR: Converts a date, time ,timestamp to its character string representation.

DATE: Converts a scalar value to a date.

DAY: Extracts the day portion of a date or a timestamp.

DAYS: Converts a date or timestamp to a number of days.

DECIMAL: Converts a number to decimal representation.

DIGITS: Converts a number(decimal or integer) to a character string representation.

FLOAT: Converts a number to a floating point representation.

HEX: Converts a scalar value to a character string representing a internal HEX code

HOUR: Extracts the hours portion of a time or timestamp.

INTEGER: Converts a number to integer representation.

LENGTH: Computes the length of the scalar value in bytes .

MICROSECOND: Extracts the microsecond portion of a timestamp.

MINUTE: Extracts the minute portion of a date or timestamp.

SECOND: Extracts the second portion of a date or timestamp.

SUBSTR: Extracts a part of the string from a string.

Assume = AARTI
e.g. SUBSTR(SNAME,1,3) would extracts AAR

TIME: Converts a scalar value to time.

- 21 -

DB2

TIMESTAMP: Converts either (a) Single scalar value or

(b) a pair of scalar values (representing
a date and time resp.) to a timestamp
VALUE: Converts a null value into a non null value.
e.g. Select custno,fname,lname,value((H):||homeph,(w):|| workph, no phone)

VARGRAPHIC: Converts a character sting to a graphic string.

YEAR: Extracts the year portion of a date or timestamp.

SPECIAL REGISTERS
Each individual user is assigned an authorization ID. That id is used to sign on to the
system, and serves as the primary id for the user in question. Tables and other objects that
are purely private to that user will typically be created under the control of, and hence be
owned by the primary id.
Each functional area(eg each department) in the organization is also assigned an
authorization id. However, that id is typically not given the sign-on authority; users sign
on to the system under their primary id. Once signed on, users can operate under their
primary id or using the sql statement (SET CURRENT SQLID) they can switch to a
secondary id. An external subsystem such as IBMs RACF keeps track of the secondary
id(s) that can legitimately be used by a given primary id. A given primary id can have any
number of secondary ids also that the same secondary id can be used by any number of
primary ids.

- 22 -

DB2

SCALAR EXPRESSIONS

Six types of scalar expression are

Numeric
Character String
Graphic String
Date
Time
Timestamp expressions

Assignments :
Assignment operations are performed when values are retrieved from the DataBase or
stored into the DataBase.

Comparisons :
The general form of a comparison is
Comparand operator comparand where
Two comparands must be compatible
The operator is any of the following
> , <, = ,>= ,<= , ~=
Examples
WEIGHT * 454=1000
SUBSTR (PNAME,1,1) = C
FINAL_DATE = REVIEW DATE - CURRENT DATE
SUM (QTY) =500

- 23 -

DB2

NULLS :
Means missing information. The problem with missing information is that is frequently
encountered in the real world. For example , historical records sometimes include such
entries as date of birth not known:; meeting agendas often show a speaker as to be
announced and police records may have entries as present whereabouts not known.
Hence it is desirable to have some way of dealing with such situations in our formal
database systems. SQL systems like DB2 represent missing information by means of
special markers called NULLS. For e.g. we might say loosely that the weight of some part
is null. What we mean by such a statement is that (a) the part exists (b) of course , it has a
weight but (c) we do not know what that weight is. Instead we mark that slot as null.
In general any column can contain nulls unless the definition of that column explicitly
specifies NOT NULL. If a given column is allowed to contain nulls, and a row is inserted
into the table and no value is provided for that column, DB2 will automatically place a null
in that position.
In DB2, a column that can accept nulls is physically represented in the stored database by
two columns, the data column itself and a hidden indicator column ,one byte wide ,that is
stored as a prefix to the actual data column.
NOT NULL WITH DEFAULT means that the column in question cannot contain NULLS,
but that 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 on which not null with default
applies,DB2 automatically places one of the following default values in that position:
Zero for numeric columns
Blanks for fixed length columns
Empty (zero-length string) for varying length string columns.

- 24 -

DB2

EMBEDDED SQL

- 25 -

DB2

EMBEDDED SQL:
Any SQL statement that can be used at the terminal can also be used in an application
program. There are various differences of detail between a given interactive SQL
statement and its corresponding embedded form.

Embedded SQL statements are prefixed by EXEC SQL and are terminated by ENDEXEC

SQL statements can include references to host variables

Any tables (base tables or views) used in the program must be declared

After any SQL statement has been executed, feedback information is returned to the
program in an area called the SQL Communication Area (SQLCA)

The embedded SQL SELECT statement requires an INTO clause specifying the host
variables.

- 26 -

DB2

HOST VARIABLES

- 27 -

DB2

HOST VARIABLES:
Host variables are variables declared in the working storage section and are used by DB2
when it moves data between your program and a table. They are defined according to the
rules of programming language.
Host variables can appear in SQL data manipulation statements. They are generally used
for designating a target for retrieval. Such variables can appear in the following positions :
Into clause in select or fetch (target for retrieval)
Where or having clause (value to be compared)
Set clause in update (value to be assigned)
Values clause in insert (value to be inserted)
Example
EXEC SQL
Select status , city into :status , :city
from employee
where sno = :given-sno;
END-EXEC
SQL statements can include references to host variables, such references are prefixed with
a colon to distinguish them from SQL column names

- 28 -

DB2

INDICATOR VARIABLES

- 29 -

DB2

INDICATOR VARIABLE
In general if there is a chance that the source or a retrieval operation might be null, the user
should include an INDICATOR VARIABLE in the into clause in addition to the target
variable as illustrated in the following example:
EXAMPLE :

EXEC SQL
Select status ,
Into :status:status-ind,
From s
Where sno = :Given-Sno
END-EXEC.

city
:city:cityind

For processing and finding out whether the fields were NULL or not, a check can be
performed as :
IF STATUS-IND < 0 THEN /*STATUS WAS NULL */

Indicator variables can be used in the VALUES clause to insert NULL VALUES.

EXAMPLE: IF COLORIND < 0 OR

CITYIND < 0

EXEC SQL
INSERT INTO P (PNO,COLOR, CITY)
VALUES
(:PNO,:PCOLOR:COLOR-IND, :PCITY:CITYIND)
END-EXEC.

Each indicator variable is a half-word integer (pic S9(4) comp).

If defined as an array (occurs clause) ,then it may be used for a list of columns with the
first occurrence of the indicator variable corresponding to the first column in that list
using a single indicator variable, Nulls can be handled for all the fields of the table.
The indicator variable will have a negative value if the select returns a null value.
If the indicator variable returns a value > 0, it indicates a truncated variable is the
length of the character string before truncation
If the Indicator variables contain :
A negative No. indicates that the column has been set to Null
The value 2 indicates that the column has been set to Null as a result of Data
Conversion Error
A positive or a zero value indicates that the column is not Null

- 30 -

DB2

If a column, defined as a char data type,is truncated on retrieval because the host
variable is not large enough, the indicator Variable, contains the original length of the
truncated column

EXAMPLE: 01

DEPT-INDICATORS.
10 DEPT-IND OCCURS 5 TIMES PIC S9(4) COMP.
EXEC SQL
SELECT DEPTNO, DNAME, MGR, HO, LOC
INTO :DCLDEPT: DEPT-IND
FROM DEPT
WHERE DEPTNO = A00
END-EXEC

Indicator variables can appear on the right hand side of an assignment in the SET
clause to set a value to NULL.

EXAMPLE: IF RANKIND = < 0

EXEC SQL
UPDATE S
SET STATUS = :STATUS:STATUS-IND
WHERE CITY =LONDON
END-EXEC.

- 31 -

DB2

A SAMPLE PROGRAM

- 32 -

DB2

IDENTIFICATION DIVISION.
PROGRAM-ID. PRG1.
AUTHOR. AARTI.
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
EXEC SQL
INCLUDE EMPDCL
END-EXEC.
EXEC SQL
INCLUDE SQLCA
END-EXEC.
PROCEDURE DIVISION.
1000-UPDATE-PARA.
MOVE 3999 TO X.
EXEC SQL
INSERT INTO EMP(X)
VALUES (:X)
END-EXEC.
EXEC SQL
COMMIT WORK
END-EXEC.
STOP RUN.

- 33 -

DB2

CURSORS

- 34 -

DB2

CURSORS:
A mechanism allowing an application program to retrieve a set of rows. The cursor facility
allows a COBOL program to gain addressability to individual row occurrences of a manyrows result table
Following steps to be performed to use cursors
Declare cursor : to define cursor
Open cursor : to create result table
Fetch cursor : to retrieve rows from cursor, one at a time to be
executed in a loop
Close cursor : to close the cursor
Declaring (defining) a cursor is done in the data division of your program.
This is purely declarative in nature. Therefore no information is being retrieved from the
database yet. The Cursor name should begin with a letter and must not exceed 18
characters.
When the open statement is encountered the select in the cursor declaration is executed.
The open cursor statement not only executes the selection of data from the DB2 database
but also establishes the initial position of the cursor in the results table. One program can
have multiple cursors.

Declaring a Cursor
EXEC SQL
DECLARE cursor CURSOR FOR SELECT col1, col2.... FROM table
WHERE condition [FOR UPDATE OF col1, col2 ..]
END-EXEC

Opening a Cursor
EXEC SQL
OPEN cursor
END-EXEC

Fetching a row from cursor :

EXEC SQL
FETCH cursor INTO : host var1, :host var2,...
END-EXEC.

Closing a cursor :
EXEC SQL
CLOSE cursor
END-EXEC.

- 35 -

DB2

Example-Based on a Single Table

Operations Involving Cursors :EXEC SQL
DECLARE X CURSOR FOR
SELECT S#, SNAME, STATUS
FROM S WHERE CITY = :Y
END-EXEC.
EXEC SQL
OPEN X
END-EXEC.
LOOP UNTIL NO MORE ROWS OR ERROR
EXEC SQL
FETCH X INTO :S#,:SNAME.:SNAME-IND
END-EXEC.
PROCESSING STATEMENTS

EXEC-SQL
CLOSE X
END-EXEC.

- 36 -

DB2

DATA MODIFICATION:
Often an application program must read data and then based on its value, either update or
delete data. One can use the UPDATE or DELETE SQL statements to modify and delete
rows from DB2 tables. These statements are similar to select statements which operate on
a set of data at any given point of time.
This is accomplished with a cursor and a special clause of the update and delet statements
usable only by embedded SQL namely :WHERE CURRENT OF. The cursor is declared
with a special FOR UPDATE OF CLAUSE.
A for update of clause appears with:

Select statement to indicate what columns can be updated when retrieved

The columns to be updated must be listed in the for update of clause or the declare
You do not have to select a column to update it

Rules for Update

The select statement must be on a single table and not on a join

If the declare cursor statement contains a subquery it must not be on the same table as
the main query
You cannot use distinct, group by, order by or built-in functions
Only those columns are eligible for updation which are selected in the for.. update
clause

The current forms of UPDATE & DELETE

EXEC SQL
UPDATE table
SET field = : exp [, field = : exp]
WHERE CURRENT OF cursor
END-EXEC.
EXEC SQL
DELETE FROM table
WHERE CURRENT OF cursor
END-EXEC.

- 37 -

DB2

Example: (Use of Cursor)

EXEC SQL
Declare C1 cursor for
Select Deptno, Deptname, Mgrno From Dept
Where ADMRDEPT = :ADMRDEPT
for update of MGRNO
END-EXEC.
PROCEDURE DIVISION.
MOVE A00 TO ADMRDEPT.
EXEC SQL
OPEN C1
END-EXEC.
PERFORM 200-MODIFY-DEPT-INFO UNTIL NO-MORE-ROWS.
EXEC SQL
CLOSE C1
END-EXEC.
200-Modify-Dept-Info.
EXEC SQL
Fetch C1 into :deptno, : deptname, : mgrno
END-EXEC.
If sqlcode < 0
GO TO 9999-error-paragraph.
If sqlcode = +100
Move NO to more-rows
Else
EXEC SQL
Update Dept Set MGRNO = 00000
Where current of C1
END-EXEC.

- 38 -

DB2

DATA RETRIEVAL
Pseudocode for retrieving data from an application join ,
using cursors:
EXEC SQL
Declare Deptcur cursor for
Select Deptno, Deptname
From Dept
END-EXEC.
EXEC SQL
Declare Empcur cursor for
Select empno, salary from emp
where workdept = :hv-workdept
END-EXEC.
EXEC SQL
Open Deptcur
END-EXEC.
Loop until no more dept rows or error
EXEC SQL
Fetch deptcur into :Deptno , :Deptname
END-EXEC.
Move deptno to HV-WORKDEPT
EXEC SQL
Open Empcur
END-EXEC.
Loop until no more employee rows or error
EXEC SQL
Fetch empcur into
:empno, :salary
END-EXEC.
Process retrieved data
End Loop (2)
End of Loop (1)

- 39 -

DB2

WITH HOLD OPTION:

This is an optional specification on a cursor declaration. The significance can be
understood by considering what happens in its absence.
Suppose we need to process some large table, one row at a time by means of a curso and
update a few of the as we go. It is often desirable to divide the work up into batches and to
make the processing of each batch into a separate transaction (by issuing a separate
commit at the end of each one); thus, e.g. a table of one million rows might be processed
by a sequence of 10,000 transactions, each one dealing with just 100 rows. This way , for
e.g. if it becomes necessary to roll a given transaction back, then at most 100 updates will
have to be undone, instead of potentially as many as a million.
The problem with this approach ,however is that every time we issue a commit, we
implicitly close the cursor, thereby losing our position within the table. The first thing each
transaction has to do, therefore is to execute some re-positioning code in order to get back
to the row that is due to be processed next. And that re-positioning code can often be quite
complex, especially if the processing sequence is determined by a combination of several
columns.
If the cursor declaration specifies with hold, however, commit does not close the cursor,
instead, leaves it open, positioned such that the next FETCH will move it to the next row
in sequence. The possibly complex code for repositioning is thus no longer required.
However it is important to note that the first operation on the cursor following the commit
must be fetch. Update and delete current are illegal.

- 40 -

DB2

ERROR / EXCEPTION
HANDLING

- 41 -

DB2

WHENEVER:
The whenever statement has the syntax :
EXEC SQL
WHENEVER condition action
END-EXEC.
Where condition is one of the following :
NOT FOUND means SQLCODE = 100
SQLWARNING means SQLCODE >0 & NOT = 100
SQLERROR means SQLCODE < 0
ACTION specifies a CONTINUE or a GO TO statement.
The whenever statement causes the program to automatically check the sqlcode. Based
on the value it finds, it takes the action you specify. Some application programmers prefer
(for structured reasons) to avoid the whenever statement, and use all specific error
checking after each SQL statement is issued.
If you omit the action for a whenever statement, the default of continue will apply for that
condition.There is no limit to the no. of whenever statements you can use.

Example using WHENEVER

1000-INQUIRY.
EXEC SQL
WHENEVER SQLERROR
GOTO 1000-UNDO
END-EXEC.
EXEC SQL
SELECT FLD1, FLD2 INTO : FLD1, :FLD2
FROM EMP-TABLE WHERE CODE = 113
END-EXEC.
1000-UNDO
DISPLAY ERROR! CANT PROCEED
EXEC SQL
ROLLBACK
END-EXEC.
1000-EXIT.
EXIT.

- 42 -

DB2

TRANSACTION PROCESSING

- 43 -

DB2

WHAT IS A TRANSACTION ?
A transaction is a logical unit of work. Consider the following example. Suppose for the
sake of example the parts table contains an additional column totqty representing the total
quantity for the part in question. The value of the totqty for any part is supposed to be
equal to the sum of all sp.qty values taken all over sp rows for that part. Now consider the
following sequence of operations, the intent of which is to add a new shipment
(S5,P1,1000) to the database:
EXEC SQL
WHENEVER SQLERROR GOTO UNDO
END-EXEC.
EXEC SQL
INSERT INTO SP VALUES (S5,P1,1000)
END-EXEC.
EXEC SQL
UPDATE P
SET TOTQTY = TOTQTY + 1000
WHERE P# = P1
END-EXEC
EXEC SQL
COMMIT WORK
END-EXEC.
UNDO:
EXEC SQL
ROLLBACK
END-EXEC
FINISH:
RETURN
The insert adds the new shipment to the sp table, the update updates the totqty column for
the part p1 appropriately.
The point of example is that what is presumably intended to be a single atomic transaction
create a new shipment infact involves 2 updates to the database. What is more is that
the database is not consistent even between thise two updates. Thus a logical unit of work
is not necessarily just one SQL operation ; rather it is a sequence of several such
operations, in general, that transforms a consistent state of the database into another
consistent state, without necessarily preserving consistency at all intermediate points.
Now it is clear that what must not be allowed to happen in the example is for one of the
- 44 -

DB2
two updates to executed and the other not (because then the database would be in an
inconsistent state). Ideally we would want that both the updates are done, but we cannot
have such a guarantee: there is always a chance that things will go wrong. For example a
system crash may occur between the two updates.
But a system that supports transaction processing does provide the next best thing to such
a guarantee. Specifically, it guarantees that if the transaction executes some updates and
then a failure occurs, for whatever reason before the transaction reaches its normal
termination, the those updates will be undone. Thus the transaction either executes in its
entirety or is totally cancelled.
The system component that provides this atomicity is know as the transaction manager and
the COMMIT WORK and ROLLBACK WORK are the keys to the way it works.
The COMMIT WORK operation signals successful end-of-transaction :it tells that
transaction manager that a logical unit of work has been successfully completed.
The ROLLBACK operation by constrast, signals unsuccessful end-of-transaction
indicating an inconsistent state and all the updates made by the logical unit of work must
be rolled back or undone.
SYNTAX:
COMMIT
The SQL commit statement takes the form
EXEC SQL
COMMIT [WORK]
END-EXEC.
ROLLBACK
The SQL ROLLBACK statement takes the form
EXEC SQL
ROLLBACK [WORK]
END-EXEC

- 45 -

DB2

CONCURRENCY AND LOCKING

- 46 -

DB2

THREE CONCURRENCY PROBLEMS:

DB2 is a shared system; i.e. it is a system that allows any number of transactions to access
the same database at the same time. Any such system requires some kind of concurrency
control mechanism to ensure that current transactions do not interfere with each others
operation and DB2 includes such a mechanism namely locking.
There are essentially three ways in which things can go wrong- three ways. They are
The lost update problem
The uncommited dependency problem
The incorrect analysis problem
The lost update problem:
Consider the situation as shown in the figure:

The Lost Update Problem

TRANSACTION A

TIME

TRANSACTION B

FETCH R

T1

T2

UPDATE R

FETCH R
T3

T4

UPDATE R
-

Transaction A retrieves some row R at time t1 ; transaction B retrieves the same row at
time t2; transaction A updates the row(on the basis of the values seen at time t1) at time t3;
and transaction B updates the same row (on the basis of the value seen at time t2, which
are the same as seen at time t1) at time t4. Transaction As update is lost at time t4,
becauses transaction B overwrites it without even looking at it.

- 47 -

DB2

The uncommitted dependency problem:

This problem arises if one transaction is allowed to retrieve (or update) a row that has been
updated by another transaction and has not yet been committed by that other transaction.
For if it has not been committed, there is always a possibility that it never will be
committed but will be rolled back instead- in which case the first transaction will have data
that now no longer exists. Consider the figure given below:

The Uncommitted Dependency Problem

TRANSACTION A

TIME

TRANSACTION B
-

T1

UPDATE R

FETCH R

T2

T3

ROLLBACK

TRAN A BECOMES DEPENDENT ON

- AN UNCOMMITTED CHANGE
AT TIME T2

In this example , transaction A sees an uncommitted update at time t2. That update is then
undone at time t3. Transaction A is therefore operating on false assumption that row R has
the value as seen at time t2, where as in fact , it has whatever value it had prior to time t1.
As a result, transaction A may well produce incorrect output.
Inconsistent analysis problem:
This problem could be a simple summation problem.

- 48 -

DB2

How DB2 solves these problems:

DB2s concurrency control mechanism is based on a technique called locking. The basic
idea of locking is simple: when a transaction needs and assurance that some of the object it
is interested in typically a database row - will not change in some unpredictable manner
while its back is turned , it acquires a lock on that object and there by 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 stable state for as long as that
transaction wishes it to
The two types of locks that can be placed are shared lock(S) and exclusive lock (X). We
assume that if a transaction requests a lock that is currently not available , the transaction
simply waits until it is. In practice, the installation can specify a maximum wait time ; then
if any transaction ever reaches this threshold in waiting for a lock, it times out and the
lock request fails ( a negative SQLCODE is returned)

COMPATIBILITY MATRIX
A
B

From the compatibility matrix , two inferences can be drawn:

If transaction A holds an X lock on row R , then a request from transaction B for a lock of
either type on R will cause B to go into a wait state. B will wait until As lock is released.
If transaction A hold a shared lock (S) lock on row R , then
A request from transaction B for an X lock on R will cause B to go into a wait
state (and B will wait until As lock is released);
A request from transaction B for an S lock on R will be granted (that is , B will
now also hold an S lock on R)

- 49 -

DB2

Transaction requests for row locks are always implicit. When a transaction successfully
fetches a row , it automatically acquires an S lock on that row. When a transaction
successfully updates a row, it automatically acquires and X lock on that row. If it already
holds an S lock on that row,as it will in FETCH/UPDATE or FETCH/DELETE
SEQUENCE, then the update or delete promotes the S lock to X level.
The lost update problem revisited

Handling the Lost Update Problem

TRAN A
FETCH R
(acquires S lock on R)
UPDATE R
(request X lock on R)

TIME

T1
-

TRAN B
-

T2

FETCH R
(acquires S lock On R)

T3

Wait
Wait
T4

UPDATE R
(request for X lock on R)

Wait
Wait

The above figure shows what would happen to the interleaved execution under the locking
mechanism of DB2. As one can see, transaction As update at time t3 is not accepted
because it is an implicit request for an X lock on R, and such a request conflicts with the S
lock already held by transaction B; so A goes into a wait state. For analogous reasons , B
goes into a wait state at time t4. Now both transaction are unable to proceed, so there is no
question of any update being lost.DB2 thus solves the lost update problem by reducing it
to another problem but at least it does solve the original problem. This problem is called
the deadlock problem, discussed later.

- 50 -

DB2

The uncommitted dependency problem revisited

Handling the Uncommitted Dependency Problem

TRAN A
FETCH R
(request for S lock on R)

TIME

T1

T2

Wait
`
Wait
T3
Wait
resume : FETCH R
(X lock on R)`

TRAN B
UPDATE R
(X lock on R)
SYNCPOINT
(Release X lock
on R)

T4

Transaction As operation at time t2 is not accepted , because it is an implicit request for a

lock on R, and such a request conflicts with the X lock already held by B; so A goes into a
wait state and remains so until B reaches a synchpoint(either commit or rollback), when
Bs lock is released and A is able to proceed; and at that point A sees a committed value
(either the pre B value, if B terminates and with a ROLLBACK , or the post b value
otherwise. Either way, A is no longer dependent on an uncommitted update.

- 51 -

DB2

Deadlocks

.
A 'deadlock' occurs when program A locks page X exclusively and attempts to
lock page Y, while program B has already locked page Y exclusively and attempts to lock
page X. Neither program can continue without the required lock. DB2 cancels one of the
processes (the one with the fewest log records) with a time out code. To avoid this
situation, you can:

Use the same sequence of update. Both programs should advance along the
tables in ascending key order; this makes it less likely that they will cross each
other's paths and attempt to lock the same page. Both programs should access
various tables in the same sequence, for the same reason.

Avoid clashing updates through different paths (if possible). The problem with
such updates can be exemplified as follows:
User A is updating page 1 using index X for access to the data;
User B is updating page 2 using index Y for access to the data.
However, each index also references the data on the other page (i.e., Index X
references data on page 2 and index Y references data on page 1).
Therefore, after the data is reached by means of one index, and after that data is
updated, each query must modify the other index so it would reflect the new,
updated data. However, that other index is still locked by the other query.
Such deadlocks are hard to avoid. You may watch out for some conditions
which make this situation more likely:

Large number of indexes on a table, with frequent deletes or updates.

Multi-row updates and deletes.
Large value used for SUBPAGES for the index.
Use frequent COMMITs. The chance that a page needed by program A
will already be held by program B is thereby reduced.

Use cursor with FOR UPDATE OF ... This technique locks with INTENT
UPDATE, ahead of time, all the pages which you will need. This is a more
relaxed lock than an exclusive lock, but it still prevents other programs from
locking one of your pages exclusively. Thus, less contention, fewer deadlocks
and fewer time outs will occur.

- 52 -

DB2

Explicit locking facilities

In addition to the implicit locking mechanism described earlier, DB2 provides certain
explicit facilities which the programmer should be aware of. The explicit facilities
consists of : the SQL statement LOCK TABLE , the ISOLATION PARAMETER on the
bind plan command, the table space LOCKSIZE parameter and the ACQUIRE/RELEASE
PARAMETER on the bind plan.

LOCK TABLE :
Depending on the versions, this command either locks up the table or an entire table space
SYNTAX
LOCK TABLE table IN mode MODE
Where mode is SHARE or EXCLUSIVE & table must designate a base table not a
view.
Once a lock is acquired no other transaction will be able to access any part of the table in
any way - until the original lock is released. When that original lock is released depends on
the RELEASE parameter on BIND.
The Lock table statement can be used to control locks from within a DB2 application
program. Every individual page lock uses system resources in storage and processing time
A single table lock reduces the storage and processing time required by the many small
locks. This results in saving of system resources.

- 53 -

DB2

ISOLATION PARAMETER:
Specifies the isolation level for the application plan being bound.DB2 supports two
isolation levels for every transaction
Cursor Stability (CS)
Repeatable Read (RR)
These are used while cursor manipulation
Cursor Stability
DB2 takes a lock on the page the cursor is accessing and releases the lock on that page,
when the cursor moves onto a different page
(This is not done when we use FOR UPDATE of statement in cursor)
The lock on the last page is released at commit time (or at Thread de-allocation time)

Repeatable Read
In cursor stability, while your transaction reads data, other transaction could change the
data you have already read. In repeatable read, DB2 holds all page locks while the cursor
is moving all till the transaction commits (or till thread deallocation).
Cursor Stability provides more /higher concurrency while repeatable read provide more
consistency.
The problem with CS is that a transaction operating at that level may have a record
changed behind its back as in inconsistent analysis problem and so may produce a
wrong answer.
By contrast, a transaction that operates under isolation level RR, can behave completely as
if it were executing in a single user system.

- 54 -

DB2

LOCKSIZE PARAMETER:
Physically, DB2 locks data in terms of pages or tables or table spaces, depending on what
was specified as the LOCKSIZE for the relevant table space in the CREATE or ALTER
TABLESPACE operation.
For a given table space, the LOCKSIZE can be specified as PAGE, TABLE, TABLE
SPACE or ANY.

TABLESPACE : means all locks acquired on data in the tablespace will be at the
tablespace level

TABLE : means locks acquired on data in the tablespace will be at the table level

PAGE : means locks acquired on data in the tablespace will be at the page level
whenever possible.

ANY : (Which is the default) means that DB2 itself will decide the appropriate
physical unit of locking for the tablespace for each plan .Defaults to a page lock, but if
the no. of pages that are locked exceeds an installation default, DB2 does a lock
escalation and automatically locks a larger unit.

- 55 -

DB2

ACQUIRE/RELEASE PARAMETERS
DB2 always implicitly acquires locks of some kind
The acquire and release parameters on the BIND command specify when such tablespace
level locks are to be acquired and released .
For ACQUIRE, the possible specifications are
USE & ALLOCATE;
For RELEASE, they are
COMMIT & DEALLOCATE
While Binding, DB2 allows us to specify transaction level lock acquiring and releasing
parameters.
ACQUIRE:
ACQUIRE (use) - This option tells DB2 to take locks at the time of SQL statements
execution. This is DB2 default.
ACQUIRE (allocate) - This option tells DB2 to take all necessary locks at the start of the
transaction.
RELEASE:
Similar to the DB2 acquire parameters, there are 2 release parameters.
RELEASE (commit) - This option tells DB2 to release all locks of transaction commit
time. This is the DB2 default.
Release (de-allocate) - This option tells DB2 to release all locks only when the program
ends (i.e. the thread is de-allocated).

All combinations except ACQUIRE (Allocate) and RELEASE (commit) are allowed.

For more concurrency, use ACQUIRE (use) and RELEASE (commit).

This is the DB2 default.

For better performance, use ACQUIRE (ALLOCATE) and RELEASE

(DEALLOCATE).

- 56 -

DB2

DB2 INTERACTIVE INTERFACE

- 57 -

DB2

The DB2 INTERACTIVE INTERFACE (DB2I):

This interface provides following:

Ability to execute SQL statements interactively

To invoke prewritten application programs

Ability to issue operator commands

Ability to invoke database utilities

Ability to produce application programs for execution.

INVOKING (DB2I)

Log on to TSO and enter ISPF. From ISPF menu, select DB2I.
The DB2I main menu will offer following options.

SPUFI
DCLGEN
PROGRAM PREPARATION
PRECOMPILE
BIND/REBIND/FREE
RUN
DB2 COMMANDS
UTILITIES

- 58 -

DB2

SPUFI

Supports the interactive execution of SQL statements from a TSO terminal

You can create a text file containing one or more SQL statements (using the ISPF
editor), then execute that file via SPUFI, and then use ISP Browse to browse through
the results of these statements (which will have been written to another text file).

Intended primarily for application programmers who wish to test the SQL portions of
their programs.

---------------------------- Datacenter Functions ---------------------------OPTION ===> D1

Type an option and press Enter.
USERID - DA0021T
A ACF2
-ACF2 Access Control Facility
TIME
- 01:18
C CA-7
-CA-7 Production Scheduler
TERMINAL - 3278
D1 DB2T
-DB2 Test Options
D2 DB2P
-DB2 Production Options
E EXPEDITER
-Debugging Tool
F FILE-AID
-Editor and Utilities
FA File Age
-Platinum Trans Century File Age (2.0.3)
H DF/HSM
-Hierarchical Storage Manager
IN INFORM
-Display Mega Center Information
IS ISMF
-Interactive Storage Management Facility
J JCLWTR
-Sysout Archiver
JS JOB/SCAN
-Job/Scan utilities
L LIBRARIAN
-Program source manager
N NDM
-Data Transfer Utility (for messages only, type NM)
R RMDS
-Report Distribution and Viewing
ST STROBE
-STROBE Monitoring Facility
V VPS70
-Printer Control Facility 7.0
XC XCOM 6.2
-Multi platform file transfer application

- 59 -

DB2

DB2I PRIMARY OPTION MENU

COMMAND ===> 1

Select one of the following DB2 functions and press ENTER.

1
2
3
4
5
6
7
8
D
X

SB#

SPUFI
DCLGEN
PROGRAM PREPARATION
PRECOMPILE
BIND/REBIND/FREE
RUN
DB2 COMMANDS
UTILITIES
DB2I DEFAULTS
EXIT
LTTI 00:03.3

SSID: DST2

(Process SQL statements)

(Generate SQL and source language declarations)
(Prepare a DB2 application program to run)
(Invoke DB2 precompiler)
(BIND, REBIND, or FREE plans or packages)
(RUN an SQL program)
(Issue DB2 commands)
(Invoke DB2 utilities)
(Set global parameters)
(Leave DB2I)
lp

- 60 -

CRTLU004 02-016 A

DB2

SPUFI

SSID: DST2

===>

Enter the input data set name:

(Can be sequential or partitioned)
1 DATA SET NAME ... ..===> DA0021T.AARTI.SQL(Q1)
2 VOLUME SERIAL ..... ===>
(Enter if not cataloged)
3 DATA SET PASSWORD ===>
(Enter if password protected)

Enter the output data set name:

(Must be a sequential data set)
4 DATA SET NAME ...===> DA0021T.OUT1

Specify processing options:

5 CHANGE DEFAULTS ===> NO
(Y/N - Display SPUFI defaults panel?)
6 EDIT INPUT ..... ===> YES
(Y/N - Enter SQL statements?)
7 EXECUTE ........ ===> YES
(Y/N - Execute SQL statements?)
8 AUTOCOMMIT .... ===> YES
(Y/N - Commit after successful run?)
9 BROWSE OUTPUT ... .===> YES
(Y/N - Browse output data set?)
For remote SQL processing:
10 CONNECT LOCATION ===>
PRESS: ENTER to process END to exit
HELP for more information
SB#
LTTI 00:03.4
lp
CRTLU004 10-041 A

- 61 -

DB2

File Edit Confirm Menu Utilities Compilers Test Help

------------------------------------------------------------------------------EDIT
DA0021T.AARTI.SQL(Q1) - 01.00
Columns 00001 00072
Command ===>
Scroll ===> PAGE
****** **************************** Top of Data ************************************
00001
SELECT * FROM EMPLOYEE
****** *************************** Bottom of Data *********************************

- 62 -

DB2

DCLGEN

Allows the user to invoke the declarations generator program

Program preparation :
precompilation
compilation or assembly
linkage editor processing
bind processing
program execution (TSO only)

DCLGEN
DB2I PRIMARY OPTION MENU

SSID: DST2

COMMAND ===> 2

Select one of the following DB2 functions and press ENTER.

1
2
3
4
5
6
7
8
D
X

SB#

SPUFI
DCLGEN
PROGRAM PREPARATION
PRECOMPILE
BIND/REBIND/FREE
RUN
DB2 COMMANDS
UTILITIES
DB2I DEFAULTS
EXIT
LTTI 00:03.3

(Process SQL statements)

(Generate SQL and source language declarations)
(Prepare a DB2 application program to run)
(Invoke DB2 precompiler)
(BIND, REBIND, or FREE plans or packages)
(RUN an SQL program)
(Issue DB2 commands)
(Invoke DB2 utilities)
(Set global parameters)
(Leave DB2I)
lp

CRTLU004 02-016 A

- 63 -

DB2

DCLGEN
===>

SSID: DST2

Enter table name for which declarations are required:

1 SOURCE TABLE NAME ===> employee
2 TABLE OWNER ..... ===>
3 AT LOCATION .... ===>

Enter destination data set:

(Can be sequential or partitioned)
4 DATA SET NAME .. ===> 'DA0021T.AARTI.DB2SORCE(EMPDCL1)'
5 DATA SET PASSWORD ===>
(If password protected)

Enter options as desired:

6 ACTION ......... ===> REPLACE (ADD new or REPLACE old declaration)
7 COLUMN LABEL .... .===> YES
(Enter YES for column label)
8 STRUCTURE NAME ... ===>
(Optional)
9 FIELD NAME PREFIX...===>
(Optional)
10 DELIMIT DBCS ... ===> YES
(Enter YES to delimit DBCS identifiers)
11 COLUMN SUFFIX ... ===> NO
(Enter YES to append column name)
12 INDICATOR VARS .. ===> NO
(Enter YES for indicator variables)

- 64 -

(Unqualified)
(Optional)
(Optional)

DB2

CATALOG MANAGER

--------------------- DB2 Blue Testing Facilities Menu -----------------------OPTION ===> 4

1 DB2I
2 QMF

- DB2 Interactive
- Query Management Facility
QMF SSID ===> DST2 PRINT (YES/NO) ===>
4 DB2MM - BMC's DB2 MasterMind Series of Products
(DB2 Alter, DASD Manager and Catalog Manager)
5 DBEDIT -IBM's Data Base Edit Facility (DBEDIT)
DBEDIT SSID ===> DST2
6 File-AID -Compuware's File-AID for DB2 Utility

R
I

Request - Request Creation and Use of DB2 Objects

Info Browse important information about the DB2 environment
- DB2 v4.1 information YOU need to know
- 09/14/97
- Check the HSM migration warning for DB2 datasets
- New DB2 users should read the DB2 User Guide, Option I.U
Enter HELP for more information about the DB2 Facilities Menu
Enter END Command to Exit the DB2 Facility Menu

- 65 -

DB2

----------------- BMC Software Administrative Products for DB2----------------COMMAND ===> 2

1 DASD MANAGER for DB2

2 CATALOG MANAGER for DB2 - Execute DDL or query the DB2 Catalog

3 CHANGE MANAGER for DB2

- Manage or monitor DB2 physical objects

- Manage changes to DB2 objects/structures

DB2 SSID . . . . . . . . . . . .DST2

DB2 Catalog Access . . . . . . . DIRECT

(Direct)

- 66 -

DB2

DST2- ------------ CATALOG MANAGER 5.4.02 Primary Menu -------------------Command ===>

Select action and type object information. Then press Enter.

Action 0. (L) List catalog objects (blank same as 0)

1. (S) Search for catalog objects
2. (C) Create objects
3. (G) Grant privileges
4. (O) CATALOG MANAGER options processing
5. (D) DB2 Commands
6. (M) Maintain logs menu
7. (Q) List SQL for edit & execution

Obj typeTB 11. DB Database 16. TS Tablespace

12. SG Stogroup 17. SU SysPrivUser
13. TB Table
18. SY Synonym
14. VW View
19. PG Package
15. IX Index
20. CI Collection
Qualifier EMP%
Initial attach to DST2

- 67 -

21. PL Plan 26. ST Strings

22. AL Alias 27. LO Location
23. US User 28. CK Checks
24. CO Column 29. PR Procs
25. DM DBRM

DB2

DST2-R ------------------------- Table List -------------------- Row 1 of 32

Command ===>
Scroll ===> PAGE
01
CMD will show commands for this list. Type command and press ENTER
Lst: AL CA CK CL CO DB DS FK IC IX KC MX PA PG PK PL RI SG SY TM TS TT UA US VW
LIKE: EMP%
C Table Name
Database Tblspace Cols
PK
Rows
Pages
----v----1----v----2----v----3----v----4----v----5----v----6----v----7----v-------------------------DA0021T.EMP
DADB2 DATD2DB2
1
-1
-1
DA0021T."EMPL.DEPT"
DADB2 DATT2001
3 1
-1
-1
DA0021T."EMPL.EMP"
DADB2 DATT2001
8 1
-1
-1
DA0021T."EMPL.PINF"
DADB2 DATD2DB2
7 1
-1
PKDA0021T.EMPLOYEE
DADB2 DATD2DB2
9 1
-1
-1
DA0021T.EMPTAB
DADB2 DATD2DB2
4
-1
-1
DA0021T.EMPTABLE
DADB2 DATD2DB2
6
-1
-1
DA0021T.EMPTABLE1
DADB2 DATD2DB2
5
-1
-1
DA0021T.EMP1
DADB2 DATD2DB2
4
-1
-1

- 68 -

DB2

DST2-R ---------------------- Primary Key List ------------------ Row 1 of 2

Command ===>
Scroll ===> PAGE
02
CMD will show commands for this list. Type command and press ENTER

QUALIFIER: TABLE=DA0021T.EMPLOYEE
Cmd Referenced Table/Column
Constrnt R Dependent Table/Column
----v----1----v----2----v----3----v----4----v----5----v----6----v----7----v--DA0021T.EMPLOYEE
EMPNO
******************************* Bottom of data ********************************

- 69 -

DB2

Fields of Sql Communication Area

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
PIC X(8).

- 70 -

DB2

SQL WARNINGS
SQLWARN0 - This indicates that any of the following warnings
are flagged.
SQLWARN1 - This is flagged if a value is truncated when
assigned to a host variable
SQLWARN2 - This is set to W if some of the rows werent
considered by a column function because the
column being processed contained null values
SQLWARN3 - Here a W means you did not supply enough host
variables in an into clause to match the columns in
a select clause
SQLWARN4 - This flag is set to W if a dynamic SQL update or
delete statement does not have a Where clause
SQLWARN5 - This indicates that the SQL statement is valid only
in SQL/DS and not in DB2
SQLWARN6 - This indicates a W when an arithmetic operation
produces an unusual date or timestamp

- 71 -

DB2

SQL WARNINGS
SQLERRD is an array of six full word items.The third of the six, contains
useful information.
After an insert,delete or update statement, sqlerrd(3) contains the no.
rows the statement affected.
Eg.
EXEC SQL
DELETE FROM EMP
WHERE DNO IN
(SELECT DNO FROM MASTER_DEPT)
END-EXEC.
Display SQLERRD(3) ROWS WERE DELETED.

- 72 -

DB2

DB2 ERROR CODES

SQLCODE

Keyword

Meaning

+100

SELECT

+304

Program

-305

Variables

-501

Cursor

-551

Authority

-803
-805
-811

Updating
Plan
SELECT

Row not found during FETCH,

SELECT, UPDATE or DELETE
Value and host variable are
incompatible
Null value occurred, and no indicator
variable was defined
Cursor named in FETCH or CLOSE is
not open
You lack the authority to access the
named object, possibly because its
name is not spelled correctly
Duplicate keys not allowed
DBRM not bound into this plan
Embedded SELECT or sub select
returned more than one row

- 73 -

DB2

DB2 ERROR CODES

SQLCODE

Keyword

Meaning

-818

Plan

Timestamps in load module and plan

do not agree; program was probably
re-precompiled without being re-bound

-901

System

Mysterious system error, permits

running more SQL statements

-904

System

Unavailable resource; if resource

name is a table view, etc. this was
probably causes by contention and
re-trying the operation maywork; if
resource name is a 44 character
VSAM file name, the file has probably
been archived or deleted

-911

System

Deadlock or timeout, updates rolled

back

-913

System

Deadlock or timeout, updates not rolled

back

- 74 -

DB2

Appendix A ASSIGNMENTS

- 75 -

DB2

Consider the following tables :

Table : EMPLOYEE
EMPNO
ENAME
JOB
MGR
HIREDATE
SAL
COMM
DEPTNO

- INTEGER
PRIMARY KEY
- CHAR (20)
NOT NULL
- VARCHAR(10)
- INTEGER
- DATE
- DECIMAL(10, 2)
- DECIMAL(6, 2)
-INTEGER
FOREIGN KEY

Table: DEPT
DEPTNO
DNAME
LOCATION

- INTEGER PRIMARY KEY

- VARCHAR(10)
- VARCHAR(10)

I. Use SPUFI to execute the SQL statements

a) List employees hired after 01/09/81 and working in the accounting dept.
b) List the BIG BOSS of the company (who does not report to anyone).
c) List all the employees whose names begin with N and the third character is J.
d) List all employees hired during the year 82.
e) List all dept details from the DEPT table which has atleast one employee.
f) Count the total no. of clerks.
g) List the minimum salary of various categories of employees department
wise such that the salary is greater than 1500.
h) List the employees in the ascending order within each dept.
i) List the names of all the clerks along with the name of their departments.
j) Find the minimum salary of MANAGERS in various departments.

II. Generate Table Declaration and host variable structure for above tables using the
DB2I-DCLGEN option .
The dclgens should be stored in the same PDS where the source programs are.
III. Write a COBOL programs to :
a. Display the details of the highest paid employee.
b. Display the name and salary of the employee whose empno is as passed on as a
host variable . If the search returns a NULL value , a NULL INDICATOR
should be used to indicate the appropriate error message.

- 76 -

DB2

IV. Increase the commission of employees, who have completed one year of service with
following conditions. (The % increase is w.r.t the salary)
if salary > 10000 and salary < =15000 grant him a commission of 20%
if salary > 15000 and salary <= 20000 grant him a commission of 15%
if salary > 20000 grant him a commission of 10%
V. Compute and display the total salary of all the employees where the total salary is
calculated as TSAL = SALARY + COMMISSION. A additional commission of 10% of
salary is granted to those employees who work as salesmen in the firm.
(Hint : commission can be null)
Precompile, compile, linkedit, bind and execute the pgm using Jcls.

VI. Use a join to display the dept. name, the location and the other employee details of all
those employees who belong to department no. 10.

- 77 -

DB2

Appendix B - STANDARDS

- 78 -

DB2

APPLICATION CONSIDERATIONS
1.1 Keep the application plans small for easy maintenance otherwise, time may be
spent unnecessarily to find out as to which of the underlying objects that were used
in the plan that have been changed or dropped at the time of re-binding the plan.
1.2 Avoid the use of the variable length columns unless there is a potential saving.
However , when used, place them at the end of the row as this would improve
performance and at the same time allow the users the format they find the most
convenient.
1.3 Use not null for primary keys, null for foreign keys and not null with default
for other colums.
1.4 When using decimal fields, use odd precision i.e., use DEC(7,2) instead of DEC(6,2).

PROGRAMMING CONSIDERATIONS:

Apart from enforcement of host language programming standards, some of the

embedded SQL related programming practices are as follows:
Avoid the use of select * as this requires the program to have a variable for each
column defined. When table definitions are altered, select * will cause an abend.
Use select with a list of column names instead.
Avoid too many joins or subqueries. However a join should be given preference
over a subselect.
When binding DB2 programs, cursor stability should be used instead of repeatable
read because under cursor stability,DB2 locks the current page only while in RR, DB2
holds the page locks and releases them at the next commit point.
Use validate (bind) instead of validate (run) because validate at run time can cause
contention on the catalog tables because requiring more run time resources.
Do not lock table unless approved by the DBA.
Host variables must always have the same format as the corresponding table fields.
Preferably use dclgen to copy the generated structure in the program.
Never code an arithmetic expression as an operand to be compare d to a column in a
where clause because it degrades the performance of the sql statements.
Restrict the use of SELECT, DISTINCT, SELECT .UNION,ORDER BY AND
GROUP BY because they require DB2 to do an internal sort.
Use BETWEEN instead of >= & <=
Error checking
Every SQL statement execution is checked for the sql return code namely
SQLCODE. The check is made immediately after execution and the control is
passed to the appropriate section of the code based on the return codes.

- 79 -

DB2

PERFORMANCE IMPROVEMENT GUIDELINES:

Create more indexes.

Index creation is always at the cost of the space and poor performance during inserts,
updates and deletes but access can be made faster by defining suitable indexes.
Increase the sub-pages.
When locking is in effect, to maximize concurrency, data should be stored over large
number of pages. This can be controlled by increasing the sub-pages.
Use acquire(use)/release(commit) on bind.
The resources are acquired on use and released on commit. This option keeps the
resources for a shorter duration compared to the option acquire(allocate) / release(deallocate).
Use validate(bind). This option is preferred to validate(run) since validate(run) would
check for validity at bind time and re-check at run time for every run.
Reduce internal DB2 sorts.

- 80 -

DB2

Appendix C - BIBLOGRAPHY

- 81 -

DB2

BIBLIOGRAPHY
1. A Guide to DB2

: C.J. Date

2. The DB2 Experts Guide : Bruce Larson

3. IBM DB2 Application
Programming & SQL Guide
4. IBM Database 2
General Information
5. DB2 Developers Guide : Craig Mullins

- 82 -