mainframe vol-ii version 1.2

7/31/2019 Mainframe Vol-II Version 1.2

1/246

Mainframe Application Programming

Volume II: DB2, CICS


2/246

Maples ESM Technologies Pvt. Ltd Page 2 of 246

INDEX

DB2 ............................................................................................................................................... 3

Chapter 1 : Introduction to RDBMS .................................................................................. 4

Chapter 2 : Overview of DB2/UDB ver 7 for OS/390 ...................................................... 12

Chapter 3 : DB2 Objects ................................................................................................... 13

Chapter 4 : Structured Query Language ........................................................................ 18

Chapter 5 : DB2 Interfaces ............................................................................................... 46

Chapter 6 : DB2 Application Development Overview ................................................... 47

Chapter 7 : SQL Execution Validation ............................................................................ 83

Chapter 8 : Advanced SQL .............................................................................................. 86

Chapter 9 : Performance Monitoring/Tuning ................................................................. 95

Chapter 10 : Locking and Concurrency ........................................................................ 101

Chapter 11 : DB2 Utilities ................................................................................................ 106

Chapter 12 : DB2 Environment for OS/390 and Z/OS ................................................... 110

Appendix ........................................................................................................................... 113

CICS........................................................................................................................................... 140

Objective ........................................................................................................................... 141

Introduction to CICS ........................................................................................................ 141

Application Programming Concepts ............................................................................. 158

Exceptional Conditions ................................................................................................... 167

Basic Mapping Support ................................................................................................... 182

File Control ....................................................................................................................... 199

CICS File Handling Program ........................................................................................... 207

Queues .............................................................................................................................. 210

Communication with Databases .................................................................................... 221

Common Abend Codes ................................................................................................... 236

CICS Commands Summary ........................................................................................... 240

Glossary ............................................................................................................................ 243


3/246

DB2


DB2

(DATABASE 2)


4/246

DB2


Objective

Before learning the details of coding DB2 COBOL programs, you need to know some basic

RDBMS concepts and terms. In this chapter you will learn about DB2 Object, SQL Queries with

SPUFI and QMF. After you are introduced to DB2 Basics and SQL processing, you wuill learning

how the application program gets communicated to DB2 and processing steps involved in

that.Then coding of Embedded SQL in Applicaion program with SQLCA and DCLGEN member.

Also you will be learning how to retrieve and process multiple rows into application programming

for processing. At the end of module performance tuning parameters and utilities in DB2 is

described for you.

Chapter 1 : Introduction to RDBMS

Relational Database is a collection of programs that enables user to create and maintain a

database based on formal mathematical concepts and definitions. It has to maintain the data

integrity and data consistency. In relational database, the datas are arranged in row and column

wise and there is only one value for each column. RDBMS is nothing more than a computer-

based record keeping system, i.e. data stored in the form of tables, which consists of multiple

rows and columns.

Examples: DB2, ORACLE, SYBASE, INGRES, etc

Relational Concepts (Terminology)

Relation : A table or File

Tuple : Row contains an entry for each attribute

Attributes : Columns or the characteristics that define the entity

Domain : A range of values (or Pool)

Entity : Some object about which we wish to store information

Null : Represents an unknown/empty value

Atomic Value : Smallest unit of data; the individual data value

Candidate key : Some attribute (or a set of attributes) that may uniquely identify each row

(tuple) in the relation (table)

Primary key : The candidate key is chosen for primary attributes to uniquely identify

each row.


5/246

DB2


Alternate key : The remaining candidate keys that were not chosen as primary key

Foreign key : An attribute of one relation that might be a primary key of another

relation.

Advantages of RDBMS over File Management Systems

Data redundancy

Multiple views

Shared data

Data independence (logical/physical)

Data dictionary

Search versatility

Cost effective Security & Control

Recovery restart & Backup

Concurrency

CODDs Relational Rules

1. All information in a relational database is represented explicitly at the logical level and in

exactly one way - by values in tables

2. Each and every datum(atomic value) in a relational database is guaranteed to be logically

accessible by resorting to a combination of table name, primary key value, and column name

3. Null values are supported for representing missing information in a systematic way

irrespective of the data type.

4. The database description is represented at the logical level in the same way as ordinary data,

so that authorized users can apply the same relational language to its interrogation as they

apply to the regular data.

5. A relational system may support several languages and various modes of terminal use.

However there must be one language whose statements can express all of the following

items: (1) data definitions (2) view definitions (3) data manipulation (interactive and by

program) (4) integrity constraints (5) authorization (6) transaction boundaries (begin, commit,

rollback)

6. All views are theoretically updatable, are also updatable by the system


6/246

DB2


7. The capability of handling a base relation or a derived relation (view) as a single operand

applies not only to the retrieval of data but also to the insertion, updation and deletion of data

8. Application programs and terminal activities remain logically unimpaired whenever any

changes are made in either storage representations or access methods

9. Application programs and terminal activities remain logically unimpaired when information-

preserving changes of any kind that theoretically permit unimpairment are made to the base

tables.

10. Integrity constraints specific to a particular relational database must be definable in relational

data sublanguage and storable in the catalog, not in application programs.

11. The data manipulation sublanguage of a relational DBMS must enable application programs

and inquiries to remain logically the same whether and whenever data are physically

centralized or distributed.

12. If a relational system has a low-level (single-record-at-a-time) language, that low level cannot

be used to subvert or bypass the integrity rules and constraints expressed in the higher-levelrelational language (multiple-records-at-a-time)

Normalisation

Normalization is a database design approach that minimizes data redundancy and optimizes data

structures by systematically and properly placing data elements into appropriate groupings. A

normalized data model can be translated into a physical database that is organized correctly.

Another way of putting it is that normalization is the process of putting one fact in one appropriate

place.E.F Codd, the father of the relational model, also created normalization. Like the relational

model, normalization is based on the mathematical principles of set theory. With a normalized

data model, one fact is stored in one place, related facts about a single entity are stored together,

and every column of each entity refers non-transitively to only the unique identifier for that entity.

The data in the database can be considered to be in one of a number of `normal forms'. Basically

the normal form of the data indicates how much redundancy is in that data. The normal forms

have a strict ordering:

1. First Normal Form2. Second Normal Form

3. Third Normal Form

Employee and Projects example illustrates the above three Normalisation

The table below depicts the requirements for a business consultancy working on local andinternational projects.


7/246

DB2


Emp-No

Emp-Name

Dept Manager Proj-id

Proj-Start-Date

Location Weeks-on-Project

005 Smith Marketing Jones ABC

12-936-9409-94

PoolePlymouthPortsmouth

11156

007 Bond Accounts Bloggs BD 06-9406-94 PlymouthBerlin 39

009 King InfoSystems

Hurne C 09-94 Portsmouth 10

010 Holt Accounts Bloggs ABD

12-9306-9406-94

PooleBelfastHamburg

211012

Notes: Employees work on a number of projects concurrently. Weeks-on-projectrepresents the

number of weeks to date that an employee has spent on a particular project. The employee

number, emp-no, and the project identifier, project-id, are unique identifiers. The department

manager, manager, is the name of the current manager, i.e., there can only be one manager per

department. A project can take place in several locations.

You are required to show the first, second and third normal forms. Explain the normalisation

process used.

First Normal Form

Relations in first normal form represent data as a set of tuples each of which is uniquely identified

by a primary key value. The most difficult part of constructing a first normal form set of relations is

identifying the primary key for each relation. It is best to select the primary key attributes which

reduce the number of attributes that repeat. An attribute repeats when it contains two or more

values for each value of the primary key. The following guidelines should produce a set of first

normal form relations.

1. Select a primary key for the set of attributes.

2. Identify the set of attributes which repeats for each value of this primary key.

3. Create a relation from the attributes which are not in the repeating group.

4. Make the key of this relation the key identified in (a).

5. Identify the primary key for the repeating group by taking each value of the primary key in

(a) and identifying a unique attribute(s) in the repeating group.6. Create a relation from the attributes in the repeating group and the primary key identified

in (a).

7. Make the key for this relation the key identified in (e) and (if the key in (e) is not unique)the key identified in (a).

8. If the repeating group contains a set of attributes which repeat then apply the guidelinesfrom (a).

In this example:


8/246

DB2


1. The primary key is emp-no.

2. The set of attributes which repeat for each value ofemp-noare proj-id, proj-start-date,

location, and weeks-on-project.

3. Removing these attributes from the full attribute set produces the relation:

(emp-no, emp-name, dept, manager)

4. The primary key is emp-no.

(emp-no, emp-name, dept, manager)

5. The primary key for the repeating group is proj_id. This is because for each emp_nothe

proj_id uniquely identifies the proj-start-date, location, and weeks-on-project attributes.

For example, for employee 005, project A is always in Poole and weeks on project is

always 11.

6. The new relation is:

(emp-no, proj-id, proj-start-date, location, weeks-on-project)

7. The primary key for the repeating group, proj-id, is not unique in this relation and so the

key of this relation is (emp-no, proj-id).

(emp-no, proj-id, proj-start-date, location, weeks-on-project)

8. There are no more repeating groups.

The first normal form relations are:

employee1(emp-no, emp-name, dept, manager)

emp-on-proj1(emp-no, proj-id, proj-start-date, location, weeks-on)

Second Normal Form

Relations which are in second normal form contain no partial key dependencies. A partial

dependency occurs in a relation when a non-key attribute depends on only part of the primary

key. A partial dependency can only occur in a relation with a composite key. If we have a

relation in first normal form with three attributes:

R(A,B,C)

As the primary key is unique the following dependencies must be true:

(A,B) -> C "C depends on A and B together. A and B together determine C."


9/246

DB2


This means that each time a value of A,B occurs in the database the same values for C occurs.

For example, in the above relation every time that employee 5 occurs and the project-id is A, the

location is always Poole. That is, emp-idand proj-iddetermine the location.

A partial dependency exists when only some of the attributes in a composite key are required to

determine a non-key attribute. That is, a partial dependency occurs if one of the followingdependencies is true:

A -> C "C depends on A alone. A alone determines C."

B -> C "C depends on B alone. B alone determines C."

Assuming that the dependency B->C holds then R must be decomposed into two relations:

R1(A,B)

R2(B,C)

In the example, only one of the first normal form relations, emp-on-proj1, has a composite key

and so it is the only relation which can have a partial dependency. The following dependencies

are true in this relation:

emp-no,proj-id -> proj-start-date, location, weeks_on The primary key determines all attributes.

proj-id -> proj-start-date

The project start date depends on the

project and is the same for allemployees.

This is a problem because each tuple in emp-on-proj1 which contains the same proj-idvalue will

also have the same proj-start-date. For example, all tuples with proj-id="A" will also have proj-

start-date="12-93". Therefore, we remove the proj-start-dateattribute to a new relation which has

a primary key composed of those attributes on which proj-start-dateis partially dependent:

emp-on-proj2(emp-no, proj-id, location, weeks-on)

project2(proj-id, proj-start-date)

The key ofemp-on-projis the same in first normal form and second normal form. The final set of

second normal form relations are:

employee2(emp-no, emp-name, dept, manager)




10/246

DB2


Third Normal Form

Third normal form relations contain no transitive dependencies. A transitive dependency occurs

when one or more attributes are determined by one or more attributes which are not part of the

primary key. If we have a relation:

R(A,B,C)

then because the primary key determines every attribute in the relation the following

dependencies must be true:

A -> B "B depends on A alone. A alone determines B."

A -> C "C depends on A alone. A alone determines C."

For example, in employee2, emp-nodetermines both emp-name, dept, and manager. If the

following dependency is also true:

B -> C "C depends on B alone. B alone determines C."

then R contains the transitive dependency:

A -> B -> C "C depends on B and B depends on A""

This is a problem because for every value of B the attribute C will always have the same value.

For example, in employee2, when the deptattribute contains "Accounts" the managerattribute

always contains "Bloggs".

To resolve this problem relation R should be decomposed into two relations:

R1(A,B)

R2(B,C)

In the above example the relation employee2contains the transitive dependency:

emp-no -> dept -> manager

Therefore, the employee2relation can be decomposed into two relations:

employee3(emp-no, emp-name, dept)

department3(dept, manager)

There are no transitive dependencies in the other relations and the final set of third normal form

relations are:

employee3(emp-no, emp-name, dept)

department3(dept, manager)




11/246

DB2


Denormalization:

Speeding the retrieval of data from DB2 tables is a frequent requirement for DBAs and

performance analysts. One way to accomplish this is to denormalize DB2 tables for physical

implementation. The opposite of normalization, denormalization is the process of putting one fact

in many places. This speeds data retrieval at the expense of data modification. This is not

necessarily a bad decision, but should be undertaken only when a completely normalized design

will not perform optimally.


12/246

DB2


Chapter 2 : Overview of DB2/UDB ver 7 for OS/390

DB2 for OS/390 and z/OS is a relational database management system that is the foundation of

many e-business, business intelligence, and mission-critical systems. It is the primary focus of

this certification guide. DB2 for OS/390 and z/OS is the largest of the DB2 family, often serving as

an enterprise server handling many of the largest applications in the world. The environment

provided by System/390 and either OS/390, or z/OS is IBMs largest and most powerful, providing

the most scalable and available platform.

The DB2 Universal Database (DB2 UDB) family of products is available for S/390, zSeries, UNIX

and Intel platforms. DB2 has the ability to store all kinds of electronic information. This includes

traditional relational data as well as structured and unstructured binary information, documents

and text in many languages, graphics, images, multimedia (audio and video), information specific

to business needs such as engineering drawings, maps, insurance claims, forms, numerical

control streams, or any type of electronic information.

The DB2 database is an important part of IBMs e -business software portfolio. The e-business

Application Framework provides an open blueprint on how to build e-business applications.

The DB2 code base is optimized for each platform to ensure maximum performance. The SQL

API is common to all platforms, which allows applications written on one platform to access data

on any platform. Internally, DB2 on the OS/400, VM/VSE, and OS/390 differ from Db2 on the

UNIX and Intel Platforms, but it is the common SQL API that enables applications to work

together. The DB2 code base on Intel and UNIX platforms are identical.

DB2 Migration from OS/390 to Z/OS

Installation is the process of preparing DB2 to operate as an OS/390 or Z/OS Subsystem.

Migration is the process of upgrading from a release of DB2 to a more current release.

There are many issues when migrating to a data sharing environment, but with careful planning

and testing the process can be made to go very smoothly.


13/246

DB2


Chapter 3 : DB2 Objects

System Objects

DB2 Catalog

The DB2 catalog and directory act as central repositories for all information about objects,

authorizations and communications regarding the support and operations of DB2.

The catalog is composed of several DB2 tables and can be accessed via SQL. The catalog

contains details about DB2 objects obtained from the DDL. It consists of tables of data about

every object defined in the DB2 system. When an object is created, altered or dropped, a row is

inserted, updated or deleted in the Catalog.

DB2 Directory

The DB2 directory is used to store information regarding the operation and housekeeping of the

DB2 environment, and it cannot be accessed by using SQL, as the DB2 catalog can be

accessed. It contains information required to start DB2, and there are activities and utilities in theDB2 environment. Directory objects are not described in DB2 catalog

Bootstrap Dataset

Contains inventory of all active and archive log datasets. During installation of DB2, two BSDS

datasets are created, and are kept in different volumes.

BSDS (Boot Strap Data Set):

It is a VSAM key sequenced data sets known to DB2. It is an inventory of all active log and

archive log data set known to DB2. Db2 uses this information to track the active and archive log

data set. It is an inventory of the Bufferpools used.


14/246

DB2


Active & Archive Logs

DB2 records all data changes and significant events in active logs as they occur. In case of

failure, it uses this data to recover the lost information. When the active log is full, DB2 copies the

contents of the active log to a DASD or magnetic tape data set called archive logs.

Buffer Pools

Buffer pools are areas of virtual storage in which DB2 temporarily stores pages of table spaces or

indexes.

When an application program accesses a row of a table, DB2 retrieves the page containing that

row and places the page in a buffer, when row is required again, the application program does

not have to wait for it to be retrieved from DASD, significantly reducing the cost of retrieving the

page.

Locks

DB2 guarantees data integrity by using several locking mechanisms. These strategies permits

multiple users from multiple environments to access and modify data concurrently without loss ofdata integrity.

DB2 supports locking at four levels.

Table Space Level

Table Level

Page Level

Row Level.

DB2 uses locks to control concurrency & prevent inconsistent data.


15/246

DB2


Data Objects

Accessed and organized by the user but controlled by DB2.

Stogroup

It is a collection of direct access volumes, all of the same device type

The option is defined as a part of tablespace definition

When a given space needs to be extended, storage is acquired from appropriate stogroup

Database

A collection of logically related objects - like Tablespaces, Indexspaces, Tables etc.

Not a physical kind of object - may occupy more than one disk space

A STOGROUP & BUFFERPOOL (is buffer area used to maintain recently accessed table

and index pages) must be defined for each database.

Stogroup and user-defined VSAM are the two storage allocations for a DB2 dataset

definition.

In a given database, all the spaces need not have the same stogroup

These are, in a sense, the most physical of various storage objects in DB2

More than one volume can be defined in a stogroup. DB2 keeps track of which volume was

defined first & uses that volume.

Tablespaces:

Logical address space on secondary storage to hold one or more tables

A SPACE is basically an extendable collection of pages with each page of size 4K or 32K

bytes.

It is the storage unit for recovery and reorganizing purpose

Three Type of Tablespaces - Simple, Partitioned & Segmented


16/246

DB2


Simple Tablespaces

Can contain more than one stored table

Depending on application, storing more than one Table might enable faster retrieval for joins

using these tables

Usually only one is preferred. This is because a single page can contain rows from all tables

defined in the database.

LOAD with replace option deletes all data

Segmented Tablespaces

Can contain more than one stored table, but in a segmented space

A Segment consists of a logically contiguous set of n pages.

Segsize parameter decides the allocation size for the tablespace

No segment is allowed to contain records for more than one table

Sequential access to a particular table is more efficient

Mass Delete is much more efficient than in any other Tablespace

Reorganizing the tablespace will restore every table to its clustered order

Lock Table on table locks only the table, not the entire tablespace

If a table is dropped, the space for that table can be reclaimed with minimum REORG

Partitioned Tablespaces

Primarily used for Very large tables

Only one table in a partitioned TS; 1 to 64 partitions/TS

Numpart parameter specifies the no. of partitions

It is partitioned in accordance with value ranges for single or a combination of columns.

Hence these column(s) cannot be updated

Individual partitions can be independently recovered and reorganized

Different partitions can be stored on different storage groups for efficient access.


17/246

DB2


Tables

All data is stored in tables.

A table is a collection of rows, all having same columns

Rows are records and Columns are fields.

Intersection of a column & row is a Value

SQL is used to access data in DB2 tables.

Indexes

An ordered set of pointers to the data in DB2 table

Stored separately from the table

Each index occupies its own space

Used to Improve performance; Ensure Uniqueness

Multiple indexes can be defined on a table

A table having a primary key will necessarily have a primary unique index.

Views

Is a virtual table derived from one or more base tables

The view definition is stored in a catalog.

View is an alternate way of representing data that exists in one or more tables

Can include all or some of the columns from one or more base tables

Indexes on Base table can improve the performance operations on the views


18/246

DB2


Chapter 4 : Structured Query Language

Structured Query Language (SQL) is a powerful tool for manipulating data. Also, it is the standard

query language for relational database management systems (RDBMS). It is not only used by

DB2, but also by the other leading RDBMS products such as Oracle, Sybase and Informix.

SQL is fashioned so that the programmer can specify what data is needed but cannot specify

how to retrieve it.

When a user issues the SQL request, it is sent to the DBMS. This request may need to access

one or many DB2 tables. The DBMS analyses the SQL request and determine which pieces of

information are necessary to resolve the users request.

One retrieval statement can return more than one row. Similarly, one modification statement can

modify multiple rows.

A single SQL statement can produce an entire report.

Another feature of SQL is that it is not merely a query language. The same language can also be

used to define data structures, control access to the data, and insert, modify and delete

occurrences of the data. This consolidation of functions into a single language eases

communication between different types of users like DBAs, system programmers, application

programmers, system analysts, system designers and end users.

A simple query goes like

SELECT EMPNAME FROM EMP WHERE EMPNO = 12345;

Record level processing is one where we read each and every record separately and then

process the same.

SQLs are categorized based on its functionality. SQL can be used to control, define and

manipulate data.

Data Definition Language (DDL) creates and maintains the physical data structure with the

CREATE, DROP and ALTER verbs.


19/246

DB2


Data Manipulation Language (DML) accesses and modifies data with the SELECT, INSERT,

DELETE and UPDATE verbs.

Data Control Language (DCL) provides the control statements that govern data security with the

GRANT and REVOKE verbs.

Another way to categorize SQL is by execution type. SQL can be planned and executed as

embedded SQL in an application program or it can be unplanned (ad hoc).

Embedded SQLs are well defined and can be planned before the execution of the SQL. Example

is batch processing.

Ad-hoc SQL is undefined until an immediate need is identified. Upon identification, an unplannedquery is composed and executed. Example is information center queries.

One more way to categorize SQL is according to its dynamism. This is probably the most difficult

one to define and provides the greatest flexibility of all the categories. SQL can either be static or

dynamic.

Static SQL is the one, which is embedded in an application program written in a high-level

language.

Dynamic SQL is either typed in at a terminal for real time execution or constructed in an

application programs at runtime.

Data Types

Integer - A column of whole numbers, positive or negative

PIC S9 (09) COMP 4 byte binary integer.

Smallint - PIC S9 (04) COMP 2 byte binary integer

Decimal (x, y) - A column of decimal numbers, where x is the maximum length in digits of

the decimal numbers in this column, and y is the maximum number of

digits allowed after the decimal point. The maximum (4, 2) number would

be 99.99.


20/246

DB2


Char (n) - A column of characters, where n is a number designating the maximum

number of characters allowed (maximum length) in the column.

PIC X(n).

Varchar (n) - A column of characters, where n is a number designating the maximum

number of characters allowed (maximum length) in the column.

01 VAR.

49 Var1 PIC S9 (04) COMP.

49 Var2 PIC X (n).

Date - PIC X (10) YYYYMMDD

4 bytes 8 unsigned packed decimal digits

Time - PIC X (08) HHMMSS 3 bytes - 6 unsigned packed decimal digits.

Timestamp - PIC X (26) YYYYMMDDHHMMSS 20 bytes - 20 unsigned packed

decimal digits.

DB2 Database Design

DB2 Data Types

Datatype COBOL Declaration

SMALLINT 01 Var PIC S9 (4)Comp

INTEGER 01 Var PIC S9(9) Comp

DECIMAL (X,Y) 01 Var PIC S9(X)v(9)(Y) Comp-3

CHAR (N) 01 Var PIC X(N)

VARCHAR (N) 01 Var

49 Var-len PIC S9(4) Comp

49 Var-text PIC X(N)

DATE 01 Var PIC X(10)

TIME 01 Var PIC X(8)

TIMESTAMP 01 Var PIC X(26)

Numeric

Character

Graphics

Data/Time

User Defined Types


21/246

DB2


Numeric Formats

Smallint - Binary half word

Integer - Binary full word

Decimal(x,y) - can be read as X numeric digits of which the last Y to be decimal fraction.

Character String Formats

CHAR (X) - O to 255 length

VARCHAR (X) - Page Size

LONG VARCHAR

Date/Time Formats

Date - YYYYMMDD

Time - HHMMSS

Time Stamp - YYYYMMDDHHMMSSNNNNNN

Nulls

Every column has a Null characteristic.(Rule for when a value is not available)

NOT NULL

ALLOW NULL

NOT NULL WITH DEFAULT

Not Null - Value must be given

Allow Null - If value is not given it is marked UNKNOWN

Not Null with Default - If value is not given, DB2 fills the Default Value

Numeric Becomes Zero, Character Becomes Blank, Date becomes Current Date, Time becomes

Current Time, Timestamp becomes Current Timestamp.


22/246

DB2


Using Nulls

A null is used to record missing or unknown information.

For example, a table contains information on the hair color of employees. Three new employeesare added today; a man with a black hair, a woman with unknown hair color and a bald man. The

woman with unknown hair color and the bald man both could be assigned null HAIR_COLOR.

DB2 does not differentiate between nulls that signify unknown data.

DB2 represents null in a variable known as indicator variable. An indicator variable is defined to

DB2 for each column that can accept nulls. The indicator variable must be provided while

programming.

The default definition for columns in a DB2 table is to allow nulls. Nulls can be prohibited for a

column by specifying the NOT NULL or NOT NULL WITH DEFAULT option in the CREATE

TABLE statement.

Avoid nulls in columns that must participate in arithmetic logic. The AVG, COUNT DISTINCT,

SUM, MAX & MIN functions omit column occurrences set to null. The COUNT (*) function,

however, doesnt omit columns set to null because it operates on rows.

Consider these rules:

Nulls are considered to be equal when duplicates are eliminated by SELECT DISTINCT or

COUNT.

When a nullable column participates in a calculation, the result is null.

Columns that participate in a primary key cannot be null.

To test for the existence of nulls, use the special predicate IS NULL in the WHERE clause of

the SELECT statement. You must state WHERE column IS NULL.

You can assign a column to null using the = predicate in the SET clause of the UPDATE

statement.

Processing Rules

Every Primary key value is unique and is not null.

Every Foreign key value matches a primary key.


23/246

DB2


EMP No EMP Name Dept No Salary

Dept No Dept Name Bonus

Group

Primary Key Foreign Key

Primary Key

Terms

Referential Constraint: The Limiting of a set of Foreign Key Values to a set of primary key values

Referential Integrity: The automatic enforcement of referential constraints

DB2 Table Parameters

Data type Default Value

Numeric Zero

Fixed-length string Blanks

Varying-length string String of length zero

Date Current date

Time Current time

Timestamp Current timestamp

Primary Key:

The primary key of a table is a column (or a combination of number of column) from that table

which can be used for uniquely identifying rows in the table and it should be declared as not null

column.

Candidate Key:

Some tables contain more than one column (or combination of columns) that can act as a primary

key. These columns possess all the properties of a primary key and are called candidate keys.

Alternate Key:

A candidate key that is not the primary key of a table is called an alternate key.

Foreign Key:

Identifies a row of related data in another table


24/246

DB2


Referential Integrity:

A mechanism that ensures data integrity between tables related by Primary and Foreign Keys. It

is the relationships among different columns and tables in a relational database. The values in

one column or set of columns refer to or must match the values in a related column or set of

columns.

Referential Integrity Rules:

Insert Rules

When inserting a row with the foreign key, DB2 checks the value of the foreign key columns

against the value of the primary key columns in the parent table. If no matching primary key

columns are found, the insert is disallowed. A new primary key can be inserted as long as it is

unique.

You cannot insert a row into a dependent table unless there is a row in the parent table with a

parent key value equal to the foreign key value of the row that is being inserted unless the foreign

key value is null. If an INSERT operation fails for one row during an attempt to insert more than

one row, all rows inserted by the statement are removed from the database.

Update Rules

When updating foreign key values, DB2 performs the same checks as when it is inserting a row

with a foreign key.

Delete Rules

When a row with a primary key is deleted what should be done about the rows with matching

foreign keys

Designer chooses one of CASCADE, SET NULL, RESTRICT

Cascade When a row of the parent table is deleted, any related rows in the dependent table are

also deleted.


25/246

DB2


Restrict Rows of parent table that have dependent rows cannot be deleted.

Set Null When a row of a parent is deleted, the corresponding values of the foreign key in any

dependent rows are set to null.

Data Definition Language

Let us consider for our discussions EMP table and DEPT table. How can we create DEPT table

and EMP table?

CREATE STATEMENT

DEPT TABLECREATE TABLE DEPT

(DEPTNO CHAR(4) NOT NULL PRIMARY KEY,

DEPTNAME CHAR(10) NOT NULL) IN .

If you do not give a database name and a tablespace name the table would get created in the

default database for which users may not have permissions. So ask your DBA the database

name and tablespace name and then create the table.

In the DEPT table created above we have mentioned the deptno as the primary key. The

primary key has to be declared as NOT NULL. Primary key will not allow any duplicates. So the

table should have an UNIQUE INDEX on the column defined as primary key - otherwise the

table definition would be incomplete and DB2 does not allow any manipulations on the table.

So the next step is to create a unique index

CREATE UNIQUE INDEX inddept on DEPT (DEPTNO);

Now the table definition becomes complete and DB2 allows you to start your operations on the

table. Let us create the EMP table that contains a Foreign Key to the DEPT table.

CREATE STATEMENT

EMP TABLE

CREATE TABLE EMP

(EMPNO CHAR(4) NOT NULL PRIMARY KEY,


26/246

DB2


EMPNAME CHAR(10) NOT NULL,

DEPTNO CHAR(4),

SALARY DECIMAL(7,2) NOT NULL

FOREIGN KEY(DEPTNO) REFERENCES DEPT

ON DELETE CASCADE) IN .

ALTER STATEMENT

ALTER TABLE DEPT

ADD PRIMARY KEY (DEPTNO);

ALTER TABLE DEPT

DROP PRIMARY KEY;

ALTER TABLE DEPTADD NOOFEMP SMALLINT;

DROP STATEMENT

DROP TABLE DEPT;

Data Manipulation Language (DML)

SQL Single row INSERT

INSERT INTO DEPT VALUES(D001,FINANCE)

INSERT INTO EMP

VALUES(E001,ABC,D001,25000)

INSERT INTO EMP(EMPNO,EMPNAME,SALARY)

VALUES (E002, DEF, 21000)

INSERT INTO EMP

VALUES(E003,UVW, NULL, 14000)


27/246

DB2


UPDATE a value in single row

UPDATE EMP SET DEPTNO = D002

WHERE EMPNO = E002;

UPDATE multiple values in a single row

UPDATE EMP SET DEPTNO = D003, SALARY=SALARY +1000

WHERE EMPNO = E003;

UPDATE multiple rows using a single UPDATE statement

UPDATE EMP SET SALARY + 1000

WHERE DEPTNO = D001;

DELETE single row

DELETE FROM EMP WHERE EMPNO=E001

DELETE multiple rows

DELETE FROM EMP WHERE SALARY > 20000

DELETE ALL rows

DELETE FROM EMP

Selection and Projection

The selection operation retrieves a specified subset of rows from a DB2 table. WHERE clause is

to specify the search criteria.

SELECT * FROM EMP WHERE DEPTNO = D001;

To retrieve all rows from a table, discard the WHERE clause from the statement.

The projection operation retrieves a specified subset of columns from a given DB2 table.

Projection retrieves all of the rows but only the specified columns.

SELECT EMPNAME, DEPTNO, SALARY FROM EMP;


28/246

DB2


To be simpler, the selection operation determines which rows are retrieved and the projection

operation determines which columns are retrieved.

In most cases, queries combine selection and projection to retrieve data.

The following SQL statement combines the selection and projection operations in the preceding

two examples.

SELECT EMPNAME, DEPTNO, SALARY FROM EMP WHERE DEPTNO = D001;

Simple Retrieval

SELECT * FROM EMP;

Unique Retrieval

SELECT DISTINCT DEPTNO FROM EMP;

Computed Values Retrieval

SELECT EMPNO, SALARY * 1.1 FROM EMP;

Qualified Retrieval

SELECT EMPNO FROM EMP

WHERE DEPTNO= D001;

Retrieval with Ordering

SELECT EMPNO, SALARY FROM EMP

ORDER BY DEPTNO;

SELECT EMPNO, SALARY FROM EMP

ORDER BY DEPTNO DESC;

Retrieval using BETWEEN


WHERE SALARY BETWEEN 10000 AND 150000


29/246

DB2


THE ABOVE QUERY CAN ALSO BE WRITTEN AS


WHERE SALARY >= 10000 AND SALARY 15000

Retrieval using IN


WHERE DEPTNO IN (D001,D002)

THE ABOVE QUERY CAN ALSO BE WRITTEN AS


WHERE DEPTNO = D001 OR DEPTNO=D002

AND & OR can be combined, for example:


WHERE DEPTNO = 'D001' OR DEPTNO =D002 AND SALARY > 60000;

First, SQL finds the rows where the salary is greater than $60,000 and the department number is

D002. Then it also finds out the list of rows where the department number is D001. Note that the

AND operation is done first.

To generalize this process, SQL performs the AND operation to determine the rows where the

AND operation holds true (remember: all of the conditions are true). Then, these results are used

to compare with the OR conditions, and display those remaining rows where any of the conditions

joined by the OR operator holds true. Mathematically, SQL evaluates all of the conditions, then

evaluates the AND "pairs", and then evaluates the OR's (where both operators evaluate left to

right).


30/246

DB2


True AND False OR True AND True OR False AND False

First simplify the AND pairs:

False OR True OR False

Now do the OR's, left to right:

True OR False

True

The result is True, and the row passes the query conditions. Be sure to see the next section on

NOT's, and the order of logical operations.

To perform OR's before ANDs, like if you wanted to see a list of employees who belong to either

department D001 or in D002 but their salary should be greater than 60000, use parentheses:

SELECT EMPNO FROM EMPWHERE (DEPTNO = 'D001' OR DEPTNO =D002 )AND SALARY > 60000;

Retrieval using LIKE

SELECT EMPNAME,DEPTNO FROM EMP

WHERE EMPNAME LIKE A%;

SELECT EMPNAME,DEPTNO FROM EMP

WHERE EMPNAME LIKE _A%;

% MATCHES ZERO OR MORE CHARACTERS

_ (UNDERSCORE) MATCHES SINGLE CHARACTER

Retrieval using NOT LIKE

SELECT EMPNAME FROM EMP WHERE EMPNAME NOT LIKE E%;

Retrieval involving NULL

SELECT NAME FROM EMP WHERE DEPTNO is NULL;

Retrieval involving NOT NULL

SELECT NAME FROM EMP WHERE DEPTNO is NOT NULL;


31/246

DB2


COLUMN and SCALAR functions

COLUMN functions

Column functions compute from a group of rows, a single value. They are AVG, COUNT, MAX,

MIN and SUM.

AVG - The AVG function computes the average of the column or expression

specified as an argument. This function operates only on numeric arguments.

SELECT AVG (SALARY) FROM EMP;

The above calculates the average salary of all employees.

COUNT- The COUNT function counts the number of rows in a table, or the number of

distinct values for a given column. It can operate, therefore, at the column or row level. The

syntax differs for each.

To count the number of rows in the EMP table, issue this SQL statement:

SELECT COUNT (*) FROM EMP;

To count the number of distinct departments represented in the EMP table, issue the following:

SELECT COUNT (DISTINCT DEPTNO) FROM EMP;

MAX - The MAX function returns the largest value in the specified column. The following

SQL statement determines the project with the latest end date.

SELECT MAX (SALARY) FROM EMP;

MIN - The MIN function returns the smallest value in the specified column. To retrieve

the lowest bonus given to any employee, issue this SQL statement.

SELECT MIN (SALARY) FROM EMP;


32/246

DB2


SUM - The accumulated total of all values in the specified column are returned by the

SUM column function.

For example, the following SQL statement calculates the total salary for all the employees:

SELECT SUM (SALARY) FROM EMP;

Some rules for the column functions:

Column functions can be executed only in SELECT statements.

Each column function returns only one value for the set of selected rows.

The result of any column function (except the COUNT function) will have the same date type

as the column to which it was applied. The COUNT function returns an integer number. The result of any column function (except the COUNT function) can be null. COUNT always

returns a numeric result.

Column functions will not return a SQLCODE of +100 if the predicate specified in the WHERE

clause finds no data. Instead, a null is returned.

For example, consider the following SQL statement:

SELECT MAX (SALARY) FROM EMP WHERE EMPNO = 999999;

There is no employee with an EMPNO of 999999 in the EMP table. This statement therefore

returns a null for the MAX (SALARY).

When using the AVG, MAX, MIN and SUM functions on nullable columns, all occurrences of

null are eliminated before applying the function.

You can use the DISTINCT keyword with all column functions to eliminate duplicates before

applying the given function. DISTINCT has no effect, however on the MAX and MIN

functions.

You can use the ALL keyword to indicate that duplicates should not be eliminated. ALL is the

default.


33/246

DB2


SCALAR functions

Scalar functions are applied to a column or expression and operate on a single value.

There are 22 scalar functions, each of which can be applied to a column value or expression.

CHAR - Converts a DB2 date, time, timestamp, or decimal value to a

character value.

COALESCE - For nullable columns, returns a value instead of a null

(equivalent to the VALUE function).

DATE - Converts a value representing a date to a DB2 date. The value

to be converted can be a DB2 timestamp, a DB2 date, a positive

integer or a character string.

DAY - Returns the day portion of a DB2 date or timestamp.DAYS - Converts a DB2 date or timestamp into an integer value

representing one more than the number of days since January

01, 0001.

DECIMAL - Converts any numeric value to a decimal value.

DIGITS - Converts a number to a character string of digits. Beware that

the DIGITS function will truncate the negative sign for negative

numbers.

FLOAT - Converts any numeric value to a floating-point value.

HEX - Converts any value other than a long string to a hexadecimal.HOUR - Returns the hour portion of a time, a timestamp, or duration.

INTEGER - Converts any number to an integer by truncating the portion of

the number to the right of the decimal point. If the whole number

of the portion is not a valid integer, an error results.

LENGTH - Returns the length of any column, which may be null. Does not

include the length of null indicators, but does include trailing

blanks for character columns.

NULLIF - Returns a null when two specified expressions are equal; if not

equal, the first expression is returned.

MICROSECOND - returns the microsecond portion of a timestamp.

MINUTE - Returns the minute portion of a time, timestamp or duration.

MONTH - Returns the month portion of a time, timestamp or duration.

SECOND - Returns the second portion of a time, timestamp or duration.


34/246

DB2


STRIP - Returns the leading, trailing, or both leading and trailing blanks

from a string expression.

SUBSTR - Returns the specified portion of a character column from any

starting point to any ending point.

TIME - Converts a value representing a valid time to a DB2 time. The

value to be converted can be a DB2 timestamp, a DB2 time, or a

character string.

TIMESTAMP - Obtains a timestamp from another timestamp, a valid character

string representation of a timestamp, or a combination of date

and time values.

VALUE - For nullable columns, returns a value instead of a null

(equivalent to COALESCE function).

VARGRAPHIC - Converts a character string to a graphic string.

YEAR - Returns the year portion of a date, a timestamp or duration.

Some rules for the scalar functions:

Scalar functions can be executed in the select list of the SQL SELECT statement or as part of

a WHERE or HAVING clause.

The argument for a scalar function can be a column function.

Sorting and Grouping

SQL can also sort and group retrieved data. The ORDER BY clause sorts the results of a query in

the specified order (ascending or descending) for each column. The GROUP BY clause collates

the resultant rows to apply functions that consolidate the data.

For example, the following query groups employee data by department, returning the aggregate

salary for each department.

SELECT DEPTNO, SUM (SALARY)

FROM EMP

GROUP BY DEPTNO;

By adding a HAVING clause to this query, you can eliminate aggregated data that is not required.


35/246

DB2


For example, if you are interested in departments with an average salary of less than $17, 500,

you can code the following query:


FROM EMP

GROUP BY DEPTNO

HAVING AVG (SALARY) < 17500;

The GROUP BY clause does not sort the data for the result set; it only consolidates the data

values for grouping. To return the results of this query in a particular order, you must use the

ORDER BY clause.

For example, to order the resultant data into descending department number order,


FROM DEP

GROUP BY DEPTNO

HAVING AVG (SALARY) < 17500

ORDER BY DEPTNO;

The ORDER BY, GROUP BY, HAVING clauses are important SQL features that can increase

productivity.

The Difference between HAVING and WHERE

The WHERE and HAVING clauses are similar in terms of functionality. However, they operate on

different types of data.

Any SQL statement can use a WHERE clause to indicate which rows of data are to be returned.

The HAVING clause operates on aggregated groups of information. Only SQL statements that

specify the GROUP BY clause can use the HAVING clause. The predicates in the HAVING

clause are applied after the GROUP BY has been applied.

If both a WHERE clause and a HAVING clause are coded on the same SQL statement, the

following occurs:


36/246

DB2


The WHERE clause is applied to the detail rows.

The GROUP BY is applied to aggregate the data.

The HAVING clause is applied to the aggregate rows.

Consider the following SQL:

SELECT DEPTNO, AVG (SALARY) FROM EMP

WHERE DEPTNO NOT IN (D001, D002)

GROUP BY DEPTNO HAVING COUNT (*) > 1;

This query will return the average salary for each department except D001 and D002, as long

as the department has more than 1 employee. The steps DB2 take to satisfy this query are:

Apply the WHERE clause to eliminate departments D001 and D002. Apply the GROUP BY clause to aggregate the data by department.

Apply the HAVING clause to eliminate any department groups consisting of only one

employee.

Joins & Sub Queries

Cartesian Products

A Cartesian product is the result of a join that does not specify matching columns.

SELECT * FROM DEPT, EMP;

This query combines every row from the DEP table with every row in the EMP table. All the

columns of the DEP table and all the columns of the EMP table are included in the Cartesian

product.

When a table with 100 rows is joined as a Cartesian product with a table having 10 rows, the

result is 100x10 rows, 1000 rows (since no criteria were specified). Avoid Cartesian products.


37/246

DB2


Joins

The art of combining data from multiple tables is called joining. A join also called inner join

matches the data from two or more tables, based on the value of one or more columns in each

table. All matches are combined, creating a resulting row that is the concatenation of the column

from each table where the specified columns match.

Although, the maximum number of tables that can be joined in a single SQL statement is 15, the

practical limit is usually fewer.

For example, to query employees and their department names, the EMP table is joined to the

DEP table.

SELECT EMPNO, EMPNAME, DEPTNO, DEPTNAMEFROM EMP, DEPT

WHERE EMP.DEPTNO=DEPT.DEPTNO;

The above query can also be written as

SELECT EMPNO, EMPNAME, DEPTNO, DEPTNAME

FROM EMP

JOIN DEP

ON EMP.DEPTNO=DEPT.DEPTNO

SELECT EMPNO, EMPNAME, DEPTNO, DEPTNAME

FROM EMP

INNER JOIN DEP


Here, the employee table is joined to the department table using a department code that exists as

a column in both the tables (DEPTNO in the employee table and DEPTNO in the department

table)

The INNER keyword will be assumed even if not said.

Consider these two tables EMP and DEPT.


38/246

DB2


EMP

EMPNO EMPNAME DEPNO SALARY

E001 A D001 12000

E002 B D002 15000E003 C D001 11000

E004 D NULL 21000

DEPT

DEPTNO DEPNAME

D001 FINANCE

D002 ACCOUNTS

D003 SALES

i) Inner join - When two tables are brought close by inner join, those rows in which the

columns are common to both the tables are highlighted.

SELECT EMPNAME,DEPTNAME

FROM EMP

INNER JOIN DEP


EMPNAME DEPNAME

E001 FINANCE

E002 ACCOUNTS

E003 FINANCE

ii) Outer join - When tables are joined, the rows that are returned contain matching values for

the columns specified in the join predicates. Sometimes, it is desirable to return both matching

and non-matching rows for one or more of the tables being joined. This is known as an outer join.

a) Left outer join - This invokes an outer join, returning all the rows from the table on the left side

of the join and the corresponding values in the table on the right side of the join. Also, the missing

values in the result set will be filled with nulls.


39/246

DB2


SELECT EMPNAME, DEPTNAME

FROM EMP

LEFT OUTER JOIN DEP


EMPNAME DEPNAME

E001 FINANCE

E002 ACCOUNTS

E003 FINANCE

E004 NULL

b) Right outer join - An outer join, returning all the rows from the table on the right side of the

join and the corresponding values in the table on the left side of the join. Also, the missing values

in the result set will be filled with nulls.

SELECT EMPNAME,DEPTNAME

FROM EMP

RIGHT OUTER JOIN DEP


EMPNAME DEPNAME

E001 FINANCE

E002 ACCOUNTS

E003 FINANCE

NULL SALES

c) Full outer join - Like all previous outer joins, it returns matching rows from both the tables. In

addition, it returns non-matching rows from both tables, left and right. A full outer join can use

only the equal (=) operator. Left and right outer joins are able to use all the comparison operators.

SELECT EMPNAME, DEPTNAME

FROM EMP

FULL OUTER JOIN DEP



40/246

DB2


EMPNAME DEPNAME

E001 FINANCE

E002 ACCOUNTS

E003 FINANCE

NULL SALESE004 NULL

SUBQUERIES

A subquery is a SELECT statement within a condition of a SELECT statement. Other words for

subquery are subselect or innerselect.

SQL facilitates us to nest SELECT statements. When one or more SELECT statements are

nested in another SELECT statement, the query is referred to as subquery. A subquery enables a

user to base the search criteria of one SELECT statement on the results of another SELECT

statement.

One SELECT statement is connected to another in one of these ways:

Using the IN or NOT IN predicate,

Using the EXISTS or NOT EXISTS predicate,

Specifying the equality predicate (=) or the inequality predicate ()

Specifying a predicate using a comparative operator ()

The following SELECT statement is an example of a SQL subquery.

SELECT * FROM EMP

WHERE SALARY > (SELECT SALARY FROM EMP WHERE EMPNO = E001);

DB2 evaluates this SQL statement by first evaluating the nested SELECT statement to retrieve

the salary of employee with an employeenumber E001. It then matches the rows in the EMP

table that have salaries more than E001s salary retrieved by the nested SELECT.

The following example shows an alternate way of nesting SELECT statements, by means of an

equality predicate.

SELECT EMPNO, EMPNAME FROM EMP

WHERE DEPTNO = (SELECT DEPTNO FROM DEPT WHERE DEPTNAME = FINANCE);


41/246

DB2


DB2 processes this SQL statement by retrieving the proper DEPTNO with the nested SELECT

statement that is coded to search for the FINANCE department. It then matches rows in the EMP

table that correspond to the DEPTNO of the FINANCE department. This match produces a result

table that lists all employees in the FINANCE department.

Ofcourse, it also assumes that there is only one PLANNING department. If there were more, the

SQL statement would fail because the nested SELECT statement can return only one row when

the = predicate is used.

Another method of subquery, called a correlated subquery permits the nested SELECT statement

to refer back to the columns in the previous SELECT statement.

SELECT A.DEPTNO, A.EMPNO, A.SALARY FROM EMP A

WHERE A.SALARY > (SELECT AVG (B.SALARY) FROM EMP B WHERE A.DEPTNO= B.DEPTNO);

This subquery differs from a normal subquery in the way that the nested SELECT statement

refers back to the table in the first SELECT statement.

In the nested SELECT statement, in the condition part, we employ A.WORKDEP through which

we are referring the table in the first SELECT EMP A.

A non-correlated subquery is processed in bottom-to-top fashion. The bottom most query isinitiated first and based on the results, the top most query is resolved.

A correlated subqueryworks in a top-bottom-top fashion. The topmost query is analyzed, and

based on the analysis the bottommost query is triggered. The bottom most query, however relies

on the topmost query to evaluate.

Joins Vs Subqueries

Lets look at a subquery here.

SELECT EMPNO, EMPNAME FROM EMP

WHERE DEPTNO = (SELECT DEPTNO FROM DEPT WHERE DEPTNAME =

FINANCE);


42/246

DB2


Now, we replace the same query above by a join.

SELECT EMPNO, EMPNAME

FROM EMP JOIN DEPT

WHERE EMP.DEPTNO = DEPT.DEPTNO AND DEPT.DEPTNAME = FINANCE;

Though the system doesnt have any problem dealing with join or subquery, from the users point

of view, it is easy to understand joins rather than subqueries.

Union

The Union operation combines two sets of rows into a single set composed of all the rows ineither or both of the two original sets. The two original sets must be union-compatible.

For union compatibility:

The two sets must contain the same number of columns.

Each column of the first set must be either the same data type as the corresponding column

of the second set or convertible to the same data type as the corresponding column of the

second set.

In this form, the union of two sets doesnt have any duplicates at all.

SELECT EMPNO FROM EMP A WHERE EMPNAME = DRAVID UNION

SELECT EMPNO FROM EMP A WHERE DEPTNO = D001;

While using the UNION operation in the same table, we can also use OR. The advantage of

using OR is that the users can understand easily. Also, OR tends to outperform UNION.

The above query is rewritten using OR.

SELECT EMPNO FROM EMP A

WHERE EMPNAME = DRAVID OR DEPTNO = D001;


43/246

DB2


View

Is like a window through which data and tables can be viewed or changed.

Derived from another table or another view which stores data physically

Stored as a SELECT statement only-it is a virtual table that does not physically exist in its

own right, but appears to the user as if it does.

A view has no data it manipulates data in the underlying base table

Allows the same data to be seen by different users in different views.

A view cannot contain an order by clause - orderby is specified when select clause is given.

Syntax

CREATE VIEW EMP1

AS

SELECT EMPNO,EMPNAME

FROM EMP;

Example

Create a view from the tables DEPT and EMP, which would store the department name,

minimum salary, maximum salary and average salary for every department.

Solution

CREATE VIEW DEPT_SUMMARY

(NAME,MINSAL,MAXSAL,AVGSAL)

AS

SELECT DEPTNAME, MIN(SAL), MAX(SAL).AVG(SAL)

FROM EMP,DEPT

WHERE EMP.DEPTNO = DEPT.DEPTNO

GROUP BY DEPT.DEPTNO;

Modifying a View

In order to modify a view you simply drop and re-create it. You cannot alter a view.

Removing a View

DROP VIEW EMP_VIEW2


44/246


45/246

DB2


Press F6 will fetch you the QMF Query panel. Type in a query. To run this query, press F2. A

report is prepared. Printing this report can be accomplished by F4. Formatting the report is done

by F9. When you say F9, the report form appears. A default form is generated for each query

when it is run.

The third QMF object, the QMF Proc, is another important feature of QMF.

A QMF query can contain only one SQL statement. This is contrast to that of SPUFI, which can

contain multiple SQL statements.

To execute multiple SQL statements at one time, you use a QMF Proc. QMF Procs contains QMF

commands that are tied together and executed serially.

Using QMF is a quick way to produce high-quality professional reports.

A QMF session goes as follows:

Enter QMF and the QMF Home Panel appears.

Press F6 to display the QMF Query panel. Code the SQL SELECT statement.

Press F2 to display the QMF Report panel. Execute the SQL statement to produce the report.

Press F9 to display the QMF Form panel. Modify the report parameters and headings as

needed.

Press F12 to display the QMF Report panel. Print the final formatted report.


46/246

DB2


Chapter 5 : DB2 Interfaces

DCLGEN

DCLGEN, the declarations generator supplied with DB2, produces a DECLARE statement for the

use in an Embedded SQL applications program to produce a Cobol copy book which contains

SQL DECLARE TABLE statement along with the WORKING-STORAGE host-variable definitions

for each column of the table. When the DCLGEN command is issued DB2 reads the catalog to

determine the structure of the table and builds the COBOL copybook.

The source table name and the dataset name for the copybook has to be entered during

DCLGEN, invoked from the DB2I panel.

Issued for a single table. Prepares the structure of the table in a COBOL copybook

The copybook contains a SQL DECLARE TABLE statement along with a working storage

host variable definition for the table

Note: DCLGEN can be used only on an existing table or view table.

The DCLGEN must be used and the DCLGEN name of the table or view must be supplied before

the program is precompiled. In order to use the declarations generated by DCLGEN in the

program, the SQL INCLUDE statement is used. The example below shows this INCLUDE

statement for the CAND DCLGEN

EXEC SQL INCLUDE CAND;

DB2 must be active before DCLGEN can be used. It can be started in different ways:

From ISPF through DB2I: Select the DCLGEN option on the DB2I Primary Option Menu panel.Next, fill in the DCLGEN panel with the information it needs to built the declarations, press

ENTER.

INCLUDE: The INCLUDE statement is used to generate the DCLGEN in the application program

at the run time.


47/246

DB2


Chapter 6 : DB2 Application Development Overview

DB2 Program Preparation Steps

Issue the DCLGEN command

DCLGEN - to invoke the declarations generator program.

Issue the DCLGEN command for a single table. On a table-by-table basis, DCLGEN produces a

module that can be included in DB2 application programs. It reads the DB2 catalog to determine

the structure of the table and builds a copybook for the host language. The copybook contains a

SQL DECLARE TABLE statement along with WORKING-STORAGE host variable definitions foreach column in the table.

DCLGEN is not a required step because the DECLARE TABLE statement and corresponding

host variables could be hard coded in the application program. Skipping this step is not

recommended. Run the DCLGEN command for every table that will be embedded in a COBOL

program. Then every program that accesses that table should be required to INCLUDE the

generated copybook as the only means of declaring that table for embedded use.

For the EMPTABL copybook, use the following include statement:

EXEC SQL

INCLUDE EMPTABL

END-EXEC.

DB2 must be running to invoke the DCLGEN command. A sample DCLGEN for the DEP table is

as follows:

DCLGEN TABLE (EMP)

LIBRARY (XXX.DB2.CNTL (DCLEMP))

ACTION (REPLACE)

QUOTE

EXEC SQL DECLARE EMP TABLE

(EMPNO CHAR (4) NOT NULL,


48/246

DB2


EMPNAME CHAR (10) NOT NULL,

DEPTNO CHAR (4),

SALARY DECIMAL(7,2) NOT NULL)

END-EXEC.

*** COBOL DECLARATION FOR TABLE EMP ***

01 DCLEMP.

10 EMPNO PIC X(4).

10 EMPNAME PIC X(10).

10 DEPTNO PIC X (4).

10 SALARY PIC S9(5)V99 COMP-3.

The DCLGEN process gives the conversion of DB2 datatypes into equivalent COBOL datatypes

as follows:

DB2 COBOL

SMALLINT 01 N1 PIC S9(4) COMP

INTEGER (or) INT 01 N1 PIC S9(9) COMP

DECIMAL(5,2) (or) DEC(5,2) 01 N1 PIC S9(3) V 9(2) COMP-3

FLOAT(21) (or) REAL 01 N1 COMP-1

FLOAT (or) FLOAT (53) (or) DOUBLE

PRECISION01 N1 COMP-2

CHAR(10) 01 N1 PIC X(10)

VARCHAR (80)

01 STR1

02 STR1-LEN PIC S9(4) COMP.

02 STR1-TXT PIC X(80).

GRAPHIC(5)01 N1 PIC G(5)

DISPLAY-1

VARGRAPHIC(40)

01 STR2

02 STR2L PIC S9(4) COMP.

02 STR2C PIC G(40) DISPLAY-1.

DB2 COBOL

DATE 01 N1 PIC X(10)

TIME 01 N1 PIC X(8)

TIMESTAMP 01 N1 PIC X(26)


49/246

DB2


As shown above, the DCLGEN command produces a DECLARE TABLE statement and a

COBOL field layout for DB2 host variables that can be used with the table. The output from

DCLGEN is stored as a member of a partitioned dataset from which it can be copied into an

application program by means of an embedded SQL INCLUDE statement.

Pre-compilation

The precompiler prepares the source program for compilation by replacing EXEC SQL by a

CALL and by putting the SQL in comment. The precompiler performs the following:

Includes DCLGEN member

Includes SQLCA

Looks for SQL statements and for host variable definitions

Verifies the SQL syntax

Matches each column and table name in the SQL to the DECLARE TABLE statements.

Prepares the SQL for compilation or assembly in the host language

Produces a DBRM and stores it in a PDS

Can be invoked in DB2I or in batch.

So urce P rogram

M odified Source

N on-SQL

Link E dit

Compilation

Load M odule

D B2 Precompiler

or H ost-Language

Compiler

DBRM

BindD B2 C atalog

Plan

SQ L

Package / P lan


50/246

DB2


DBRM

A Data Base Request Module is nothing more than a module containing SQL statements

extracted from a source program by the DB2 precompiler. It is stored as a member of a

partitioned data set. It is not stored in the DB2 Catalog or DB2 Directory. Although a DB2 Catalog

table named SYSIBM. SYSDBRM exists, it does not contain the DBRM. It also does not contain

every DBRM created by the precompiler.

When a DBRM is bound into a plan, all its SQL statements are placed into the

SYSIBM.SYSSTMT DB2 catalog table. When a DBRM is bound into a package, all its SQL

statements are placed into the SYSIBM.SYSPACKSTMT table.

Binding

The bind process establishes a relationship between an application program and its relational

data. This step is necessary before a program can be executed. DB2 allows two basic ways of

binding a program: to a package, or directly to an application plan.

The bind process performs the following

Checks SQL syntax

Checks security (validity & authorization)

Compares column/table names against DB2 catalog

Builds access path strategy for each SQL statement.

Issue the BIND command

The DBRM goes through a process by name BIND to produce an executable plan or package.

The BIND command is a type of compiler for SQL statements. In general, BIND reads SQL

statements from DBRMs and produces a mechanism to access data as directed by the SQL

statements being bound.

Two types of binds: BIND PLAN and BIND PACKAGE.


51/246

DB2


What Is a Plan?

A planis an executable module containing the access path logic produced by the DB2 optimizer.

It can be composed of one or more DBRMs and packages.

BIND PLAN (PLAN1)

MEMBER (PROGRAM1, PROGRAM2, PROGRAM3)

LIBRARY (MTRGIT.DBRMLIB)

QUALIFIER (TRG001)

OWNER (TRG001)

Plans are created by the BIND command. When a plan is bound, DB2 reads the f DB2 catalog

tables:

SYSIBM.SYSCOLDIST

The DB2 catalog stores only information about the plans.

What Is a Package?

A package is a single, bound DBRM with optimized access paths, by using packages, the table

logic is packaged at a lower level of granularity, at the package (or program) level.

To execute a package, you first must include it in the package list of a plan. Packages are not

directly executed they are only indirectly executed when the plan in which they are contained

executes (as discussed previously, UDFs and triggers are exceptions to this rule). A plan can

consist of one or more DBRMs, one or more packages, or a combination of packages and

DBRMs.

To help differentiate between plans and packages, consider a grocery store analogy. Before

going to the grocery store, you should prepare a shopping list. As you go through the aisles,when you find an item on your list, you place the item in your shopping cart. After your paying for

the items at the check-out register, the clerk places your grocery items in a bag. You can think of

the purchased items as DBRMs. The bag is the plan. You have multiple DBRMs (grocery items)

in your plan (Shopping bag).


52/246

DB2


Name of the package is same as the name of the DBRM.

BIND PACKAGE (COLLECTION1)

To execute a package, you must first include it in the package list of a plan. Packages are never

directly executed they are only indirectly executed when the plan in which they are contained

executes.

A plan can consist of one or more DBRMs, one or more packages, or a combination of packages

and DBRMs.

The plan contains a list pointing to the physical location of the packages and one or more

DBRMs.

Package information is stored in its own DB2 catalog tables. When a package is bound, DB2reads the DB2 catalog tables:

Information about the package is then stored in the DB2 catalog tables:

The DB2 catalog stores only information about the packages.

A package contains a location identifier, a collection identifier and a package identifier.

The location identifier specifies the site at which the package was bound. The collection identifierrepresents a logical grouping of packages. The package identifier is the DBRM name bound into

the package. This ties the package to the program to which it applies.

A Package also contains a location identifier, a collection identifier, and a package identifier. The

location identifier specifies the site at which the package was bound. If your processing is local,

you can forgo the specification of the location ID for packages.

LOCATION.COLLECTION.PACKAGE

One final consideration when using packages is versioning. A package can have multiple

versions, each with its own version identifier. The version identifier is carried as text in the DBRM,

and is covered in more depth in the Package version Maintenance section.


53/246

DB2


Package Benefits:

Reduced bind time is the package benefit most often cited. When you are utilizing packages and

the SQL within a program changes, only the package for that particular program needs to be

rebound. If packages are not used when multiple DBRMs are bound into a plan and the SQL

within one of those programs changes, the entire plan must be rebound. This wastes time

because you must still rebind all the other DBRMs in that plan that did not change.

Another benefit of packages involves the granularity of bind parameters. With packages, you can

specify your bind options at the program level because many of the bind parameters are now

available to BIND PACKAGE command, such as the ISOLATION level and RELEASE

parameters. By specifying different parameters for specific packages and including these

packages in a plan, many combinations of isolation level and release are possible. You can, forexample, create a single plan that provides an isolation level of cursor stability (CS) for one of its

packages and an isolation level of repeatable read (RR) for another package. This combination of

strategies is not possible in a plan-only environment.

The third benefit, versioning, probably is the biggest benefit of all. Packages can be

versioned, thus enabling you to have multiple versions of the same package existing at the same

time in the DB2 Catalog. Simply by running the appropriate lad module, DB2 chooses the correct

package to execute. DB2 uses a package selection algorithm to execute the correct access path.

Packages also provide improved support for mirror tables. Because a package has a high level

qualifier of collection, you can specify a collection for each of your mirror table environments.

Suppose that you have an environment in which you have current and history data in separate

tables. Using only plans, the following two options were available:

You could write a program that specifically selected the appropriate high-level

qualifier for each appropriate table, such as CURRENT or HISTORY, and hard-code that

qualifier into your program.

You could BIND the programs DBRM into different plans, specifying a different owner for

each.


54/246

DB2


Every time a DBRM with a different version identifier is bound to a package, a new version is

created. This can cause many unused package versions to be retained. When packages are

freed, you must specify the location, collection, package and version of package you want to free.

FREE PACKAGE (MYCOLLN1.MYPACK1.TEST)

(MYCOLLN1.MYPACK1)

(MYCOLLN1. *)

Note: DB2 is not accessed during this process.

DB2 programs must be parsed and modified before normal compilation. The DB2 precompiler

performs this task. When invoked, the precompiler performs the following functions:

Searches for and expands DB2 related INCLUDE members.

Searches for SQL statements 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 database request module

(DBRM). DBRM is a member of a partitioned dataset.

Places a timestamp token in the modified source and the DBRM to ensure that these two

items are inextricably tied.

Reports on the success or failure of the precompile process.

The consistency token is passed to the load module from the modified source code during

the compiling and linking process.

The precompiler searches for SQL statements embedded in EXEC SQL and END-EXEC

keywords. For this reason, every SQL statement, table declaration, or host variable in an

INCLUDE copybook must be in an EXEC SQL block.

The timestamp token or consistency token is a DB2 internal timestamp unless we specify. If we

use the LEVEL keyword in the precompile JCL, the consistency token becomes the value we

specify. Hence, we can control the changes in the consistency token using LEVEL keyword.


55/246

DB2


What Is a Collection?

A collection is a user-defined name from 1 to 128 characters that the programmer must specify

for every package. A collection is not an actual, physical database object. You can compare

collections to databases. A DB2 database is not actually a physical object (ignoring, for the

moment, the DBD). In much the same way that a database is a grouping of DB2 objects, a

collection is grouping of DB2 packages.

But how do you access these packages? Assume that both packages were generated from a

DBRM named SAMPPROG. This would give you packages named ORIG. SAMPRPROG and

CLONE. SAMPPROG. You can bind both these packages into a plan called SAMPPLAN, for

example, as in the following:

BIND PLAN (SAMPPLAN)

PKLIST (ORIG.SAMPPROG, CLONE.SAMPPROG)

BIND PLAN accepts as input one or more DBRMs produced from previous DB2 program

precompilations, one or more packages produced from previous BIND PACKAGE commands, or

a combination of DBRMs and package lists.

The output of the BIND PLAN command is an application plan containing executable logic

representing optimized access paths to DB2 data. An application plan is executable only with a

corresponding load module. Before you can run a DB2 program, regardless of environment, an

application plan name must be specified.

The BIND PACKAGE command accepts as input a DBRM and produces a single package

containing optimized access path logic. Then, we can bind packages into an application plan

using the BIND PLAN command. A package is not executable and cannot be specified when a

DB2 program is being run. It is a must that all the packages must be bound into a plan before

using it.

BIND performs many functions to create packages and plans that access the requested DB2

data, include the following:

Reads the SQL statements in the DBRM and checks the syntax of those statements and

reports on any errors.

Converts high-level database requests into optimized internal forms.


56/246

DB2


Checks that the DB2 tables and columns being accessed conform to the corresponding DB2

catalog information.

Performs authorization validation (this is optional, though)

Optimizes the SQL statements into efficient access paths.

The consistency token is copied from the DBRM to the plan or package.

The application packages and plans contain the access path specifications developed by the

BIND command. The BIND command invokes the DB2 optimizer to determine efficient access

paths based on DB2 catalog statistics (such as the availability of indexes, the organization of

data, and the table size) and other related information (such as number of processors, processor

speed and bufferpool specifications). The BIND command is performed in the relational data

services component of DB2.

A package can be bound for only a single DBRM. A package, hence, is the optimized SQL from asingle program. Although packages are discrete entities in the DB2 catalog and directory, they

cannot be executed until they are bound into a plan. Plans are either composed of one or more

DBRMs or one or more packages.

Compile the program

The modified COBOL source data set produced by the DB2 compiler must then be compiled.

Link the program

The compiled source is then link edited to an executable load module. The appropriate DB2 host

language interface module also must be included by the link edit step. This interface module is

based on the environment (TSO, CICS, etc.) in which the program will execute.

The output of the link edit step is an executable load module, which then can be run with a plan

containing the pr

mainframe vol-ii version 1.2

Documents