DB2 Handout v1.0

Handout: DB2 Version: DB2/Handout/0308/1.0

Date: 20-03-08

Cognizant

500 Glen Pointe Center West

Teaneck, NJ 07666

Ph: 201-801-0233

www.cognizant.com

http://www.cognizant.com/

Handout: DB2

TABLE OF CONTENTS

Introduction ................................................................................................................................. 11

About this Module ....................................................................................................................... 11

Target Audience ......................................................................................................................... 11

Module Objectives ...................................................................................................................... 11

Pre-requisite ............................................................................................................................... 11

Session 02: Introduction to DB2 Objects ................................................................................... 12

Learning Objectives .................................................................................................................... 12

Database .................................................................................................................................... 12

DBMS ......................................................................................................................................... 12

Database Model .......................................................................................................................... 12

RDBMS ....................................................................................................................................... 13

DB2 ............................................................................................................................................. 13

Storage Group ............................................................................................................................ 13

Database in detail ....................................................................................................................... 14

Table Space ................................................................................................................................ 14

Index Space ................................................................................................................................ 15

Table ........................................................................................................................................... 15

Column ....................................................................................................................................... 15

Row ............................................................................................................................................. 15

Table Terminology ...................................................................................................................... 16

Types of Table ............................................................................................................................ 16

Index ........................................................................................................................................... 16

View ............................................................................................................................................ 17

Synonym ..................................................................................................................................... 19

Alias ............................................................................................................................................ 19

Physical Storage of Data ............................................................................................................ 20

Hierarchy of DB2 Objects ........................................................................................................... 20

Buffer Pool .................................................................................................................................. 21

Summary .................................................................................................................................... 21

Test Your Understanding ............................................................................................................ 22

Session 03: Database Design ..................................................................................................... 23


Why Should You Be Concerned with Database Design? .......................................................... 23

Page 2 ©Copyright 2007, Cognizant Technology Solutions, All Rights Reserved

C3: Protected

Handout: DB2

Activities involved in Database Design ....................................................................................... 23

Logical Database Design ............................................................................................................ 24

Physical database design ........................................................................................................... 36

Implementing and Altering Database Design ............................................................................. 37

Advantage of DB2 over VSAM ................................................................................................... 37

Summary .................................................................................................................................... 38


Exercises .................................................................................................................................... 39

Session 07: Data Integrity............................................................................................................ 40


Introduction to Data Integrity ...................................................................................................... 40

Entity Integrity ............................................................................................................................. 40

Referential Integrity .................................................................................................................... 41

Rules ensuring RI: ...................................................................................................................... 41

Domain Integrity .......................................................................................................................... 42

Summary .................................................................................................................................... 45


Session 08: Interaction with DB2 ................................................................................................ 47


Interaction with DB2: Overview .................................................................................................. 47

DB2I ............................................................................................................................................ 48

SPUFI ......................................................................................................................................... 49

QMF ............................................................................................................................................ 53

Summary .................................................................................................................................... 58


Session 09: SQL ........................................................................................................................... 60


SQL: Overview ............................................................................................................................ 60

DDL ............................................................................................................................................. 61

DDL – Create Storage Group ..................................................................................................... 61

DDL – Alter Storage Group ........................................................................................................ 61

Try It Out ..................................................................................................................................... 62

DDL – Create Database ............................................................................................................. 62

Try It Out ..................................................................................................................................... 63

DDL – Alter Database ................................................................................................................. 63

DDL – Create Tablespace .......................................................................................................... 63


C3: Protected

Handout: DB2

Try It Out ..................................................................................................................................... 66

DDL – Alter Tablespace ............................................................................................................. 67

Summary .................................................................................................................................... 68


Session 10: SQL ........................................................................................................................... 69


DDL – Create Table .................................................................................................................... 69

Try It Out ..................................................................................................................................... 71

Try It Out ..................................................................................................................................... 72

Try It Out ..................................................................................................................................... 73

DDL – Alter Table ....................................................................................................................... 73

Try It Out ..................................................................................................................................... 74

DDL – Create Index .................................................................................................................... 74

DDL – Alter Index ....................................................................................................................... 78

Try It Out ..................................................................................................................................... 79

DDL – Create View ..................................................................................................................... 80

DDL – Alter View ........................................................................................................................ 80

DDL – Create Alias ..................................................................................................................... 80

DDL – Create Synonym .............................................................................................................. 80

DDL – DROP .............................................................................................................................. 81

Summary .................................................................................................................................... 81


Exercises .................................................................................................................................... 82

Session 11: SQL ........................................................................................................................... 83


DML – Insert ............................................................................................................................... 83

DML – Update ............................................................................................................................. 84

DML – Delete .............................................................................................................................. 84

DML – Simple Retrieval .............................................................................................................. 85

DML – Retrieving Multiple Columns ........................................................................................... 85

DML – Retrieving All Columns .................................................................................................... 85

DML – Sorting Retrieved data .................................................................................................... 85

DML – Sorting by Multiple Columns ........................................................................................... 86

DML – Sorting by Column Position............................................................................................. 86

DML – Specifying Sort Direction ................................................................................................. 86

DML – Filtering Data ................................................................................................................... 86

DML – WHERE Clause Operators ............................................................................................. 87


C3: Protected

Handout: DB2

DML – Advanced Filtering .......................................................................................................... 88

DML – Wildcard Filtering ............................................................................................................ 89

DML – Removing Duplicates ...................................................................................................... 90

DML – Concatenating Fields ...................................................................................................... 90

DML – Using Aliases .................................................................................................................. 90

DML – Performing Mathematical Calculations ........................................................................... 91

DML – Functions......................................................................................................................... 91

DML – Aggregate Functions ....................................................................................................... 91

DML – Text Functions ................................................................................................................ 92

DML – Date and Time Manipulation Functions .......................................................................... 92

DML – Numeric Functions .......................................................................................................... 93

Summary .................................................................................................................................... 93


Exercises .................................................................................................................................... 94

Session 12: SQL ........................................................................................................................... 96


DML – Grouping Data ................................................................................................................. 96

DML – Filtering Groups .............................................................................................................. 97

DML – Grouping and Sorting ...................................................................................................... 97

DML – Subquery ......................................................................................................................... 97

DML – Join ................................................................................................................................100

DML – Union .............................................................................................................................102

DCL ...........................................................................................................................................103

DCL - GRANT ...........................................................................................................................103

DCL - REVOKE ........................................................................................................................103

Summary ..................................................................................................................................104

Test Your Understanding ..........................................................................................................104

Exercises ..................................................................................................................................104

Session 21: Introduction to Simple COBOL DB2 Application Program ...............................106

Learning Objectives ..................................................................................................................106

Embedded SQL ........................................................................................................................106

DCLGEN ...................................................................................................................................106

Host Variables ..........................................................................................................................111

SQLCA ......................................................................................................................................112

SQLCODE ................................................................................................................................113

Try It Out ...................................................................................................................................113

Summary ..................................................................................................................................115


C3: Protected

Handout: DB2


Exercises ..................................................................................................................................115

Session 26: Program Preparation and Execution ...................................................................116


Steps involved in Program Preparation ....................................................................................116

Need for Precompilation ...........................................................................................................116

Tasks of Precompiler ................................................................................................................116

Bind ...........................................................................................................................................118

Plan ...........................................................................................................................................119

Need of Package ......................................................................................................................119

Package ....................................................................................................................................120

Understanding Plan and Package more clearly .......................................................................120

Version ......................................................................................................................................120

Advantage of Version ...............................................................................................................120

Advantages of Package ............................................................................................................120

Collection ..................................................................................................................................121

Advantages of Collection ..........................................................................................................121

Packages and Plans Storage ...................................................................................................125

Compile .....................................................................................................................................125

Link Edit ....................................................................................................................................126

Execution ..................................................................................................................................127

Try It Out ...................................................................................................................................128

Summary ..................................................................................................................................131


Exercises ..................................................................................................................................132

Session 31: Error Handling .......................................................................................................133


Error Handling - Introduction ....................................................................................................133

SQLCA ......................................................................................................................................133

DSNTIAR ..................................................................................................................................134

WHENEVER .............................................................................................................................135

Try It Out ...................................................................................................................................136

Summary ..................................................................................................................................139


Exercises ..................................................................................................................................139

Session 33: Commit and Rollback ............................................................................................140


C3: Protected

Handout: DB2


COMMIT ...................................................................................................................................140

Rollback ....................................................................................................................................141

Try It Out ...................................................................................................................................141

Summary ..................................................................................................................................144


Session 35: Cursor .....................................................................................................................145


Cursor - Introduction .................................................................................................................145

Cursor Processing ....................................................................................................................145

Cursor Declaration ....................................................................................................................146

Cursor Open .............................................................................................................................146

Cursor Fetch .............................................................................................................................146

Cursor Close .............................................................................................................................147

Using Cursor for Data Modification ...........................................................................................147

Try It Out ...................................................................................................................................148

Summary ..................................................................................................................................151


Exercises ..................................................................................................................................151

Session 42: Handling Null .........................................................................................................152


Null - Introduction......................................................................................................................152

Null Indicator .............................................................................................................................152

Try It Out ...................................................................................................................................153

Summary ..................................................................................................................................161


Exercises ..................................................................................................................................161

Session 46: Handling VARCHAR ..............................................................................................162


VARCHAR - Introduction ..........................................................................................................162

VARCHAR - Behavior ...............................................................................................................162

Try It Out ...................................................................................................................................163

Summary ..................................................................................................................................171


Exercises ..................................................................................................................................171


C3: Protected

Handout: DB2

Session 51: Locks ......................................................................................................................172


Lock - Introduction ....................................................................................................................172

Table Space - Recap ................................................................................................................172

Simple Table Space .................................................................................................................172

Segmented Table Space ..........................................................................................................173

Partitioned Table Space ...........................................................................................................173

Lock Size ..................................................................................................................................173

Lock Escalation .........................................................................................................................174

Lock Duration ............................................................................................................................174

Summary ..................................................................................................................................175


Session 52: Locks ......................................................................................................................177


Lock Mode ................................................................................................................................177

Suspension ...............................................................................................................................179

Timeout .....................................................................................................................................179

Deadlock ...................................................................................................................................179

Constructs that affect locking ...................................................................................................180

Summary ..................................................................................................................................181


Session 54: Miscellaneous ........................................................................................................182


Bind Parameters .......................................................................................................................182

Common SQL Errors ................................................................................................................183

Application Programming Guidelines .......................................................................................184

Using EXPLAIN ........................................................................................................................184

Summary ..................................................................................................................................185




Table-Based Infrastructure of DB2 ...........................................................................................186

DB2 Catalog .............................................................................................................................186

DB2 Directory ...........................................................................................................................190

Summary ..................................................................................................................................190



C3: Protected

Handout: DB2



Utilities - Introduction ................................................................................................................191

Data Consistency Utilities .........................................................................................................191

CHECK Utility ...........................................................................................................................191

REPAIR Utility ...........................................................................................................................192

REPORT Utility .........................................................................................................................195

DIAGNOSE Utility .....................................................................................................................195

Backup and Recovery Utilities ..................................................................................................196

COPY Utility ..............................................................................................................................196

MERGECOPY Utility ................................................................................................................197

QUIESCE Utility ........................................................................................................................198

RECOVER Utility ......................................................................................................................199

REBUILD Utility ........................................................................................................................200

REPORT RECOVERY Utility ....................................................................................................201

Summary ..................................................................................................................................201




Data Organization Utilities ........................................................................................................202

LOAD Utility ..............................................................................................................................202

REORG Utility ...........................................................................................................................203

Catalog Manipulation Utilities ...................................................................................................204

CATMAINT Utility ......................................................................................................................204

MODIFY Utility ..........................................................................................................................204

RUNSTATS Utility .....................................................................................................................204

STOSPACE Utility ....................................................................................................................205

DB2 Commands .......................................................................................................................206

Summary ..................................................................................................................................209




Dynamic SQL - Introduction .....................................................................................................210

Dynamic SQL - Types ..............................................................................................................210

When to use Dynamic SQL ......................................................................................................210

Execute Immediate SQL ...........................................................................................................210

Non-select dynamic SQL ..........................................................................................................212


C3: Protected

Handout: DB2

Parameter marker .....................................................................................................................213

Fixed-list select .........................................................................................................................213

Varying-list select SQL .............................................................................................................214

Summary ..................................................................................................................................214




Stored Procedure - Introduction ...............................................................................................215

Stored Procedure - Development .............................................................................................215

Creating Stored Procedures .....................................................................................................216

Managing Stored Procedures ...................................................................................................217

Executing a Stored Procedures ................................................................................................217

Summary ..................................................................................................................................218


Glossary ......................................................................................................................................219

References ..................................................................................................................................227

Websites ...................................................................................................................................227

Books ........................................................................................................................................227

STUDENT NOTES: ......................................................................................................................228


C3: Protected

Handout: DB2

Introduction

About this Module

This module deals with the fundamentals of DB2.

Target Audience

This module is specifically aimed at entry level trainees.

Module Objectives

After completing this module, you will be able to: Explain the introduction to DB2 Objects Explain Database Design Describe Data Integrity Identify the Interaction with DB2 Describe SQL Explain the introduction of simple COBOL DB2 application program Identify Error Handling Explain Commit and Rollback Explain Cursor Handle NULL Handle VARCHAR Define Locks State Application Programming Guidelines

Pre-requisite

To follow the course successfully, a trainee needs to have a prior theoretical as well as hands-on knowledge of the following:

TSO/ISPF COBOL JCL VSAM


C3: Protected

Handout: DB2

Session 02: Introduction to DB2 Objects

Learning Objectives

After completing the session, you will be able to: Identify the different DB2 objects Explain the relation between DB2 objects Describe how the data is being stored in DB2 physically

Database

A database is a collection of data stored in some organized fashion. The simplest way to think of it is to imagine a database as a filing cabinet. The filing cabinet is simply a physical location to store data, regardless of what that data is or how it is organized. You will see about Database in detail in the later part of this session.

Database: A container (usually a file or set of files) to store organized data.

DBMS

A Database Management System (DBMS) is a set of programs designed for the purpose of managing databases. Typical examples of DBMS include:

DB2 Oracle Microsoft Access Microsoft SQL Server

Database Model

A database model refers to the way a DBMS organizes information internally. It is a theory or specification, describing how a database is structured and used. Common models include the following:

Hierarchical model Network model Relational model Object model


C3: Protected

Handout: DB2

RDBMS

Relational Database Management System (RDBMS) is a type of database management system (DBMS) that stores data in the form of related tables. Most popular RDBMS includes:

DB2 Oracle Microsoft SQL Server

DB2

DB2 or Database 2 is a Relational Database Management System offered by IBM that runs on IBM Mainframe, AS/400 and on PC. A DB2 database can grow from a small single-user application to a large multi-user system.

Storage Group

A DB2 storage group (STOGROUP) is a set of volumes on direct access storage devices (DASD). The volumes hold the VSAM data sets in which tables and indexes are actually stored. Max no of volumes per Storage group is 133 (Ideally 3 or 4). All volumes of a given storage group must have the same device type (3380, 3390, and so no.). But, parts of a single database can be stored in different storage groups. If the volumes in a storage group are different types or if any volume is not mounted or is otherwise invalid, then an error will occur when you try to create a table space or index. Try to assign frequently accessed objects (indexes, for instance) to fast devices and seldom-used tables to slower devices; that choice of storage groups improves performance. After you define a storage group, DB2 stores information about it in the DB2 catalog. (This catalog is not the same as the integrated catalog facility catalog that describes DB2 VSAM data sets). The catalog table SYSIBM.SYSSTOGROUP has a row for each storage group and SYSIBM.SYSVOLUMES has a row for each volume. At installation, the system default storage group is defined. This storage group is named SYSDEFLT. If you do not explicitly manage your storage, then DB2 uses the default storage group to allocate space.


C3: Protected

Handout: DB2

Following figure represents the physical representation of storage group.

Database in detail

A database is a collection of related data tables or entities. For example, a typical database for an organization would consist of a customer, an order, and order details tables. All these tables are related to one another in some way. In this example, customers have orders and orders have order details. Even though each table exists on its own, collectively the tables comprise a database. Database is a group of logically related Tablespaces and Indexspaces, which in turn contain tables and indexes respectively. The default database, DSNDB04, is predefined in the DB2 installation process.

Table Space

Data is actually stored in a structure known as a table space. Each table space correlates to one or more individual physical VSAM data sets in the DASD volumes of storage Group. Each table space contains one or more tables. There are three different types of table space:

Simple table space Segmented table space Partitioned table space

You will talk about table space in detail while dealing with “Locks”.


C3: Protected

Handout: DB2

Index Space

An index space is the underlying storage structure for index data. Each index space correlates to one or more individual physical VSAM data sets in the DASD volumes of storage Group. It is automatically created by DB2 whenever an index is created. There can only be one index in an index space.

Table

Tables are logical structures maintained by the database manager. When you store information in your filing cabinet you do not just toss it in a drawer. Rather, you create files within the filing cabinet, and then you file related data in specific files. In the database world, that file is called a table. A table is a structured file that can store data of a specific type. A table might contain a list of customers, a product catalog, or any other list of information. Each table has a name, and within a table, each column has a name. No particular ordering is maintained among the rows of a table, but rows can be retrieved in an order determined by values in their columns. The data in a table is logically related. All table data is assigned to table spaces. A table consists of data logically arranged in columns and rows.

Column

Tables are made up of columns. A column contains a particular piece of information within a table. Column is a single field in a table. All tables are made up of one or more columns. The best way to comprehend this is to envision database tables as grids, somewhat like spreadsheets. Each column in the grid contains a particular piece of information. In a customer table, for example, one column contains the customer number, another contains the customer name, and the address, city, state, and zip are all stored in their own columns.

Row

Data in a table is stored in rows. Row is a record in a table. Again, envisioning a table as a spreadsheet style grid, the vertical columns in the grid

are the table columns, and the horizontal rows are the table rows.


C3: Protected

http://publib.boulder.ibm.com/infocenter/db2luw/v8/topic/com.ibm.db2.udb.concepts.doc/concepts/about_tablespaces.htm#about_tablespaces

Handout: DB2

For example, a customer table might store one customer per row. The number of rows in the table is the number of records in it.

Table Terminology

Following table will give the terminology used in table context:

In this Document Formal Terms Many Database Manuals

Table Relation Table

Column Attribute Field

Row Tuple Record

Types of Table

Base Table: A base table is created with the CREATE TABLE statement and is used to hold persistent user data. Result Table: A result table is a set of rows that the database manager selects or generates from one or more base tables to satisfy a query. Summary Table: A summary table is a table defined by a query that is also used to determine the data in the table. Summary tables can be used to improve the performance of queries. If the database manager determines that a portion of a query can be resolved using a summary table, the database manager can rewrite the query to use the summary table. Temporary Table: A declared temporary table is created with a DECLARE GLOBAL TEMPORARY TABLE statement and is used to hold temporary data on behalf of a single application. This table is dropped implicitly when the application disconnects from the database

Index

An index is a data access aid that can be created on a table. It is an ordered set of pointers to rows in a table. Each index is based on the values of data in one or more columns in a table. An index is an object that is separate from the data in the table. When you create an index, the database manager builds the structure and maintains it automatically.


C3: Protected

http://publib.boulder.ibm.com/infocenter/db2luw/v8/topic/com.ibm.db2.udb.concepts.doc/concepts/about_tables.htm#about_tables

http://publib.boulder.ibm.com/infocenter/db2luw/v8/topic/com.ibm.db2.udb.concepts.doc/concepts/about_dbm.htm#about_dbm

Handout: DB2

An index can serve the following purposes: Improve performance. In most cases, access to data is faster with an index. Provides

a fast way to find rows in a table based on their values in the key columns. Enforces uniqueness rules by defining a column or group of columns as a unique

index or primary key. Provides a logical ordering of the rows of a table based on the key column values. Clusters the rows of a table in physical storage according to the order of the defined

index.

View

A view provides a different way of looking at the data in one or more tables. View is a virtual table consisting of a SQL SELECT statement that accesses data from one or more tables or views. A view never stores data. When you access a view, the SQL statement that defines it is executed to derive the requested data. A view has columns and rows just like a base table. All views can be used just like base tables for data retrieval. You can use views to control access to sensitive data, because views allow multiple users to see different presentations of the same data. For example, several users may be accessing a table of data about employees. A manager sees data about her employees but not employees in another department. A recruitment officer sees the hire dates of all employees, but not their salaries; a financial officer sees the salaries, but not the hire dates. Each of these users work with a view derived from the base table. Each view appears to be a table and has its own name. When the column of a view is directly derived from the column of a base table, that view column inherits any constraints that apply to the base table column. For example, if a view includes a foreign key of its base table, insert and update operations using that view are subject to the same referential constraints as is the base table. Also, if the base table of a view is a parent table, delete and update operations using that view are subject to the same rules as are delete and update operations on the base table. A view can become inoperative (for example, if the base table is dropped); if this occurs, the view is no longer available for SQL operations. The best way to recognize views is to look at an example. (You will study about the SQLs in detail further. This example is just to make you understand the concept of views). You have following three tables:

Customers

Orders

OrderDetails


C3: Protected

Handout: DB2

You need to retrieve the customers who had ordered a specific product. The column details are as follows.

Table Column

Customers

cust_id

cust_name

cust_contact

Orders order_num

cust_id

OrderDetails order_num

prod_id

The query is as follows: SELECT cust_name, cust_contact

FROM Customers, Orders, OrderDetails

WHERE Customers.cust_id = Orders.cust_id

AND OrderDetails.order_num = Orders.order_num

AND prod_id = 'RGAN01';

Anyone needing this data would have to understand the table structure, as well as how to create the query and join the tables. To retrieve the same data for another product (or for multiple products), the last WHERE clause would have to be modified. Now imagine that you could wrap that entire query in a virtual table called ProductCustomers. You could then simply do the following to retrieve the same data: SELECT cust_name, cust_contact

FROM ProductCustomers

WHERE prod_id = 'RGAN01';

This is where views come into play. ProductCustomers is a view, and as a view, it does not contain any columns or data. Instead it contains a query—the same query used above to join the tables properly. Why Use Views: Here are some common uses of views:

To draw data from multiple tables. To reuse SQL statements. To simplify complex SQL operations. After the query is written, it can be reused easily,

without having to know the details of the underlying query itself. To expose parts of a table instead of complete tables. To secure data. Users can be given access to specific subsets of tables instead of to

entire tables.


C3: Protected

Handout: DB2

To change data formatting and representation. Views can return data formatted and presented differently from their underlying tables.

For the most part, after views are created, they can be used in the same way as tables. You can perform SELECT operations, filter and sort data, join views to other views or tables, and possibly even add and update data. There are some restrictions on this last item. The important thing to remember is views are just that, views into data stored elsewhere. Views contain no data themselves, so the data they return is retrieved from other tables. When data is added or changed in those tables, the views will return that changed data. There are some performance issues with views because views contain no data, any retrieval needed to execute a query and that must be processed every time the view is used. If you create complex views with multiple joins and filters, or if you nest views, you may find that performance is dramatically degraded. Be sure you test execution before deploying applications that use views extensively.

Synonym

1. An alternative, private name for a table or view. 2. A synonym can be used only by the individual who creates it.

When a table or view is dropped, all synonyms defined on it are also dropped

Alias

1. A locally defined name for a table or view in the same local DB2 subsystem or in a remote DB2 subsystem. Aliases give DB2 location independence because an alias can be created for a table at a remote site, thereby freeing the user from specifying the site that contains the data. Aliases can be used also as a type of global synonym because they can be accessed by anyone, not only by their creator.

2. When a table/view is dropped, all aliases defined on it are NOT dropped 3. Use Synonyms for Program Development, use Aliases for Distributed Applications and

use Views for security and joining. Following table gives the difference between “Synonym” and “Alias”

Synonym Alias

An alternative name for a table or view which should reside in the local DB2 subsystem

An alternative name for a table or view which can reside in the local or remote DB2 subsystem

Can be used only by its creator Can be used by anyone including its creator

Is dropped when it’s corresponding Table/View is dropped

Not dropped even when it’s corresponding Table/View is dropped


C3: Protected

Handout: DB2

Physical Storage of Data

The following figure represents how the data is physically stored in DB2 system.

Hierarchy of DB2 Objects

Following figure represents the hierarchy of DB2 objects:


C3: Protected

Handout: DB2

Buffer Pool

Buffer pools are areas of virtual storage in which DB2 temporarily stores pages of table spaces or indexes. Buffer pools improve database performance. If a needed page of data is already in the buffer pool, that page is accessed faster than if that page had to be read directly from disk. The database manager has agents whose tasks are to retrieve data pages from disk and place them in the buffer pool (pre-fetchers), and to write modified data pages from the buffer pool back to disk (page cleaners). The reading and writing of data pages to and from disk is called disk input/output (I/O). Avoiding the wait associated with disk I/O is the primary way to improve the performance of the database. How you create the buffer pool, and configure the database manager and the agents associated with the buffer pool, controls the performance of the database. In DB2, you have the option of allocating 80 Buffer Pools:

50 4K buffer pools and 10 8K, 16K and 32K buffer pools.

The default buffer pool is BP0.

Summary

Storage Group is a set of volumes on DASD which contains VSAM datasets. Database is a collection of related data elements. Table space represents one or more tables which correlate to one or more VSAM data

sets in the DASD volumes of storage Group. Index Space represents an index correlates to one or more VSAM data sets in the

DASD volumes of storage Group. Table consists of data logically arranged in columns and rows. Index is an ordered set of pointers to rows in a base table. View is a virtual table that accesses data from one or more tables or views. Synonym is an alternative name for a table or view which should reside in the local

DB2 subsystem. Alias is an alternative name for a table or view, which can reside in the local or remote

DB2 subsystem. Buffer Pools are areas of virtual storage in which DB2 temporarily stores pages of

table spaces or indexes.


C3: Protected

Handout: DB2

Test Your Understanding

1. What is a storage group? 2. What is a database? 3. What is a table space? 4. What is an index space? 5. What is a table? 6. What is an index? 7. What is a View? 8. What is the difference between Synonym and Alias? 9. State the logical and physical objects among the DB2 objects and their hierarchy. 10. How the data is being stored physically? 11. What is a buffer pool?


C3: Protected

Handout: DB2

Session 03: Database Design

Learning Objectives

After completing the session, you will be able to: Design a DB2 database

Why Should You Be Concerned with Database Design?

You will look at the concept of database design with the real life example. Say your database is like a custom home and that you are going to have one built for us. What is the first thing you are going to do? Certainly you are not going to hire a contractor immediately and let him build our home however he wishes. Surely you will first engage an architect to design your new home and then hire a contractor to build it. The architect will express your needs as a set of blueprints, recording decisions about size and shape, and requirements for various systems (structural, mechanical, electrical). Next the contractor will procure the labor and materials, including the listed systems, and then assemble them according to the drawings and specifications. Now let’s return to your database perspective and think of the logical database design as the architectural blueprints and the physical database implementation as the completed home. The logical database design describes the size, shape, and necessary systems for a database; it addresses the informational needs and operational needs of your business. You then build the physical implementation of the logical database design, using your RDBMS software program. Once you have created your tables, set up table relationships, and established the appropriate levels of data integrity, our database is complete. Now you are ready to create an application that allows interacting easily with the data stored in the database and you can be confident that these applications will provide with timely and above all, accurate information. It is possible to implement a poor design in an RDBMS, but a well designed database will yield accurate information, store data more efficiently and effectively, and will be easier to manage and maintain. If a database is designed improperly, users will have difficulty in retrieving certain types of information, and there is the added risk that searches will produce inaccurate information. Inaccurate information is probably the most detrimental result of improper database design. It can adversely affect the bottom line of a business. In fact, if the data kept and used in a database is going to affect the way a business performs its day-to-day operations or if it's going to influence the future direction of the business, database design must be a concern.

Activities involved in Database Design

Designing the database involves: Logical Database Design Physical Database Design


C3: Protected

Handout: DB2

Implementing and Altering Database Design

Logical Database Design

Logical database design involves three phases: Requirements analysis phase Data modeling phase Normalization phase

Requirements Analysis Phase The requirements analysis phase involves examining the business being modeled, interviewing users and management to assess the current system and to analyze future needs, and determining information requirements for the business as a whole. This process is relatively straightforward. Data Modeling Phase The data modeling phase involves modeling the database structure itself. This involves using a data modeling method which provides a means of visually representing various aspects of the database structure, such as the tables, table relationships, and relationship characteristics. Some of the common data modeling methods are:

Entity Relationship modeling (ER modeling) Semantic object modeling Object role modeling

The method which you use here is a basic version of ER modeling.

ER Modeling

A simple ER Diagram looks as follows.

This figure represents several aspects of the database. First, it conveys the fact that there are two tables in this database, one called Agents and the other called Clients; each of the tables is represented by a rectangle. The diamond represents the fact that there is a relationship between these two tables, and the "1:N" within the diamond indicates that the relationship is a one-to-many relationship. Finally, the diagram conveys the fact that a client must be associated with an agent (indicated by the vertical line next to the AGENTS table), but an agent does not necessarily have to be associated with a client (as indicated by the circle next to the CLIENTS table). An entity-relationship (ER) diagram is a specialized graphic that illustrates the interrelationships between entities in a database of a Logical data modeling.


C3: Protected

Handout: DB2

Symbols used in ER Diagram: Box represents Entity Diamond represents Relationship Oval represents Attribute

Key Activities in ER Modeling: Following are the key activities involved in designing Logical database using Entity-Relationship Mode:

Define Entities Define Primary Key Define Relationships among Entities Define Additional Attributes for the Entities

Define Entities:

You begin the ER Model, by defining the entities, the significant objects of interest Entities are the things about which you want to store information.

Define Primary Key:

A primary key is a unique identifier for an Entity. If a primary key is made up of more than one attribute, then it is called as “Composite

Key”.

Define Relationships among Entities A connection established between a pair of tables is known as a relationship. A relationship exists when a pair of tables is connected by a Primary key and a foreign key or is linked together by a third table, known as a linking table. Relationships are very important because they help to reduce redundant data and duplicate data. They also provide the means to define views. Every relationship can be characterized by the type of relationship that exists between the tables, the type of participation each table has within the relationship, and the degree of participation each table has within the relationship. Types of Relationships (Cardinality): When two tables are related, there is always a specific type of relationship (traditionally known as cardinality) that exists between them. There are three possible types of relationships:

one-to-one one-to-many and many-to-one relationships many-to-many


C3: Protected

Handout: DB2

One-to-One Relationships: A one-to-one relationship exists between a pair of tables if a single record in the first table is related to only one record in the second table and a single record in the second table is related to only one record in the first table. Following figure shows an example of a one-to-one relationship involving an EMPLOYEES table and a COMPENSATION table. In this example, a single record in the EMPLOYEES table is related to only one record in the COMPENSATION table; likewise, a single record in the COMPENSATION table is related to only one record in the EMPLOYEES table.

One-to-Many Relationships: A one-to-many relationship exists between a pair of tables if a single record in the first table can be related to one or more records in the second table, but a single record in the second table can be related to only one record in the first table. A one-to-many relationship involving a STUDENTS table and an INSTRUMENTS table is shown in the following figure. In this case, a single record in the STUDENTS table can be related to one or more records in the INSTRUMENTS table, but a single record in the INSTRUMENTS table is related to only one record in the STUDENTS table.


C3: Protected

Handout: DB2

Many-to-One Relationships A many-to-one relationship exists between a pair of tables if a single record in the first table can be related to only one record in the second table, but a single record in the second table can be related to one or many records in the first table. A many-to-one relationship involving an EMPLOYEE table and a DEPARTMENT table is shown in the following figure. In this example, a single record in the EMPLOYEE table can be related to only one record in the DEPARTMENT table and a single record in the DEPARTMENT table can be related to one or more records in the EMPLOYEE table. Following figure represents many-to-one relationship. Here a relationship is established between two tables with the help of a linking table.


C3: Protected

Handout: DB2

Many-to-Many Relationships: A many-to-many relationship exists between a pair of tables if a single record in the first table can be related to one or more records in the second table, and a single record in the second table can be related to one or more records in the first table. Following figure shows a classic many-to-many relationship. In this example, a single record in the STUDENTS table can be related to one or more records in the CLASSES table; likewise, a single record in the CLASSES table can be related to one or more records in the STUDENTS table. Following figure represents many-to-many relationship. Here a relationship is established between two tables with the help of a linking table.

Types of Participation (Optionality): There are two types of participation that a table can have within a relationship:

Mandatory Optional

Say there is a relationship between two tables called TABLE A and TABLE B. If records in TABLE A must exist before any new records can be entered into TABLE B, TABLE A's participation within the relationship is mandatory. However, if it is not necessary for records in TABLE A to exist in order to enter any new records into TABLE B, TABLE A's participation within the relationship is optional. Each table within a relationship can participate in either manner. The type of participation each table has within a relationship is typically determined by the way the data in each table is related and how the data is being used.


C3: Protected

Handout: DB2

Consider the relationship between the AGENTS and CLIENTS tables in the following figure. The AGENTS table has a mandatory participation within the relationship if agents must exist before a new client can be entered into the CLIENTS table. But the AGENTS table's participation is optional if it isn't necessary to have agents in the AGENTS table before a new client can be entered into the CLIENTS table. The type of participation established for the AGENTS table is determined by the way its data is being used in relation to the data in the CLIENTS table. For example, if it is necessary to ensure that each client is assigned an available agent, then the participation of the AGENTS table within the relationship should be mandatory.

Representation of Cardinality and Optionality: In general the following conventions are being used for representing cardinality and optionality, Cardinality:

The notion of cardinality is expressed as either "one" or "many" A cardinality of “one” is expressed as a “straight line” and a cardinality of “many” is

expressed using “crow's feet”.

Optionality: The notion of optionality is expressed as either "mandatory" or "optional" An optionality of “Optional” is expressed as a “circle” and an optionality of “Mandatory”

is expressed as a “vertical bar”. Sample ER Diagram: Consider the example of a database that contains information on the residents of the cities. The ER Diagram contains two Entities – Person and City. Optionality: A person should live in a city. (That is why a bar appears adjacent to City from Person). A City can exist without a person. (That is why a circle appears adjacent to Person in the “City – Person Relationship”).


C3: Protected

Handout: DB2

Define Additional Attributes for the Entities: Defining the attributes for an entity includes the following activities.

Defining attribute name. Defining Data Type for the attributes. Defining appropriate values for the attributes - what values are acceptable for the

various attributes of a table. Normalization: Normalization is a design approach that minimizes data redundancy and optimizes data structures by systematically and properly placing data elements into the appropriate groupings. Normalization is the process of efficiently organizing data in a database and is the process of decomposing large tables into smaller tables. Goals of Normalization: There are two goals of the normalization process:

Eliminating redundant data (for example, storing the same data in more than one table)

Ensuring data dependencies make sense (only storing related data in a table). Both of these are worthy goals as they reduce the amount of space a database consumes and ensure that data is logically stored and avoid problems with inserting, updating, or deleting data. Normal Form: A series of guidelines were developed by the database community for ensuring that the databases are normalized. Those guidelines are represented by different normal forms. Types of Normal forms are as follows:

First Normal Form or 1NF Second normal Form or 2NF Third Normal Form or 3NF Fourth Normal Form or 4NF Fifth Normal Form or 5NF


C3: Protected

http://databases.about.com/library/glossary/bldef-table.htm

Handout: DB2

In practical applications, in general, you use only 1NF, 2NF, and 3NF.

First Normal Form: All entities must have a unique identifier or key, that can be composed of one or more

attributes. Eliminate repeating groups and non-atomic data from an entity.

The term atomic derives from atom, the smallest indivisible particle that can exist on its own. First normal form eliminates repeating groups and non-atomic data from an entity. To normalize a data model into 1NF, eliminate repeating groups into individual entities. In other words, do not use multiple attributes in a single entity to store similar data. Consider the sample data shown in table for a STUDENT information system for a college or university. This data contains several violations of 1NF. First, you are tracking courses that really represent a repeating group for STUDENTs. So, the course information should be moved into separate entities. Furthermore, you need to specify identifiers for both entities. The identifier is the primary key for the entity. A second violation of 1NF is the non-atomic data shown in the StudentName attribute. A student name can be broken down into pieces: first name, middle initial and last name. It is not indivisible, and therefore violates first normal form.

Unnormalized STUDENT Data

StudentID StudentName MajorID StudentMajor CourseNum CourseName CourseCompDate

2907 Smith, Jacob R

MAT Mathematics MAT0011 Discrete Math 8/1/2002

MAT0027 Calculus I 4/30/2002

EGL0010 English Classics I

12/30/2001

4019 Patterson, Jane K

PHI Philosophy PHI0010 CS00100

Intro to Philosophy

Programming Languages

2002-04-30 2002-04-30

5145 Neeld, Norris B

EGL English Literature

SOC0102 Ascent of Man

8/1/2002

6132 Morrison, Xavier Q

MUS Music MUS0002 SOC0102

Origin of Jazz Ascent of

Man

2002-04-30 2002-08-01

7810 Brown, Richard E

CS Computer Science

8966 Juarez, Samantha


EGL0010 EGL0101

English Classics I

Shakespeare II

2001-12-30 2002-08-01


C3: Protected

Handout: DB2

STUDENT Entity in 1NF

StudentID LastName FirstName MiddleInit MajorID StudentMajor

2907 Smith Jacob R MAT Mathematics

4019 Patterson Jane K PHI Philosophy

5145 Neeld Norris B EGL English Literature

6132 Morrison Xavier Q MUS Music

7810 Brown Richard E CS Computer Science

8966 Juarez Samantha EGL English Literature

COURSE Entity in 1NF

StudentID CourseNum CourseName CourseCompDate

2907 MAT0011 Discrete Math 8/1/2002

2907 MAT0027 Calculus I 4/30/2002

2907 EGL0010 English Classics I 12/30/2001

4019 PHI0010 Intro to Philosophy 4/30/2002

4019 CS00100 Programming Languages 4/30/2002

5145 SOC0102 Ascent of Man 8/1/2002

6132 MUS0002 Origin of Jazz 4/30/2002

6132 SOC0102 Ascent of Man 8/1/2002

8966 EGL0010 English Classics I 12/30/2001

8966 EGL0101 Shakespeare II 8/1/2002

Second Normal Form: Should be in First Normal Form Every non-key attribute is fully dependent on the key

Second normal form (2NF) ensures that all the attributes of each entity are dependent on the primary key. Notice that certain courses repeat in the COURSE entity, namely "English Classics I" and "Ascent of Man." This situation indicates a violation of 2NF. To correct the problem, we need to identify the attributes that do not depend on the entire key and remove them. The removed attributes, along with the portion of the primary key on which they depend, are placed in a new entity, ENROLLMENT. The entire primary key of the original entity remains with the original entity. Another benefit of the normalization process is that you will frequently encounter new attributes that need to be specified for the new entities that are created. For example, perhaps the new COURSE entity causes us to remember that each course is assigned a number of credits that count toward graduation. No changes were required for the STUDENT entity:


C3: Protected

Handout: DB2

ENROLLMENT Entity in 2NF

StudentID CourseNum CourseCompDate

2907 MAT0011 2002-08-01

2907 MAT0027 2002-04-30

2907 EGL0010 2001-12-30

4019 PHI0010 2002-04-30

4019 CS00100 2002-04-30

5145 SOC0102 2002-08-01

6132 MUS0002 2002-04-30

6132 SOC0102 2002-08-01

8966 EGL0010 2001-12-30

8966 EGL0101 2002-08-01

COURSE Entity in 2NF

CourseNum CourseName Credits

MAT0011 Discrete Math 3

MAT0027 Calculus I 4

EGL0010 English Classics I 3

PHI0010 Intro to Philosophy 3

CS00100 Programming Languages 3

SOC0102 Ascent of Man 3

MUS0002 Origin of Jazz 3


C3: Protected

Handout: DB2

Third Normal Form: Should be in Second Normal Form Every non-key attribute is non-transitively dependent on the primary key that is, every

attribute in the entity should depend only on the key not on any other non-key attributes.

A rule of thumb for identifying 3NF violations is to look for groups of attributes whose values can apply to more than a single entity occurrence. When you discover such attributes, move them to a separate entity. It is time to review our STUDENT information again, this time looking for 3NF violations. Examine the STUDENT data in closely. Notice that students can have the same major and, as such, certain major information can be repeated, specifically two students in our small sample are English Literature majors. To correct the problem, we need to remove major attributes that transitively depend on the key and create a new entity for them.

STUDENT Entity in 3NF

StudentID LastName FirstName MiddleInit MajorID

2907 Smith Jacob R MAT

4019 Patterson Jane K PHI

5145 Neeld Norris B EGL

6132 Morrison Xavier Q MUS

7810 Brown Richard E CS

8966 Juarez Samantha EGL

MAJOR Entity in 3NF

MajorID StudentMajor

MAT Mathematics

PHI Philosophy


MUS Music

CS Computer Science

A Normalized Data Model: To be complete, a diagram should be developed for the 3NF data model we just created for the STUDENT data. Figure shows such a data model. Notice that we have not filled in the optionality of the relationships. We could do this based on the sample data we used, but we really need to ask more questions before we can answer questions such as Does a every student have to have a major? The current data shows this to be the case, but in reality; you know that most freshmen, and even upperclassmen, may attend college without having a formally declared major.


C3: Protected

Handout: DB2

The STUDENT data model

Further Normal Forms: Normalization does not stop with 3NF. Additional normal forms have been identified and documented. However, normalization past 3NF does not occur often in normal practice. The following are additional normal forms. Just for your information we’ve kept this. Boyce Codd normal form (BCNF) is a further refinement of 3NF. Indeed, in his later writings Codd refers to BCNF as 3NF. A row is in Boyce Codd normal form if and only if every determinant is a candidate key. Most entities in 3NF are already in BCNF. Fourth normal form (4NF) states that no entity can have more than a single one-to-many relationship if the one-to-many attributes are independent of each other. An entity is in 4NF if and only if it is in 3NF and has no multiple sets of multivalued dependencies. Fifth normal form (5NF) specifies that every join dependency for the entity must be a consequence of its candidate keys.


C3: Protected

Handout: DB2

Physical database design

After completing the logical design of our database, we now move to the physical design. The purpose of building a physical design of our database is to optimize performance while ensuring data integrity by avoiding unnecessary data redundancies. During physical design, you transform the entities into tables, the instances into rows, and the attributes into columns. You must decide on many factors that affect the physical design, some of which are listed as follows:

How to translate entities into physical tables What attributes to use for columns of the physical tables Which columns of the tables to define as keys What indexes to define on the tables What views to define on the tables How to denormalize the tables How to resolve many-to-many relationships

Physical design is the time when you abbreviate the names that you chose during logical design. For example, you can abbreviate the column name that identifies employees, EMPLOYEE_NUMBER, to EMPNO. The task of building the physical design is a job that truly never ends. You need to continually monitor the performance and data integrity characteristics of the database as time passes. Many factors necessitate periodic refinements to the physical design. Denormalization: Denormalization is a key step in the task of building a physical relational database design. It is the intentional duplication of columns in multiple tables, and the consequence is increased data redundancy. This is recommended to avoid performance problems occur as a result of normalization. This should be done based on the processing needs of applications accessing the data.


C3: Protected

Handout: DB2

Implementing and Altering Database Design

Implementing the database design involves: Implementing DB2 objects loading data managing data altering the design as necessary

Altering Database Design:

After using a relational database for a while, we might want to change some aspects of its design.

To alter the database design we need to change the definitions of DB2 objects.

Advantage of DB2 over VSAM

The following list will give some of the advantages of DB2 over VSAM.

Feature DB2 VSAM

Hardware Independence PC to mainframe Only Mainframe

OS Independence NT, Unix and OS/390 Only OS/390

Ease of development Standard SQL Not so simple

Stored procedure & triggers No such option

Ease of maintenance Standard SQL Difficult

Security High degrees of security Only at Dataset level

Referential Integrity DB2 enforces it Developers responsibility

Query Interface Easy to view/modify Not available

Performance Better for even large data Better when data is less

Optimizer handles Developer responsible

Performance Tuning Can be tuned anytime Depends on initial design

Can be at SQL level Only application level

Tools available for aiding No tuning aids

Abundant tuning skills Tuning skills are rare

Reorganization Direct reorganization Delete & recreate

Online reorg possible Downtime needed

Recovery Managed by DB2 Managed by CICS/IMS

Always recoverable No recovery in batch

From log / backup From backup only

Auto Recovery Manual Restore

Backup Online backup possible Downtime needed

Incremental backup No incremental backup

Disaster Recovery Supported by DB2 Part of DASD recovery

Data Archival Selective archival No Selective archival


C3: Protected

Handout: DB2


C3: Protected

Feature DB2 VSAM

Selective retrieval No Selective retrieval

Up to row level archival Dataset level archival

Data types Images, Video, Audio, and so on. Text only

Contents can be in file No such option

Summary

Database Design involves: o Logical Database Design o Physical Database Design o Implementing and Altering Database Design

Key activities for designing Logical data modeling with Entity-Relationship Model are: o Define Entities o Define Primary Key:

Unique identifier Composite Key: Key made up of more than one attributes

o Define Relationships among Entities: One-to-one relationships One-to-many and many-to-one relationships Many-to-many relationships Cardinality: Number of occurrences between the entities. Optionality: Relationships are mandatory or optional Define Additional Attributes for the Entities

Normalization: Eliminating redundant data thereby reducing the amount of space o Three Normal Forms: 1NF, 2NF, and 3NF

Physical database design is transformation of: o Entities into tables o Instances into rows o Attributes into columns o Denormalization is recommended to avoid performance problems occur as a

result of normalization Implementing the database design involves: Implementing DB2 objects, loading and

managing data and altering the design as necessary. o Altering Database Design: To alter the database design, you need to change the

definitions of DB2 objects


1. What are the tasks involved in database design? 2. What is logical data modeling? 3. What is ER Model? 4. What are all the symbols used in ER model? 5. Describe the key activities involved in designing logical data modeling using ER model? 6. What is a Primary key?

Handout: DB2

7. What are all the different types of relationship? 8. What is Cardinality and Optionality? 9. What is Normalization? 10. What are the goals and benefits of Normalization? 11. State the different types of Normal forms. 12. Describe the tasks involved in the physical database design. 13. When will you do Denormalization? 14. State the activities involved in implementing and altering database design. 15. List some of the advantages of DB2 over VSAM.

Exercises

Following figure represents the “Medical Bill” to be produced to a customer. Design a Database for the medical shop system.


C3: Protected

Handout: DB2

Session 07: Data Integrity

Learning Objectives

After completing the session, you will be able to: Identify different means of achieving data integrity across the database by DB2

Introduction to Data Integrity

Data integrity refers to the validity, consistency, and accuracy of the data in a database. It cannot be overstated that the level of accuracy of the information retrieved from the database is in direct proportion to the level of data integrity imposed within the database. Data integrity is one of the most important aspects of the database design process, and it should not be underestimated, overlooked, or even partially neglected. To make any of these mistakes would result in a high risk of undetectable errors. There are three types of data integrity and are as follows:

Entity Integrity Referential Integrity Domain Integrity

Entity Integrity

This is the “Table-level integrity” which ensures that the field that identifies each record within the table is unique and is never missing its value. Entity integrity requires the specification of a primary key (PK) for each table. Key Notes about Primary Key:

Each table can have zero or one primary key. Primary key should not be Null and if the primary key is a composite key, make sure

that each component should not be Null. Every primary key explicitly defined for a table must be associated with a

corresponding unique index. If you do not create a unique index for a primary key, then an incomplete key is

defined for the table, making the table inaccessible. Unique Constraint: A unique constraint is similar to a primary key constraint which also enforces unique values on an individual or a group of columns. Each table can have zero, one, or many unique constraints consisting of one or more columns each. The values stored in the unique column, or combination of columns, must be unique within the table. Unique constraint column should not be Null. A unique index needs to be created on the columns of the unique constraint to ensure uniqueness. The only difference between Primary Key constraint and Unique Constraint is a table can have only one primary key constraint but can have more than one unique constrains.


C3: Protected

Handout: DB2

Unique Index: In addition of creating unique index in primary key column or unique constraint column (which is mandatory), you can create as many unique indexes as we need on any other columns of the table to ensure uniqueness. The following table will show the difference between unique index on Primary Key/Unique constraint column and other column other than primary/unique constraint column.

Primary Key or unique constraint column Column other than primary/unique constraint but defined with unique index

A table can contain only one primary key constraint and multiple unique constraints

A table can contain multiple unique indexes

Cannot allow NULL values Can allow NULL values

Supports Referential Integrity Cannot support Referential Integrity

Referential Integrity

This is a “Relationship-level integrity” which ensures that the relationship between a pair of tables is sound and that there is synchronization between the two tables whenever data is entered, updated, or deleted. Referential integrity is achieved through the foreign key. Foreign Key: A foreign key (FK) is a column or combination of columns used to establish and enforce a link between the data in two tables. A link is created between two tables by adding the column or columns that hold one table's primary key values to the other table. This column becomes a foreign key in the second table. The table with the primary key is called parent table and the table with the foreign key is called dependent table (or child table). Referential integrity (RI) means each row in a dependent table must have a foreign key that is equal to a primary key in the parent table.

Rules ensuring RI:

Insert: When inserting a row with a foreign key in the dependent table, DB2 checks the values of the foreign key column against the values of the primary key column in the parent table. If there is a matching primary key column, the insert is allowed. If there is no matching primary key column, the insert will not happen. A new row can be inserted in the parent table as long as the primary key value of the new row is unique.


C3: Protected

Handout: DB2

Update: When updating foreign key values in the dependent table, DB2 checks whether there is a matching primary key in the parent table or not. If there is a matching primary key, update is allowed. If there is no matching primary key, update is not allowed. The primary key in the parent table cannot be updated if any rows in the dependent tables refer to it. Delete: Deleting a row with a foreign key in the dependent table is permitted. When deleting a row with a primary key in the parent table, DB2 takes one of the following actions as indicated while defining the table. RESTRICT: Disallows the deletion of the primary key row if any foreign keys relate to that row. CASCADE: Allows the deletion of the primary key row and also deletes the foreign key rows that relate to it. SET TO NULL: Allows the deletion of the primary key row and, instead of deleting all related foreign key rows, sets the foreign key columns to NULL.

Operation Child Table Parent Table Insert Allowed if the foreign key value

matches the value of Primary key of the parent table.

Allowed as long as the primary key value is unique.

Update Allowed if the foreign key value matches the value of Primary key of the parent table.

Allowed if there are no foreign key references in the child tables.

Delete Allowed. Depending upon the action specified during table definition.

Restrict: not allowed if there are any foreign key references

Cascade: allowed and deletes the foreign key references if any in the child tables.

SET TO NULL: allowed and a Null value will be set in the foreign key references of the child tables

Domain Integrity

This is the “Field-level integrity” which ensures that the structure of every field is sound, that the values in each field are valid, consistent, and accurate, and that fields of the same type (such as City fields) are consistently defined throughout the database.


C3: Protected

Handout: DB2

Domain integrity is enforced using: Data Type and Length Default Values NULL Values Check constraint

Data Type and Length

By specifying the data type and maximum length for each column when a table is created, the DBMS will automatically ensure that only the correct type of data with the maximum length allowed is stored in that column.

Default Values

When columns are created within tables, they can be assigned a default value that will be used when inserting or loading the data which do not provide an explicit value for that column. Each column can have only one default value. User can provide a default value for a column. If there is no user specific default value, DB2 will assign the default value based on the data type of that column. DB2 Data Types with Default Values:

Data Type COBOL PIC

COBOL USAGE

Default Description

CHAR(n) PIC X(n) DISPLAY Blanks Fixed length character (EBCDIC) data

VARCHAR(n) PIC X(n) DISPLAY Empty String Variable length character data

SMALLINT PIC S9(4) COMP OR COMP-4

0 Half word integer data

INTEGER PIC S9(9) COMP OR COMP-4

0 Full word integer data

DECIMAL(p,s) PIC S9(p)V9(s)

COMP-3 0 Packed decimal data.

p è number of decimal digits

s è number of digits to the right side of the decimal point

DATE PIC X(10) DISPLAY Current Date Date data (yyyy-mm-dd)

TIME PIC X(8) DISPLAY Current Time Time data (hh.mm.ss)

TIMESTAMP PIC X(26) DISPLAY Current timestamp

Date and Time data with microseconds

(yyyy-mm-dd-hh.mm.ss.mmmmmm)

GRAPHIC PIC G(n) DISPLAY-1 Blanks Double byte character set (DBCS) data

VARGRAPHIC PIC G(n) DISPLAY-1 Empty String Variable length DBCS data

FLOAT(n) None COMP-1 or COMP-2

0 Floating point data in single or double precision format


C3: Protected

Handout: DB2

NULL Values:

Whenever a value is missing or unknown, it is said to be Null. A null value represents neither zero (in the case of numeric data) nor blank (represented by one or more spaces in the case of textual data). Zero and blank are actual values and can be meaningful in some way under certain circumstances. For example, a zero can represent the current state of an Account Balance; a blank in a Middle Initial field can represent the fact that an employee has no middle initial in his or her name. In the following figure, a blank represents the fact that Washington, D.C., is not located in any county whatsoever.

A null value is typically used to represent an unknown value in a field. In the above figure, for example, there are null values in the County field. Shannon McLain did not know what county she lived in at the time her data was entered into the database, so no entry was made into the County field. As a result, the County field contains a null value. This value can be changed, however, once Shannon finds out what county she lives in. A null value is also used to represent a missing value in a field. If the person who entered the data for Shannon McLain failed to ask her for the name of the county she lives in, the data is considered missing since no entry was made into the County field due to operator error. Once the error is recognized, it can be easily corrected by obtaining the appropriate value from Ms. McLain.

A drawback to null values is that they cannot be evaluated by mathematical expressions or aggregate functions. If a null value is used in a mathematical expression, that expression will evaluate to Null. In figure Products, Total Value is derived from the mathematical expression "[SRP] * [Qty On Hand]." Note, however, that the value for the Total Value field is missing where the Qty On Hand value is Null, resulting in a null value for the Total Value field as well. This is


C3: Protected

Handout: DB2

logically reasonable—if the number is unknown, the value will necessarily be unknown. Also there is a serious undetected error that occurs if all the values in the Total Value field are then added together: an inaccurate total. The only way to obtain an accurate total is to provide a value for the entries in the Qty On Hand field that are currently Null. The result of an aggregate function, such as "Count()," will be Null if it is based on a field that contains null values. For example, the following figure shows the results of a summary query that counts the total number of occurrences of each category in the PRODUCTS table shown above. The value of Total Occurrences in the summary query is the result of the function expression "Count([Total Occurrences])." Notice that the summary query shows 0 occurrences of an unspecified Category, implying that each product has been assigned a category. This information is clearly inaccurate because there are two products in the PRODUCTS table that have not been assigned a category.

Check Constraint

A check constraint is a rule that specifies the values that are allowed in one or more columns of every row of a table. Check constraint enforces business rules directly into the database without requiring additional application logic. This can be defined during column definition.

Summary

Data Integrity ensures the accuracy of the data in a database. Types of Data Integrity

o Entity Integrity o Referential Integrity o Domain Integrity

Entity integrity enforces each occurrence of an entity must be uniquely identifiable and is achieved through primary key.

A table definition can be complete only when a unique index is created on its primary key.

Unique constraint also behaves similar to primary key constraint except the fact of the number of unique constraints can be more than one in a table.

Unique index column allows null values and does not support RI as against primary or unique constraint column.

Foreign key is a column in a child table which holds the value of primary key column of a parent table.

Referential integrity (RI) ensures each row in a dependent table must have a foreign key that is equal to a primary key in the parent table.

Rules to ensure Referential integrity:


C3: Protected

Handout: DB2

Operation Child Table Parent Table

Insert Allowed if the foreign key value matches the value of Primary key of the parent table.

Allowed as long as the primary key value is unique.

Update Allowed if the foreign key value matches the value of Primary key of the parent table.

Allowed if there are no foreign key references in the child tables.

Delete

Allowed.

Depending upon the action specified during table definition. Restrict: Not allowed if there are any foreign key references Cascade: Allowed and deletes the foreign key references if any in the child tables. SET TO NULL: Allowed and a Null value will be set in the foreign key references of the child tables

Domain integrity ensures the possible values of a column and is achieved through:

o Data Type and Length: o Commonly used DB2 data types: Char, Varchar, Smallint, Integer, Decimal, Date,

Time, Timestamp o Default Values:

Can be user defined or depends on the data type Used for columns with the missing values during insertion

o NULL Values: Unknown or missing value o Check constraint: Enforces business rules and allows only the predefined values


1. What is data integrity? 2. What is entity integrity and how do you achieve it? 3. Can you create a table without a primary key? 4. Can a primary key column hold a value of null? 5. State the importance of unique index in the primary key. 6. What is a unique constraint? 7. Differentiate between the primary key constraint and unique constraint. 8. State the differences between primary key index and unique index. 9. What is a foreign key? 10. What is a referential integrity? 11. List the rules applied to ensure RI while inserting, updating, and deleting the data both in

the parent table as well as in the child table. 12. What is domain integrity and how to achieve it? 13. State the different DB2 data types. 14. What is Null? 15. What is check constraint?


C3: Protected

Handout: DB2

Session 08: Interaction with DB2

Learning Objectives

After completing the session, you will be able to: Access DB2 data using DB2I, SPUFI and QMF

Interaction with DB2: Overview

An environment is connected to a DB2 subsystem by an attachment facility. Whenever there is a need of interaction with DB2, a thread will be established. A thread is a control structure used to:

Send requests to DB2 Send data from DB2 to the requestor Communicate the status of each SQL statement after it is executed

TSO as a Door to DB2: You use TSO (Time-Sharing Option) environment as a door that provides access to DB2 data. The TSO Attachment Facility provides access to DB2 resources in two ways:

Online mode, in the TSO foreground, using ISPF (Interactive System Productivity Facility) panels

Batch mode using the TSO Terminal Monitor Program - IKJEFT01 (or IKJEFT1B) Common types of TSO foreground users include:

DB2I QMF


C3: Protected

Handout: DB2

DB2I

DB2I (DB2 Interactive) is a TSO-based DB2 application. It consists of a series of ISPF panels, programs, and CLISTs enabling rapid access to DB2 services and data. DB2I increases the TSO DB2 developer's productivity.

How to access DB2I:

Log on to TSO as you normally would. The ISPF main menu appears. Choose Option 8 (DB2 - Perform DATABASE 2 Interactive Functions) in Cognizant

Mainframe. DB2I Main menu appears as shown in the following screenshot.

DB2I Primary Option Menu

Following Options are available with DB2I: o SPUFI: SQL Processor Using File Input. o DCLGEN: Declaration Generator. o PROGRAM PREPARATION: Prepares a program containing embedded SQL for

execution. o PRECOMPILE: Program containing embedded SQL is parsed to retrieve all SQL

and replace it with calls to a runtime interface to DB2 o BIND/REBIND/FREE: Provides the capability to bind a DB2 plan & package,

rebound a plan & package, remove plan & package from the system o RUN: enables to run a DB2 application program o DB2 COMMANDS: Enables to submit DB2 commands using TSO.


C3: Protected

Handout: DB2

o UTILITIES: Provides panels that ease the administrative burdens of DB2 utility processing

o DB2I DEFAULTS: Lets you modify parameters that control the operation of DB2I Be sure that the proper DB2 subsystem is specified in the “DB2 Name” parameter Be sure that the proper language to be used for preparing DB2 programs in the “Application Language” parameter A valid job card needs to be supplied in the “DB2I Job Statement” parameter.

o EXIT: Leaves DB2I

SPUFI

The first option in the DB2I main menu is SPUFI (SQL Processor Using File Input). SPUFI is intended primarily for application programmers who wish to test the SQL portions of their programs or administrators who wish to perform SQL operations. SPUFI reads SQL statements contained as text in a sequential file or in a member of a PDS, processes those statements and places the results in an ISPF browse session. By specifying the input and output data sets and selecting the appropriate options, we can execute SQL statements in an online mode. The SPUFI Panel is as follows.

Input Dataset

Output Dataset

Other Options


C3: Protected

Handout: DB2

You need to enter Input data set name and Output data set name

Input Data Set

Input dataset must be allocated before invoking SPUFI. This can be a member of Partitioned Data Set or a Sequential Data Set. This can be empty and can be edited as part of the SPUFI session. It is recommended to maintain a partitioned data set to keep track of SQL statements used. Input dataset can be defined as a fixed, blocked data set with an LRECL of 80. SQL statements can be written in all but the last 8 bytes of each input record; this area is reserved for sequence numbers. This can contain multiple SQL statements, as long as they are separated by semicolons. Comments are preceded by two hyphens. If the input file contains multiple SQL statements, SPUFI will stop execution of those statements as soon as it encounters an error in any one of them. Sample SQL statements in the input data set as follows: --DELETE FROM THYD001.TEST

--WHERE TEST_NO = 'A114';

--

SELECT * FROM THYD001.TEST;

--

Output Data Set

The output data set need not be allocated before using SPUFI. If the output data set does not exist, SPUFI creates a virtual, blocked sequential data set with an LRECL of 4092. The output file will contain a sequence of results, one for each statement (including the relevant SQLCODE), followed by a summary of the overall execution (including, in particular, an indication as to which of Commit and Roll Back occurred). There are some specific defaults to be set for Output data set.


C3: Protected

Handout: DB2

When the SQL is executed and browsed, an output data set like the following appears:

Query

Query Result

Information about the Query Result


C3: Protected

Handout: DB2

Other Options:

After entering Input data set name and Output data set name, we need to specify following options.

CHANGE DEFAULTS: When Y is specified, the SPUFI defaults panel appears as follows:

Isolation Level

Options of “CURRENT SPUFI DEFAULTS”:

o Typically, defaults are changed only once—the first time someone uses SPUFI. ISPF saves the defaults entered from session to session.

o Be sure to specify the following defaults: Isolation Level: Always set this option to CS (Cursor Stability). (Note: You will study about Isolation Level in detail in your forthcoming sessions.) Max Select Lines: Set to an appropriate number. If we will be selecting from large tables that return more than 250 rows, the installation default value of 250 is insufficient. SPUFI stops returning rows after reaching the specified limit, and it issues a message indicating so.

o All the remaining installation defaults are appropriate. So keep them as they are. o EXECUTE: When Y is specified, the SQL in the input file is read and executed.


C3: Protected

Handout: DB2

o AUTOCOMMIT: When Y is specified, a COMMIT is issued automatically after the successful execution of the SQL in the input file. When you specify N, SPUFI prompts you about whether a COMMIT should be issued. If the COMMIT is not issued, all changes are rolled back. Note: You will study about commit and rollback in our forthcoming sessions.

o BROWSE OUTPUT: When Y is specified, SPUFI places you in an ISPF browse session for the output data set. You can view the results of the SQL that was executed.

Note: Specifying Y for all these options (from 6 to 9) except Change Defaults (5) is common.

QMF

QMF (Query Management Facility) is an interactive query tool used to produce formatted query output. It is similar to SPUFI but has much more advanced features to produce formatted output. In Cognizant mainframe, choose the option “TS.QMF” in the ISPF main menu; you will get the QMF Home Panel as follows:

Options

Command Line

Notice the numbered options in the bottom portion of the screen. These numbers correspond to QMF functions:


C3: Protected

Handout: DB2

There are three basic QMF objects to produce formatted reports of DB2 data: Queries Forms Procs

Queries

You will see how to produce a simple report: Press F6 to navigate to the QMF Query panel, which is initially blank. Type the following statement at the COMMAND prompt and press Enter

DRAW <Table Name> Following panel will appear:

Query

Options


C3: Protected

Handout: DB2

To run this query, press F2 which will produce this report.

Query Result as Report

You can save a query by typing the following in the Command prompt SAVE AS <Query Name>

Press F4 to print the report. You can format this report using Forms by pressing F9.


C3: Protected

Handout: DB2

Forms

Forms are used to format the report of the query output. Press F9 to go to a Form. A default form is generated for each query when it is run. QMF Forms enable us to perform the following:

o Code a different column heading o Specify control breaks o Code control-break heading and footing text o Specify edit codes to transform column data (for example, suppress leading

zeroes or display a currency symbol) o Compute averages, percentages, standard deviations, and totals for specific

columns o Display summary results across a row, suppressing the supporting detail rows o Omit columns in the query from the report

QMF Form Panel is as follows:

Form Panel


C3: Protected

Handout: DB2

Procs

A QMF query can contain only one SQL statement in contrast with SPUFI, which can contain multiple SQL statements as long as they are separated by a semicolon.

QMF Proc is used to execute multiple SQL statements at one time. QMF Procs contain QMF commands that are tied together and executed serially. By pressing F10, you can enter into PROC and can execute the queries as follows:

Proc Panel


C3: Protected

Handout: DB2

Following is a typical QMF user's session. If you type a single SQL statement and press a few function keys, then an end-user report is generated.

Summary

An environment is connected to DB2 by an attachment facility by establishing a thread.

TSO interacts with DB2 through: o Online mode o Batch mode

The most common online mode includes: o DB2I o QMF

DB2I (DB2 Interactive) is a TSO-based DB2 application, which increases the TSO DB2 developer's productivity.


C3: Protected

Handout: DB2

DB2I helps application programmers and administrators to: o Run queries (SPUFI) o Generate declare code (DCLGEN) o Prepare programs (precompile, bind, rebind, free, run) o Issue DB2 commands o Prepare DB2 utilities for execution

SPUFI supports the online execution of SQL statements from TSO terminal. o By specifying an input and output data set and selecting the appropriate options,

you can execute SQL statements in an online mode. QMF (Query Management Facility) is an interactive query tool used to produce

formatted query output. o QMF objects to produce formatted reports of DB2 data are:

Queries to execute a query to produce report Forms to format the query output (report) Procs to execute multiple queries to perform series of actions


1. What is an attachment facility? 2. What is a thread? 3. How does TSO interact with DB2? 4. List the common TSO Online modes through which DB2 interaction happens. 5. What is DB2I? 6. List the different options in DB2I. 7. What is SPUFI? 8. Explain the different options in SPUFI. 9. What is QMF? 10. Explain the important functionalities available in QMF.


C3: Protected

Handout: DB2

Session 09: SQL

Learning Objectives

After completing this session, you will be able to: Create the following objects:

o Storage Group o Database o Table space

SQL: Overview

SQL (Structured Query Language) is a language designed specifically for communicating with databases and is a powerful tool for manipulating data. It is the standard query language for relational database management systems (RDBMS). It is a database-independent language that allows you to query data and to perform CRUD (Create, Update, and Delete) operations. SQL is easy to learn. The statements are all made up of descriptive English words. SQL consists of three sublanguages as follows:

DDL: Data Definition Language DML: Data Manipulation Language DCL: Data Control Language


C3: Protected

Handout: DB2

DDL

DDL (Data Definition Language) creates and maintains physical data structures using the following statements.

Create: Creating the objects. Alter: Changing the characteristics of the existing objects. Drop: Deleting the objects.

DDL – Create Storage Group

Following syntax is used for creating storage group: CREATE STOGROUP <storage group name>

VOLUMES (<volume-id,…>) or VOLUMES (*)

VCAT <catalog-name>

DATACLAS <dc-name>

MGMTCLAS <mc-name>

STORCLAS <sc-name>

VOLUMES: Defines the volumes of the storage group.

(*) indicates that SMS (Storage Management Subsystem) will manage the volumes to be used.

VCAT: Identifies the integrated catalog facility catalog for the SG. DATACLAS: Identifies the name of the SMS data class to associate with the SG. MGMTCLAS: Identifies the name of the SMS management class to associate with SG. STORCLAS: Identifies the name of the SMS storage class to associate with the SG.

Example: Create a storage group, DSN8G910, of volumes ABC005 and DEF008. DSNCAT is the integrated catalog facility catalog name.

CREATE STOGROUP DSN8G910

VOLUMES (ABC005,DEF008)

VCAT DSNCAT;

DDL – Alter Storage Group

Following syntax is used for altering the storage group. ALTER STOGROUP <storage group name>

ADD VOLUMES(<volume-id>) |

REMOVE VOLUMES (<volume-id>)

DATACLAS <dc-name>

MGMTCLAS <mc-name>

STORCLAS <sc-name>


C3: Protected

Handout: DB2

ADD VOLUMES: Adds volumes to the storage group. REMOVE VOLUMES: Removes volumes from the storage group.

Example: Alter storage group DSN8G910. Add volumes DSNV04 and DSNV05.

ALTER STOGROUP DSN8G910

ADD VOLUMES (DSNV04,DSNV05);

Try It Out

Problem Statement: Alter storage group DSN8G910. Remove volumes DSNV04 and DSNV05. Code: ALTER STOGROUP DSN8G910 TO REMOVE VOLUMES (DSNV04,DSNV05);

DDL – Create Database

Database creation syntax is as follows: CREATE DATABASE <database-name>

BUFFERPOOL <bp-name>

INDEXBP <bp-name>

STOGROUP <stogroup-name>

CCSID <ASCII>/<EBCDIC>/<UNICODE>

BUFFERPOOL:

o Specifies the default buffer pool name to be used for table spaces created within the database.

o If you omit the BUFFERPOOL clause, then the default BP, BP0 is used. INDEXBP:

o Specifies the default buffer pool name to be used for the indexes created within the database.

o If you omit the INDEXBP clause, the default BP, BP0 is used. STOGROUP: Specifies the storage group to be used to support DASD space

requirements for table spaces and indexes within the database. The default is SYSDEFLT.

CCSID (Coded Character Set ID) o Specifies the default encoding scheme for data stored in the database. o Encoding Schemes are ASCII, EBCDIC, UNICODE.

Example: Create a database DSN8D91P. Specify DSN8G910 as the default storage group to be used for the table spaces and indexes in the database. Specify 8KB buffer pool BP8K1 as the default buffer pool to be used for table spaces in the database, and BP2 as the default buffer pool to be used for indexes in the database. CREATE DATABASE DSN8D91P

STOGROUP DSN8G910


C3: Protected

Handout: DB2

BUFFERPOOL BP8K1

INDEXBP BP2;

Try It Out

Problem Statement: Create a database DSN8TEMP. Use the defaults for the default storage group and default buffer pool names. Specify ASCII as the default encoding scheme for data stored in the database. Code: CREATE DATABASE DSN8TEMP CCSID ASCII;

DDL – Alter Database

Database alteration syntax is as follows. ALTER DATABASE <database-name>


INDEXBP <bp-name>


CCSID <ASCII/EBCDIC/UNICODE>

Example: Change the default buffer pool for both table spaces and indexes within database ABCDE to BP2. ALTER DATABASE ABCDE

BUFFERPOOL BP2

INDEXBP BP2;

DDL – Create Tablespace

Table space creation syntax is as follows: CREATE TABLESPACE <tablespace-name>

IN <database-name>

<using-block>

<free-block>

DEFINE <YES/NO>

LOGGED | NOT LOGGED

TRACKMOD <YES/NO>

DSSIZE <integer>

MAXPARTITIONS <integer>

MEMBER CLUSTER

NUMPARTS <integer>

PARTITION <integer>

<using-block>

<free-block>



C3: Protected

Handout: DB2


CLOSE <YES/NO>

COMPRESS <YES/NO>

LOCKMAX <integer>

LOCKSIZE <ANY/TABLESPACE/TABLE/PAGE/ROW>

MAXROWS <integer>

SEGSIZE <integer>

<using-block>:

USING

VCAT <catalog-name>


PRIQTY <integer>

SECQTY <integer>

ERASE <YES/NO>

<free-block>:

FREEPAGE <integer>

PCTFREE <integer>

<database-name>: If you omit database-name, then the default DB, DSNDB04 is used. But it is advisable to specify the database. USING:

VCAT: Specifies that the first data set for the table space is managed by the user, and following data sets, if needed, are also managed by the user.

STOGROUP: Specifies the storage group in which the datasets for the table space will be defined and managed by DB2. o PRIQTY: Specifies the minimum primary space allocation for a DB2-managed

data set. o SEQQTY: Specifies the minimum secondary space allocation for a DB2-managed

data set. o ERASE: Indicates whether the DB2-managed data sets for the table space are to

be erased when the corresponding table space is deleted. NO: It does not erase the data sets. This is the default. YES: Erases the data sets.

FREEPAGE: o Specifies how often to leave a page of free space when the table space is loaded

or reorganized. o You must specify an integer in the range 0 to 255. o If you specify 0, no pages are left as free space. Otherwise, one free page is left

after every n pages, where n is the specified integer. PCTFREE:

o Indicates what percentage of each page to be left as free space when the table space is loaded or reorganized.

o Integer can range from 0 to 99. o The first record on each page is loaded without restriction. When additional

records are loaded, at least integer percent of free space is left on each page. DEFINE:


C3: Protected

Handout: DB2

o Specifies at which point (when) the underlying data sets for the table space are physically created.

o YES: The data sets are created when the table space is created. This is the default.

o NO: The data sets are not created until data is inserted into the table space. DEFINE NO is applicable only for DB2-managed data sets (USING STOGROUP specification). DEFINE NO is ignored for user-managed data sets (USING VCAT specification).

LOGGED: o LOGGED: Specifies that changes that are made to the data in the specified table

space are recorded in the log. o NOT LOGGED: Specifies that changes that are made to data in the specified table

space are not recorded in the log. TRACKMOD: Specifies whether DB2 tracks modified pages in the space map pages of

the table space. o YES: Tracked. This is the default. o NO: Not tracked.

DSSIZE: Specifies the maximum size for each data set. MAXPARTITIONS: Specifies the maximum number of partitions in a partitioned table

space. MEMBER CLUSTER: Specifies that data inserted by an “insert operation” is not

clustered by the clustering index. Instead, DB2 chooses where to locate the data in the table space based on available space.

Clustered and Non-Clustered Index: Indexes are organized with the B-Tree structure.

Clustered Index: o The leaf level (the lowest level of the tree) is the data. o For a table that has a clustered index, the data is actually stored in the order of the

index. Non-clustered Index:

o The leaf contains bookmarks to the actual data. o The bookmarks in non-clustered indexes are in RID format (Row ID), that is, direct

pointers to the physical location the row is stored in. NUMPARTS:

o Indicates that the table space is partitioned. o Integer is the number of partitions.

PARTITION:

o Specifies to which partition the subsequent using-block or free-block applies. o Integer can range from 1 to the number of partitions given by NUMPARTS.

BUFFERPOOL: Identifies the buffer pool to be used for the table space. CCSID: Specifies the encoding scheme for tables in the TS. CLOSE: When the limit on the number of open data sets is reached, specifies the

priority in which data sets to be closed. o YES: Eligible for closing data sets. This is the default. o NO: Eligible for closing after all CLOSE YES data sets is closed.


C3: Protected

Handout: DB2

COMPRESS: Specifies whether data compression applies to the rows of the table space. o YES: Specifies data compression. o NO: Specifies no data compression.

LOCKMAX: Specifies the maximum number of page or row locks an application process can hold simultaneously in the table space.

LOCKSIZE: Specifies the size of locks used within the table space. MAXROWS: Specifies the maximum number of rows that DB2 will consider placing on

each data page. SEGSIZE:

o Specifies that the table space will be a segmented. o Integer specifies the number of pages that are to be assigned to each segment of

the table space. Integer must be a multiple of 4 between 4 and 64 (inclusive).

Example: Create table space DSN8S91D in database DSN8D91A. Let DB2 define the data sets, using storage group DSN8G910. The primary space allocation is 52 kilobytes; the secondary, 20 kilobytes. The data sets need not be erased before they are deleted. Locking on tables in the space is to take place at the page level. Associate the table space with buffer pool BP1. The data sets can be closed when no one is using the table space. CREATE TABLESPACE DSN8S91D

IN DSN8D91A

USING STOGROUP DSN8G910

PRIQTY 52

SECQTY 20

ERASE NO

LOCKSIZE PAGE

BUFFERPOOL BP1

CLOSE YES;

Try It Out

Problem Statement: Assume that a large query database application uses a tablespace to record historical sales data for marketing statistics. Create large tablespace SALESHX in database DSN8D91A for the application. Create it with 82 partitions, specifying that the data in partitions 80 through 82 is to be compressed. Let DB2 define the data sets for all the partitions in the tablespace, using storage group DSN8G910. For each data set, the primary space allocation is 4000 kilobytes, and the secondary space allocation is 130 kilobytes. Except for the data set for partition 82, the data sets do not need to be erased before they are deleted. Locking on the table is to take place at the page level. There can only be one table in a partitioned tablespace. Associate the tablespace with buffer pool BP1. The data sets cannot be closed when no one is using the tablespace. If there are no CLOSE YES data sets to close, then DB2 might close the CLOSE NO data sets when the DSMAX is reached.


C3: Protected

Handout: DB2

Code: CREATE TABLESPACE SALESHX

IN DSN8D91A


PRIQTY 4000

SECQTY 130

ERASE NO

NUMPARTS 82

(PARTITION 80

COMPRESS YES,

PARTITION 81

COMPRESS YES,

PARTITION 82

COMPRESS YES

ERASE YES)

LOCKSIZE PAGE

BUFFERPOOL BP1

CLOSE NO;

DDL – Alter Tablespace

Table space alteration syntax is as follows: ALTER TABLESPACE [<database-name>.]<tablespace-name>

<using-block>

<free-block>

LOGGED | NOT LOGGED

TRACKMOD <YES/NO>



CLOSE <YES/NO>

COMPRESS <YES/NO>

LOCKMAX <integer>

LOCKSIZE <ANY/TABLESPACE/TABLE/PAGE/ROW>

MAXROWS <integer>

MAXPARTITIONS <integer>

<using-block>:

USING

VCAT <catalog-name>


PRIQTY <integer>

SECQTY <integer>

ERASE <YES/NO>

<free-block>:

FREEPAGE <integer>


C3: Protected

Handout: DB2

PCTFREE <integer>

Example: Alter table space DSN8S91D in database DSN8D91A. BP2 is the buffer pool associated with the table space. PAGE is the level at which locking is to take place. ALTER TABLESPACE DSN8D91A.DSN8S91D BUFFERPOOL BP2

LOCKSIZE PAGE;

Summary

SQL is the Structured Query Language, which is used for manipulating data for RDBMS.

SQL consists of three sublanguages: o DDL (Data Definition Language) o DML (Data Manipulation Language) o DCL (Data Control Language)

DDL can do the following operations: o Create o Alter o Drop

Object Operation DDL

Storage Group Creation CREATE STOGROUP

Storage Group Alteration ALTER STOGROUP

Database Creation CREATE DATABASE

Database Alteration ALTER DATABASE

Tablespace Creation CREATE TABLESPACE

Tablespace Alteration ALTER TABLESPACE


1. What is SQL? 2. List the sublanguages of SQL. 3. List the operations to be performed under DDL, DML, and DCL. 4. How do you create a storage group and explain the different options while creating? 5. What are all the changes you can make while altering a storage group? 6. How do you create a database and explain the different options while creating? 7. What are all the changes you can make while altering a database? 8. How do you create a tablespace and explain the different options while creating? 9. What are all the changes you can make while altering a tablespace?


C3: Protected

Handout: DB2

Session 10: SQL

Learning Objectives

After completing this session, you will be able to: Create the following objects:

o Table o Index o View o Alias o Synonym

DDL – Create Table

Tables can be created in two ways: By specifying the columns and their data types explicitly. Creation based on the existing table.

Following is the table creation syntax by specifying the columns and their data types explicitly: CREATE TABLE <table-name>

<column-definition>

<table-constraint-clause>

<physical-storage-clause>

<column-definition>:

<column-name> <data type>

[WITH DEFAULT expression]

[NULL|NOT NULL]

[column-constraint-clause]

[, <column-name> <data type> [WITH DEFAULT expression] [NULL|NOT NULL] [column- constraint-clause]...]

<Constraint> (column-constraint-clause or table-constraint-clause)

[CONSTRAINT <constraint-name>]

[REFERENCES <table-name> [(<column-name>)]

[ON DELETE <RESTRICT | CASCADE| SET TO NULL>]

[UNIQUE]

[PRIMARY KEY]

[CHECK (<check-condition>)]

<physical-storage-clause>

IN <database-name>.<tablespace-name>


C3: Protected

Handout: DB2

Default: o When a row is inserted into the table and no value is supplied for the column, the

value specified in the default clause is inserted. o If the expression is missed in the default clause, then the system defined default

value for the data type of the column will be substituted. NULL / NOT NULL:

o NULL is a default. o NOT NULL: Prevents the column from containing null values. Omission of NOT

NULL implies that the column can contain null values. Constraints: Constraints are defined on two possible levels.

o Column level: A column-level constraint refers to a single column and is defined together with the column. These are also referred to as “inline constraints”

o Table level : A table-level constraint references one or multiple columns and is defined separately after the definition of all the columns. These are called out-of-line constraints.

o You must use a table-level constraint if you are constraining more than one column.

Constraint-name: o Names the constraint and is optional. o If a constraint name is not specified, then a unique constraint name is generated. o If the name is specified, it must be different from the names of any referential,

check, primary key, or unique key constraints previously specified on the table. FOREIGN KEY constraint

o The FOREIGN KEY constraint is defined with the REFERENCES keyword. o The FOREIGN KEY constraint (referential integrity constraint), ensures that the

values in the foreign key correspond to values of a primary key. o When defining a FOREIGN KEY constraint on a table, the column name does not

have to be identical to the column name it references. o By default the foreign key constraint is of type DELETE RESTRICT: Parent rows

cannot be deleted if child rows exist. o ON DELETE CASCADE: Allows the deletion of the primary key row and also

deletes the foreign key rows that relate to it. o SET TO NULL: Allows the deletion of the primary key row and, instead of deleting

all related foreign key rows, sets the foreign key columns to NULL. UNIQUE constraint:

o To enforce unique values on an individual or a group of columns. o UNIQUE constraint column should not contain NULL values. o A table can contain one or more UNIQUE constraints.

PRIMARY KEY constraint: o The PRIMARY KEY ensures all values in the column/columns are unique. o The clause must not be specified more than once and the identified columns must

be defined as NOT NULL.


C3: Protected

Handout: DB2

Note: If you do not create a unique index for a primary key or for a unique constraint, then an incomplete key is defined for the table, making the table inaccessible.

Check: CHECK constraints enforce logical expressions on column/columns, which must evaluate to true for every row in the table.

Creating tables based on other tables. Following is the table creation syntax based on the exiting table: CREATE TABLE <destination-table-name>

LIKE <source-table-name>

IN <database-name>.<tablespace-name>

Try It Out

Problem Statement: Create a table TB_TAB1 in database DB_DB1 and tablespace TS_TS1 with the following specifications with the column level constraints and with the implicit constraint names.

Column Name Data Type Length Constraint Remarks

TAB1_COL1 Integer Primary Key

TAB1_COL2 Integer Not Null

TAB1_COL3 Varchar 5

foreign key to the ZIP column of the

ZIPCODE table- if a row in the ZIPCODE table is deleted, any rows with the same zip code are to be

deleted from the TAB1 table

TAB1_COL4 Date Current date should be inserted by default

TAB1_COL5 Char 20 Unique

TAB1_COL6 Integer

Should accept the values which are less than 100. Null value is

allowed.

Code: CREATE TABLE TB_TAB1

(TAB1_COL1 INTEGER NOT NULL PRIMARY KEY,

TAB1_COL2 INTEGER NOT NULL,

TAB1_COL3 VARCHAR(5) REFERENCES ZIPCODE(ZIP)

ON DELETE CASCADE,

TAB1_COL4 DATE WITH DEFAULT,

TAB1_COL5 CHAR(20) NOT NULL UNIQUE,

TAB1_COL6 INTEGER CHECK(TAB1_COL6 < 100))


C3: Protected

Handout: DB2

IN DB_DB1.TS_TS1;

How It Works:

TAB1_COL1 INTEGER NOT NULL PRIMARY KEY: When you define a column as Primary Key, it should be defined with “Not Null” (The primary key column should not contain Null values).

TAB1_COL5 CHAR (20) NOT NULL UNIQUE: When you define a column with the unique constraint, it should be defined with “Not Null” (The unique constraint column should not contain Null values).

TAB1_COL4 DATE WITH DEFAULT: During insert if you do not provide a value for this column, then the default value of “Current Date” for the “Date” variable will be inserted.

Try It Out

Problem Statement: Create a table TB_TAB1 in database DB_DB1 and tablespace TS_TS1 with the following specifications with the table level constraints by naming the constraints exclusively.

Column Name Data Type Length Constraint Remarks

TAB1_COL1 Integer Primary Key

TAB1_COL2 Integer Not Null

TAB1_COL3 Varchar 5

foreign key to the ZIP column of the ZIPCODE table- if a row in the ZIPCODE table is deleted, any rows with the same zip code are to be deleted from the TAB1 table

TAB1_COL4 Date Current date should be inserted by default

TAB1_COL5 Char 20 Unique

TAB1_COL6 Integer

Should accept the values which are less than 100. Null value is allowed.


C3: Protected

Handout: DB2

Code: CREATE TABLE TB_TAB1

(TAB1_COL1 INTEGER NOT NULL,


TAB1_COL3 VARCHAR(5),

TAB1_COL4 DATE WITH DEFAULT,

TAB1_COL5 CHAR(20) NOT NULL,


CONSTRAINT TAB1_COL1_PK PRIMARY KEY(TAB1_COL1),

CONSTRAINT TAB1_COL3_FK FOREIGN KEY(TAB1_COL3)

REFERENCES ZIPCODE(ZIP),

CONSTRAINT TAB1_COL5_COL6_UK UNIQUE(TAB1_COL5,TAB1_COL6),

CONSTRAINT TAB1_COL6_CK CHECK(TAB1_COL6 < 100))

IN DB_DB1.TS_TS1;

How It Works:

CONSTRAINT TAB1_COL5_COL6_UK UNIQUE(TAB1_COL5,TAB1_COL6): As the two columns TAB1_COL5 and TAB1_COL6 need to have unique constraints, you have combined and created this constraint and these two columns are defined with NOT NULL clause.

Try It Out

Problem Statement: Create a table TB_TAB1 in a database DB_DB1 and in a table space TS_TS1, which exactly behaves like the table TB_TAB2. Code: CREATE TABLE TB_TAB1 LIKE TB_TAB2

IN DB_DB1.TS_TS1;

DDL – Alter Table

Following is the table alteration syntax: ALTER TABLE <table-name>

[ADD <column-definition>

<table-constraint-clause>]

[ALTER COLUMN <column-alteration>]

[DROP CONSTRAINT <constraint-name>|

PRIMARY KEY|

UNIQUE (<column-name> [,<column-name>...])]

[RENAME COLUMN <source-column-name>

TO <target-column-name>]

<column-alteration>

[SET DATA TYPE (<altered-data-type>)]


C3: Protected

Handout: DB2

[SET <default-clause>]

[DROP DEFAULT]

Example: Column DEPT_NAME in table DSN8910.TB_DEPT was created as a VARCHAR(36).Increase its length to 50 bytes. Also, add the column DEPT_BLDG to the table DSN8910.TB_DEPT. Describe the new column as a character string column of length 3. ALTER TABLE DSN8910.TB_DEPT

ALTER COLUMN DEPT_NAME

SET DATA TYPE VARCHAR(50)

ADD DEPT_BLDG CHAR(3);

Try It Out

Problem Statement: Alter the TB_PRODINFO table to define a foreign key that references a non-primary unique key in the product version table (TB_PRODVER). The columns of the unique key are PRODVER_NAME and PRODVER_RELNO. Code: ALTER TABLE TB_PRODINFO

FOREIGN KEY (PRODINFO_NAME, PRODINFO_VERNO)

REFERENCES TB_PRODVER (PRODVER_NAME, PRODVER_RELNO)

ON DELETE RESTRICT;

DDL – Create Index

Following is the index creation syntax: CREATE [UNIQUE] INDEX <index-name>

ON <table-name> (<column-name> [ASC | DESC])

[CLUSTER | NOT CLUSTER]

[PARTITIONED]

[PADDED | NOT PADDED]

[<using-specification>]

[<free-specification>]

[DEFINE <YES | NO>]

[COMPRESS <YES | NO>]

[PARTITION BY RANGE <partition-element>

<using-specification>

<free-specification>]

[BUFFERPOOL <bp-name>]

[CLOSE <YES | NO>]

[DEFER <YES | NO>]

[PIECESIZE <integer>]


C3: Protected

Handout: DB2

[COPY <YES | NO>]


USING

VCAT <catalog-name> |


PRIQTY <integer>

SECQTY <integer>

ERASE <YES | NO>

<free-specification>

FREEPAGE <integer>

PCTFREE <integer>

<partition-element>

PARTITION <integer>

ENDING AT (<constant/MAXVALUE/MINVALUE>)

UNIQUE: This prevents the table from containing two or more rows with the same

value of the index key. ASC:

o Specifies that the index entries are to be kept in ascending order of the column values.

o This is the default setting. DESC: Specifies that index entries are to be kept in descending order of the column

values. CLUSTER or NOT CLUSTER: Specifies whether the index is the clustering index for

the table or not. PARTITIONED: Specifies that the index is data partitioned PADDED or NOT PADDED: Specifies how varying-length string columns are to be

stored in the index. o PADDED: Specifies that varying-length string columns within the index are always

padded with the default pad character to their maximum length. o NOT PADDED: Specifies that varying-length string columns are not to be padded

to their maximum length in the index. Using clause:

o For non-partitioned indexes, the USING clause indicates whether the data sets for the index are to be managed by the user or managed by DB2.

o VCAT: Specifies that the first data set for the index is managed by the user, and that following data sets, if needed, are also managed by the user.

o STOGROUP: Specifies that DB2 will define and manage the index data sets. PRIQTY: Specifies the minimum primary space allocation for the DB2 managed data set. SECQTY: Specifies the minimum secondary space allocation for the DB2 managed data set. ERASE: Indicates whether the DB2-managed data sets are to be erased when the index is deleted.

FREEPAGE: Specifies how often to leave a page of free space when index entries are created.


C3: Protected

Handout: DB2

PCTFREE: Determines the percentage of free space to be left in each non-leaf page and leaf page when entries are added to the index.

DEFINE: Specifies when the underlying data sets for the index are physically created. o YES:

The data sets are created when the index is created YES is the default.

o NO: The data sets are not created until data is inserted into the index. COMPRESS: Specifies whether compression for index data will be used.

o NO: Specifies that no index compression will be used. This is the default.

o YES: Specifies that index compression will be used. PARTITION BY RANGE: Specifies the index is the partitioning index.

o PARTITION integer: A PARTITION clause specifies the highest value of the index key in one partition of a partitioning index.

o ENDING AT: Specifies that this is the partitioning index and indicates how the data will be partitioned.

CONSTANT: Specifies a constant value with a data type that must conform to the rules for assigning that value to the column. MAXVALUE: Specifies a value greater than the maximum value for the limit key of a partition boundary. MINVALUE: Specifies a value that is smaller than the minimum value for the limit key of a partition boundary.

BUFFERPOOL: Identifies the buffer pool that is to be used for the index. CLOSE: Specifies whether or not the data set is eligible to be closed when the index

is not being used and the limit on the number of open data sets is reached. o YES: Eligible for closing. This is the default o NO: Not eligible for closing.

DEFER: Indicates whether the index is built during the execution of the CREATE INDEX statement. o NO: The index is built. This is the default. o YES: The index is not built.

PIECESIZE: Specifies the maximum addressability of each data set for an index. COPY: Indicates whether the COPY utility is allowed for the index.

o NO: Does not allows full image or concurrent copies NO is the default.

o YES: Allows full image or concurrent copies. Example:

1. Create an index on the column TAB1_COL2 of a table TB_TAB1.

CREATE INDEX IX_TAB1_COL2

ON TB_TAB1(TAB1_COL2);


C3: Protected

Handout: DB2

2. Create an index named IX_PROJECT_NAME on the TB_PROJECT table. The purpose of the index is to ensure that there are not two entries in the table with the same value for project name (PROJECT_NAME). The index entries are to be in ascending order.

CREATE UNIQUE INDEX IX_PROJECT_NAME ON TB_PROJECT(PROJECT_NAME);

3. Create an index named IX_EMPLOYE_JOB_DEPT on the TB_EMPLOYE table. Arrange the

index entries in ascending order by job title (EMPLOYE_JOB) within each department (EMPLOYE_DEPT).

CREATE INDEX IX_EMPLOYE_JOB_DEPT

ON TB_EMPLOYE (EMPLOYE_DEPT, EMPLOYE_JOB);

Example: Create a unique index, named DSN8910.IX_DEPT, on table DSN8910.TB_DEPT. Index entries are to be in ascending order by the single column DEPT_NO. DB2 is to define the data sets for the index, using storage group DSN8G910. Each data set should hold 1 megabyte of data at most. Use 512 kilobytes as the primary space allocation for each data set and 64 kilobytes as the secondary space allocation. Make the index padded. The data sets can be closed when no one is using the index and do not need to be erased if the index is dropped. CREATE UNIQUE INDEX DSN8910.IX_DEPT

ON DSN8910.TB_DEPT

(DEPT_NO ASC)

PADDED


PRIQTY 512

SECQTY 64

ERASE NO

BUFFERPOOL BP1

CLOSE YES

PIECESIZE 1M;

Explanation: The underlying data sets for the index will be created immediately, which is the default (DEFINE YES). Assuming that table DSN8910.TB_DEPT is empty, if we wanted to defer the creation of the data sets until data is first inserted into the index, we would specify DEFINE NO instead of accepting the default behavior. Specifying PADDED ensures that the varying-length character string columns in the index are padded with blanks.


C3: Protected

Handout: DB2

Example: Create a cluster index, named IX_EMP, on table TB_EMP in database DSN8910. Put the entries in ascending order by column EMP_NO. Let DB2 define the data sets for each partition using storage group DSN8G910. Make the primary space allocation be 36 kilobytes, and allow DB2 to use the default value for SECQTY. If the index is dropped, the data sets need not be erased. There are to be 4 partitions, with index entries divided among them as follows: Partition 1: entries up to H99

Partition 2: entries above H99 up to P99 Partition 3: entries above P99 up to Z99 Partition 4: entries above Z99

Associate the index with buffer pool BP1 and allow the data sets to be closed when no one is using the index. Enable the use of the COPY utility for full image or concurrent copies. CREATE INDEX DSN8910.IX_EMP

ON DSN8910.TB_EMP

(EMP_NO ASC)

USING

STOGROUP DSN8G910

PRIQTY 36

ERASE NO

CLUSTER

PARTITION BY RANGE

(PARTITION 1 ENDING AT('H99'),

PARTITION 2 ENDING AT('P99'),

PARTITION 3 ENDING AT('Z99'),

PARTITION 4 ENDING AT('999'))

BUFFERPOOL BP1

CLOSE YES

COPY YES;

DDL – Alter Index

Following is the index alteration syntax. ALTER INDEX <index-name>

[REGENERATE]

[ADD COLUMN (<column-name> ASC/DESC)]

[CLUSTER | NOT CLUSTER]

[PADDED | NOT PADDED]

[<using-specification>]

[<free-specification>]

[COMPRESS <YES | NO>]

[ALTER <partition-element>


<free-specification>]


C3: Protected

Handout: DB2

[BUFFERPOOL <bp-name>]

[CLOSE <YES | NO>]

[PIECESIZE <integer>

[COPY <YES | NO>]

REGENERATE: Specifies that the index will be regenerated. ADD COLUMN: Adds column-name to the index. ALTER PARTITION: Identifies the partition of the index to be altered.

Example:

1. Alter the index DSN8910.IX_EMP. Indicate that DB2 is not to close the data sets that support the index when there are no current users of the index. ALTER INDEX DSN8910.IX_EMP

CLOSE NO;

2. Alter partitioned index DSN8910.IX_DEPT. For partition 3, leave one page of free space

for every 13 pages and 13 percent of free space per page. For partition 5, leave one page for every 25 pages and 25 percent of free space. For all the other partitions, leave one page of free space for every 6 pages and 11 percent of free space.

ALTER INDEX DSN8910.IX_DEPT

USING

VCAT CATLGG

FREEPAGE 6

PCTFREE 11

ALTER PARTITION 3

USING VCAT CATLGG

FREEPAGE 13

PCTFREE 13,

ALTER PARTITION 5

USING VCAT CATLGG

FREEPAGE 25

PCTFREE 25;

Try It Out

Problem Statement: 1. Alter the index DSN8910.IX_PROJ. Use BP1 as the buffer pool that is to be associated

with the index, indicate that full image or concurrent copies on the index are allowed, and change the maximum size of each data set to 8 megabytes.

2. Assume that index IX_X1 contains a least one varying-length column and is a padded index. Alter the index to an index that is not padded.


C3: Protected

Handout: DB2

Code: 1. ALTER INDEX DSN8910.IX_PROJ BUFFERPOOL BP1 COPY YES PIECESIZE 8M;

2. ALTER INDEX IX_X1 NOT PADDED;

DDL – Create View

Following is the view creation syntax. CREATE VIEW <view-name>

AS <query>

Example: Create a view named VW_PROJECT upon the TB_PROJECT table that contains only those rows with a project number (PROJECT_NO) starting with the letters 'MA'. CREATE VIEW VW_PROJECT

AS SELECT *

FROM TB_PROJECT

WHERE SUBSTR(PROJECT_NO, 1, 2) = 'MA'

DDL – Alter View

Following is the view alteration syntax. ALTER VIEW <view-name> REGENERATE

You use the ALTER VIEW command to regenerate an invalid view after altering one of

the base tables to ensure that the view continues to be valid.

DDL – Create Alias

Following is the alias creation syntax. CREATE ALIAS <alias-name>

FOR <table-name> |

<view-name>

Example: Create an alias for a table TB_TAB1. CREATE ALIAS AL_TAB1

FOR TB_TAB1;

DDL – Create Synonym

Following is the synonym creation syntax. CREATE SYNONYM <synonym-name>

FOR <authorization-name>.<table-name> |

<authorization-name>.<view-name>


C3: Protected

Handout: DB2

Example: Create a synonym for a table DSN8910.TB_DEPT. CREATE SYNONYM SN_DEPT

FOR DSN8910.TB_DEPT;

DDL – DROP

The DROP statement removes an object in the current server. DATABASE: Whenever a database is dropped, all of its tablespaces, tables, index spaces, and indexes are also dropped. Tablespace: Whenever a tablespace is dropped, all the tables in the tablespace are also dropped. Table: Whenever a table is dropped, all referential constraints in which the table is a parent or dependent, and all synonyms, views, and indexes defined on the table are also dropped. If the table space for the table was implicitly created, it is also dropped. Alias is not dropped. DROP STOGROUP <stogroup-name>

DATABASE <database-name>

TABLESPACE <table-space-name>

TABLE <table-name>

INDEX <index-name>

VIEW <view-name>

ALIAS <alias-name>

SYNONYM <synonym-name>

Summary

Object Operation DDL

Table Creation CREATE TABLE

Table Alteration ALTER TABLE

Index Creation CREATE INDEX

Index Alteration ALTER INDEX

View Creation CREATE VIEW

View Alteration ALTER VIEW

Alias Creation CREATE ALIAS

Synonym Creation CREATE SYNONYM

In order to delete the objects, you need to issue “DROP” command.


C3: Protected

Handout: DB2


1. List the different ways in which tables can be created. 2. Describe how do you create a table and explain the options. 3. Describe how do you alter a table and explain the options. 4. Describe how do you create an index and explain the options. 5. Describe how do you alter an index and explain the options. 6. Describe how do you create a view and explain the options. 7. What is the need of altering the view? 8. How do you create an alias? 9. How do you create a synonym? 10. How can you delete the objects?

Exercises

1. Create a table PATIENT with the following characteristics: PATIENT_NO CHAR(4)

LASTNAME VARCHAR(30)

FIRSTNAME VARCHAR(30)

GENDER CHAR(1) – Should accept only the values “M” & “F”

DATE_OF_BIRTH DATE

2. Create a table PATIENT_ADDRESS with the following characteristics: PATIENT_NO CHAR(4)

LINE_NO CHAR(1)

ADDRESS VARCHAR(30)

Primary key: PATIENT_NO,LINE_NO

Foreign Key : PATIENT_NO (PATIENT Table)


C3: Protected

Handout: DB2

Session 11: SQL

Learning Objectives

After completing this session, you will be able to: Perform the following DML (Data Manipulation Language) operations:

o Insert o Update o Delete o Retrieval (Simple, multiple columns, all columns) o Sorting the retrieved data o Filtering the data o Concatenation o Using alias o Removing duplicates o Functions

DML – Insert

The INSERT command adds new rows to a table or view. Inserting a row into a view also inserts the row into the table on which the view is based INSERT INTO <table-name>/<view-name>

[(<column-names>)]

VALUES (<values>)

Example: The table TB_DEPT contains the following columns:

DEPT_NO

DEPT_NAME

DEPT_MGR_NO

DEPT_ADMR.

1. Insert a new department with the following specifications into the TB_DEPT table. Department number (DEPT_NO) is 'E31' Department name (DEPT_NAME) is 'ARCHITECTURE' Managed by (DEPT_MGR_NO) a person with number '00390' Reports to (DEPT_ADMR) department 'E01'.

INSERT INTO TB_DEPT

VALUES (‘E31’

, ‘ARCHITECTURE’

, ‘00390’

, ‘E01’);


C3: Protected

Handout: DB2

2. Insert a new department into the TB_DEPT table as in example 1, but do not assign a manager to the new department.

INSERT INTO TB_DEPT (DEPT_NO

, DEPT_NAME

, DEPT_ADMR )

VALUES (‘E31’

, ‘ARCHITECTURE’

, ‘E01’);

DML – Update

The UPDATE statement updates the values of specified columns in the rows of a table or view. UPDATE <table-name> / <view-name>

SET <column-name>=<value>

WHERE <search-condition>

Example: Change the manager (DEPT_MGR_NO) for the department (DEPT_NAME) ‘ARCHITECTURE’ to ‘00455’, in the table TB_DEPT. UPDATE TB_DEPT

SET DEPT_MGR_NO = ‘00455’

WHERE DEPT_NAME = ‘ARCHITECTURE’ ;

DML – Delete

The DELETE statement deletes rows from a table or view DELETE <table-name> / <view-name>

WHERE <search-condition>

Note: If there is no “where” clause in the Delete statement, then SQL will delete all the data in the table. So you need to be very careful while executing the Delete statement and make sure that there is a Where clause. Example:

1. Delete department (DEPT_NO) 'D11' from TB_DEPT table. DELETE FROM TB_DEPT

WHERE DEPT_NO = ‘D11’;

2. Delete all the departments from TB_DEPT table (that is, empty the table).

DELETE FROM TB_DEPT;


C3: Protected

Handout: DB2

DML – Simple Retrieval

SELECT is used to retrieve table data To use SELECT, at a minimum, specify two pieces of information, that what you want to select and from where you want to select it. SELECT <column-name>

FROM <table-name>

Example: SELECT prod_name FROM tb_prod;

This SELECT statement will retrieve a single column called prod_name from the table tb_prod.

DML – Retrieving Multiple Columns

To retrieve multiple columns from a table, multiple column names must be specified after the SELECT keyword, and each column must be separated by a comma. Example: SELECT prod_id, prod_name, prod_price

FROM tb_prod;

This SELECT statement will retrieve data from multiple columns of the tb_prod table.

DML – Retrieving All Columns

In addition to being able to specify desired columns (one or more, as seen earlier), SELECT statements can also request all columns without having to list them individually. This is done by using the asterisk (*) wildcard character in lieu of actual column names, as follows: Example: SELECT * FROM tb_prod;

DML – Sorting Retrieved data

To explicitly sort data retrieved using a SELECT statement, the ORDER BY clause is used. SELECT <column-name>

FROM <table-name>

ORDER BY <column-name>

Example: SELECT prod_name

FROM tb_prod

ORDER BY prod_name;

This statement sorts the data alphabetically in the ascending order by the prod_name column.


C3: Protected

Handout: DB2

DML – Sorting by Multiple Columns

To sort by multiple columns, simply specify the column names separated by commas in the ORDER BY clause. Example: SELECT prod_id, prod_price, prod_name

FROM tb_prod

ORDER BY prod_price, prod_name;

This code retrieves three columns and sorts the results by two of them, first by price and then by name.

DML – Sorting by Column Position

ORDER BY also supports ordering specified by relative column position. Example: SELECT prod_id, prod_price, prod_name

FROM tb_prod

ORDER BY 2, 3;

ORDER BY 2 means sort by the second column in the SELECT list, the prod_price column. ORDER BY 2, 3 means sort by prod_price and then by prod_name.

DML – Specifying Sort Direction

Data sorting is not limited to ascending sort orders (from A to Z). Although this is the default sort order, the ORDER BY clause can also be used to sort in descending order (from Z to A). To sort by descending order, the keyword DESC must be specified. Example: SELECT prod_id, prod_price, prod_name

FROM tb_prod

ORDER BY prod_price DESC;

This code sorts the products by price in descending order (most expensive first).

DML – Filtering Data

Retrieving just the data you want, involves specifying search criteria, also known as a filter condition. Within a SELECT statement, data is filtered by specifying search criteria in the WHERE clause. Example: SELECT prod_name, prod_price

FROM tb_prod

WHERE prod_price = 3.49;


C3: Protected

Handout: DB2

This statement retrieves two columns from the tb_prod table, but instead of returning all rows, only rows with a prod_price value of 3.49 are returned

DML – WHERE Clause Operators

SQL supports a whole range of conditional operators in the WHERE clause as listed.

Operator Description

= Equality

<> Non-equality

!= Non-equality

< Less than

<= Less than or equal to

!< Not less than

> Greater than

>= Greater than or equal to

!> Not greater than

BETWEEN Between two specified values including the specified start and end value

IS NULL Is a NULL value

Example:

To List all products that cost less than $10

SELECT prod_name, prod_price

FROM tb_prod

WHERE prod_price < 10;

To List all products not made by vendor DLL01

SELECT vend_id, prod_name

FROM tb_prod

WHERE vend_id <> 'DLL01';

To retrieve all products with a price between $5 and $10, including the specified start and end values.

SELECT prod_name, prod_price

FROM tb_prod

WHERE prod_price BETWEEN 5 AND 10;

To return a list of all products that have no price (price unknown)

SELECT prod_name

FROM tb_prod

WHERE prod_price IS NULL;


C3: Protected

Handout: DB2

DML – Advanced Filtering

For a greater degree of filter control, SQL lets you specify multiple WHERE clauses. Operator: A special keyword used to join or change clauses within a WHERE clause. This is also known as logical operators.

Using the AND Operator To filter by more than one column, we use the AND operator to append conditions to our WHERE clause. This is a keyword used in a WHERE clause to specify that only rows matching all the specified conditions should be retrieved. “AND” instructs the DB2 to return only rows that meet all the conditions specified. Example: SELECT prod_id, prod_price, prod_name

FROM tb_prod

WHERE vend_id = 'DLL01' AND prod_price <= 4;

The earlier SQL statement retrieves the product name and price for all products made by vendor DLL01 as long as the price is $4 or less. The WHERE clause in this SELECT statement is made up of two conditions, and the keyword AND is used to join them.

Using the OR Operator The OR operator is exactly the opposite of AND. The OR operator instructs the DB2 to retrieve rows that match either condition not both. Example: SELECT prod_name, prod_price

FROM tb_prod

WHERE vend_id = 'DLL01' OR vend_id = 'BRS01';

The earlier SQL statement retrieves the product name and price for any products made by either of the two specified vendors.

Order of Evaluation WHERE clauses can contain any number of AND and OR operators. SQL processes AND operators before OR operators. Example To get a list of all products costing $10 or more made by vendors DLL01 and BRS01 SELECT prod_name, prod_price

FROM Products

WHERE (vend_id = 'DLL01' OR vend_id = 'BRS01') AND prod_price >= 10;

If you do not use parentheses, you will not get desired output. Whenever you write WHERE clauses that use both AND and OR operators, use parentheses to explicitly group operators.


C3: Protected

Handout: DB2

Using the IN Operator The IN operator is used to specify a range of conditions, any of which can be matched. Example: SELECT prod_name, prod_price

FROM tb_prod

WHERE vend_id IN ('DLL01','BRS01')

ORDER BY prod_name;

IN operator accomplishes the same goal as OR. But IN has the following advantages. For long lists of valid options, the IN operator syntax is far cleaner and easier to read. The order of evaluation is easier to manage. The biggest advantage of IN is that the IN operator can contain another SELECT

statement.

Using the NOT Operator NOT is a keyword used in a WHERE clause to negate a condition. Example SELECT prod_name

FROM tb_prod

WHERE NOT vend_id = 'DLL01'

This code lists the products made by all vendors except vendor DLL01.

DML – Wildcard Filtering

Wildcards are special characters used to match parts of a value. To use wildcards in search clauses, the LIKE operator must be used. Wildcard searching can be used only with text fields (strings).

The Percent Sign (%) Wildcard Within a search string, % means match any number of occurrences of any character. Example: To find all products that start with the word Fish SELECT prod_id, prod_name

FROM tb_prod

WHERE prod_name LIKE 'Fish%‘;


C3: Protected

Handout: DB2

The Underscore (_) Wildcard The underscore is used just like %, but instead of matching multiple characters, the underscore matches just a single character. Example: To find all products that has two characters followed by “inch teddy bear” SELECT prod_id, prod_name

FROM tb_prod

WHERE prod_name LIKE '__ inch teddy bear ';

DML – Removing Duplicates

SQL uses DISTINCT to remove duplicates from the result set. Example: For getting the unique Vendor Zip codes, you need to use the following query. SELECT DISTINCT vend_zipcode

FROM tb_vend;

DML – Concatenating Fields

Concatenation is joining values together (by appending them to each other) to form a single long value. In SQL SELECT statements, you can concatenate columns by using a special operator “||”. Example: SELECT vend_name || ' (' || vend_country || ')'

FROM tb_vend

ORDER BY vend_name;

The result of this query is as follows.

----------------------------------------------------------

Bear Emporium (USA )

Bears R Us (USA )

Doll House Inc. (USA )

DML – Using Aliases

An alias is just that, an alternative name for a field or value. Aliases are assigned with the AS keyword. Example: SELECT vend_name || ' (' || vend_country || ')' AS vend_title

FROM tb_vend;

The result of this query is as follows.


C3: Protected

Handout: DB2

vend_title

----------------------------------------------------

Bear Emporium (USA)

Bears R Us (USA)

Doll House Inc. (USA)

DML – Performing Mathematical Calculations

SQL Mathematical Operators are as follows:

Operator Description

+ Addition

- Subtraction

* Multiplication

/ Division

Example: SELECT order_id, order_quantity, order_item_price, order_quantity*order_item_price AS expanded_price

FROM tb_order

WHERE order_num = 20008;

DML – Functions

Types of Functions are as follows: Aggregate function Text function Date and time functions Numeric functions

DML – Aggregate Functions

Aggregate Functions are functions that operate on a set of rows to calculate and return a single value. It is often necessary to summarize data without actually retrieving it all, and SQL provides special functions for this purpose. Examples of this type of retrieval are:

Determining the number of rows in a table Obtaining the sum of a set of rows in a table. Finding the highest, lowest, and average values in a table column.


C3: Protected

Handout: DB2

Following is the list of Aggregate Functions:

Function Description

AVG() Returns a column's average value

COUNT() Returns the number of rows in a column

MAX() Returns a column's highest value

MIN() Returns a column's lowest value

SUM() Returns the sum of a column's values

Example: SELECT AVG(prod_price) AS avg_price

FROM tb_prod;

DML – Text Functions

Following is the list of commonly used Text-Manipulation Functions:

Function Description Example

LEFT() Returns characters from left of string LEFT(cust_firstname, 4)

LENGTH() Returns the actual length of a string LENGTH(cust_firstname)

LOWER() Converts string to lowercase LOWER(cust_firstname)

LTRIM() Trims white space from left of string LTRIM(cust_firstname)

RIGHT() Returns characters from right of string RIGHT(cust_firstname)

RTRIM() Trims white space from right of string RTRIM(cust_firstname)

UPPER() Converts string to uppercase UPPER(cust_firstname)

SUBSTR() Returns a substring of a string. 2nd argument – starting position 3rd argument – length

SUBSTR(cust_firstname,3,4)

HEX() Returns the hexadecimal representation of its argument

HEX(cust_firstname)

DML – Date and Time Manipulation Functions

Following is the list of commonly used Date and Time Manipulation Functions:

Function Description Example CHAR Returns a string representation of its first

argument. CHAR(cust_hiredate,USA)

DAYS Returns an integer representation of its argument.

DAYS(‘2008-01-01’)

YEAR Returns the year part of its argument YEAR(cust_hiredate)

MONTH Returns the month part of its argument MONTH(cust_hiredate)

DAY Returns the day part of its argument DAY(cust_hiredate)

HOUR Returns the hour part of its argument HOUR(CURRENT TIME)


C3: Protected

Handout: DB2


C3: Protected

Function Description Example MINUTE Returns the minute part of its argument MINUTE(CURRENT TIME)

SECOND Returns the seconds part of its argument SECOND(CURRENT TIME)

MICROSECOND Returns the microsecond part of its argument

MICROSECOND(CURRENT TIMESTAMP)

DATE Returns the date derived from its argument

DATE(‘2008-01-01’)

TIME Returns the time derived from its argument

TIME(’13:00:00’)

TIMESTAMP Returns the timestamp derived from its argument

TIMESTAMP(CURRENT DATE)

DML – Numeric Functions

Following is the list of commonly used numeric functions:

Function Description Example DECIMAL Returns a decimal representation of its argument DECIMAL(inv_total, 10,3)

DIGITS Returns a character string representation of its argument

DIGITS(inv_total)

FLOAT Returns a floating point representation FLOAT(cust_salary)

INTEGER Returns an integer representation INTEGER(cust_salary+.5)

ABS() Returns a number's absolute value ABS(inv_total)

COS() Returns the trigonometric cosine of a specified angle

COS(inv_total)

EXP() Returns the exponential value of a specific number

EXP(inv_total)

PI() Returns the value of PI PI(inv_total)

SIN() Returns the trigonometric sine of a specified angle

SIN(inv_total)

SQRT() Returns the square root of a specified number SQRT(inv_total)

TAN() Returns the trigonometric tangent of a specified angle

TAN(inv_total)

Summary

Types of DML functions are as follows: o Aggregate function o Text function o Date and time functions o Numeric functions

Handout: DB2

o

Clause Description

INSERT Populate the data into table or view

UPDATE Update the data in the table or view

DELETE Delete the data from table or view

SELECT Columns or expressions to be returned

FROM Table to retrieve data from

WHERE Row-level filtering

ORDER BY Sort the data retrieved

DISTINCT Remove duplicates


1. How do you insert the data into a table or view? 2. How do you update the data in a table or view? 3. How do you delete the data from the table or view? 4. How do you retrieve multiple column values from the table? 5. How do you retrieve all the column values from the table? 6. How do you sort the retrieved data? 7. How do you filter the data retrieved? 8. What are the different WHERE clause operators? 9. Explain about the logical operators in the WHERE clause. 10. How do you match parts of the value? 11. How do you remove duplicates? 12. How do you concatenate fields? 13. What are the mathematical operators? 14. Explain different types of functions.

Exercises

1. Insert the following rows into the table PATIENT.

PATIENT_NO LASTNAME FIRSTNAME GENDER DATE_OF_BIRTH

A111 HAR BHU F 1975-07-27

A112 MAHESH LATHA F 1980-08-17

A113 SWAMI VIGNESH M 1985-01-07

A114 RAM PRABHU M 1981-04-27

A115 KRISHNA DHILIP M 1969-04-14

A116 KANNAN LEKHA F 1980-05-18

A117 VENKAT DEEPA F 1977-02-21

A118 SWAMI AKILA F 1960-08-29

A119 GOPI KANNAN M 1965-05-17

A120 MS GEETHA F 1975-08-27


C3: Protected

Handout: DB2

2. Get gender and date of birth of patients. 3. Count the number of patients. 4. Get last names and first names of all patients whose last name starts with a letter 'M'. 5. Get last names and first names of all patients whose last name starts with a letter 'M' and

whose last name has only 2 characters. 6. Get Female patients only ordered by date of birth. 7. Get last name and first names of all patients who were born:

before 1st January 1960 after 31st December 1975 between 1st January 1959 and the 31st December 1975

8. Add following rows to PATIENT_ADDRESS table.

PATIENT_NO LINE_NO ADDRESS

A111 1 G3

A111 2 KONDAPUR

A111 3 HYDERABAD

A112 1 A12G3

A112 2 KUKATPALLY

A112 3 HYDERABAD

A113 1 G3

A113 2 NUNGAMBAKKAM

A113 3 CHENNAI

A114 1 A14G3

A114 2 KK NAGAR

A114 3 CHENNAI

A115 1 G3

A115 2 KORAMANGALA

A115 3 BANGALORE


C3: Protected

Handout: DB2

Session 12: SQL

Learning Objectives

After completing this session, you will be able to: Perform the following DML operations:

o Grouping o Subquery o Join o Union o DCL

Grant Revoke

DML – Grouping Data

Grouping lets you divide data into logical sets so that you can perform aggregate calculations on each group. Groups are created using the GROUP BY clause in the SELECT statement. The GROUP BY clause instructs the DB2 to group the data and then perform the aggregate on each group rather than on the entire result set. Example: SELECT prod_vend_id, COUNT(*) AS num_prods

FROM tb_prod

GROUP BY prod_vend_id;

The result of this query is as follows. prod_vend_id num_prods

-----------------------------

BRS01 3

DLL01 4

FNG01 2

This statement specifies two columns, prod_vend_id, which contains the ID of a product's vendor, and num_prods, which is a calculated field (created using the COUNT(*) function). The GROUP BY clause instructs DB2 to sort the data and group it by vend_id. This causes num_prods to be calculated once per vend_id rather than once for the entire table


C3: Protected

Handout: DB2

DML – Filtering Groups

In addition to being able to group data using GROUP BY, SQL also allows you to filter which groups to include and which to exclude. For example, you might want a list of all customers who have made at least two orders. To obtain this data you must filter based on the complete group, not on individual rows.

HAVING is very similar to WHERE. The only difference is that WHERE filters rows and HAVING filters groups. WHERE filters before data is grouped and HAVING filters after data is grouped. Example: SELECT order_cust_id, COUNT(*) AS orders

FROM tb_order

GROUP BY order_cust_id

HAVING COUNT(*) >= 2;

SELECT prod_vend_id, COUNT(*) AS num_prods FROM tb_prod

WHERE prod_price >= 4

GROUP BY prod_vend_id

HAVING COUNT(*) >= 2;

DML – Grouping and Sorting

To sort the output of GROUP BY, you need to use ORDER BY.

Example SELECT order_num, COUNT(*) AS items

FROM tb_order

GROUP BY order_num

HAVING COUNT(*) >= 3

ORDER BY order_num;

In this statement, GROUP BY clause is used to group the data by order number so that the COUNT(*) function can return the number of items in each order. The HAVING clause filters the data so that only orders with three or more items is returned. Finally, the output is sorted using the ORDER BY clause.

DML – Subquery

Subqueries are used to combine different queries into one single statement. Subqueries are always processed starting with the innermost SELECT statement and working outward. Example: SELECT order_cust_id

FROM tb_order

WHERE order_num IN


C3: Protected

Handout: DB2

(SELECT order_item_num

FROM tb_order_item

WHERE order_item prod_id = 'RGAN01');

When the preceding SELECT statement is processed, the DBMS actually performs two operations. First it runs the subquery:

SELECT order_item_num

FROM tb_order_item

WHERE order_item_prod_id = 'RGAN01'

This query is called “Inner Query”. This query returns two order numbers 20007 and 20008. Those two values are then passed to the WHERE clause of the “outer query” in the comma-delimited format required by the IN operator. The outer query now becomes the following: SELECT order_cust_id

FROM tb_order

WHERE order_num IN (20007,20008)

You can use subquery in a Simple Comparison: IN

ANY

SOME

ALL

EXIST

If a subquery returns a single row, then the =, <, >, <=, >=, or <> operator may be used for comparison with the subquery. If multiple records are returned, the IN, ANY, ALL or SOME operator must be used. With ANY or SOME, the condition must be true for any one of the values returned by the subquery. With ALL, the condition must be true for all of the values returned by the subquery.

Example: Subquery which uses ANY operator is as follows: SELECT cust_no

FROM tb_cust

WHERE cust_no = ANY

(SELECT inv_cust_no

FROM tb_inv

WHERE inv_total > 200);


C3: Protected

Handout: DB2

Types of subqueries

There are two types of subqueries: Non-correlated subquery Correlated subquery

Non-correlated subquery: In the subquery if the inner query and the outer query work independently, then the subquery is called Non-correlated subquery. Correlated subquery: In correlated subquery, the inner query does not work independently of the outer query. In this, the inner query is performed once for each row of the outer query. To correlate the table in the inner query with the table in the outer query, you need to define an alias for the outer query and use it as a qualifier in the inner query.

When you use the alias in this context, it is called “correlation name” and the connection it makes is called a “correlated reference”.

A correlated subquery with the EXISTS keyword does not name any column because no data is transferred when you use EXISTS.

Example: SELECT cust_name

FROM tb_cust A

WHERE NOT EXISTS

(SELECT * FROM tb_inv WHERE inv_cust = A.cust_no)

EXISTS Operator The EXISTS operator is used for correlated subqueries. It tests if the subquery returns at least one row. The EXISTS operator returns true or false, never unknown. Because EXISTS tests only if a row exists, the columns shown in the SELECT list of

the subquery are irrelevant. Typically, you use a single character text literal such as '1' or 'X' or the keyword NULL.

Example: This is a correlated subquery displays instructors where the INSTRUCTOR_ID has a matching row in the SECTION table. The result shows the INSTRUCTOR_ID, INSTRUCTOR_FIRST_NAME column values of instructors assigned to at least one section. SELECT instructor_id, instructor_last_name

FROM tb_instructor I

WHERE EXISTS

(SELECT 'X'

FROM tb_section


C3: Protected

Handout: DB2

WHERE I.instructor_id = instructor_id)

For every row of the INSTRUCTOR table, the outer query evaluates the inner query. It checks to see if the current row's INSTRUCTOR_ID value exists for the SECTION table's INSTRUCTOR_ID column. Only if a row with the appropriate value is found, the condition is true and the outer row is included in the result.

NOT EXIST Operator: The NOT EXISTS operator is the opposite of the EXISTS operator; it tests if a matching row cannot be found.

DML – Join

A join is a mechanism used to associate tables within a SELECT statement. For creating a join, you must specify all the tables to be included and how they are related to each other. Example: SELECT vend_name, prod_name, prod_price

FROM tb_vend, tb_prod

WHERE tb_vend.vend_id = tb_prod.vend_id;

The SELECT statement starts in the same way as all the statements you have looked at so far, by specifying the columns to be retrieved. The big difference here is that two of the specified columns (prod_name and prod_price) are in one table, whereas the other (vend_name) is in another table. Unlike all the prior SELECT statements, this one has two tables listed in the FROM clause, tb_vend and tb_prod. You must use the fully qualified column name (table and column separated by a period) whenever there is a possible ambiguity about which column you are referring to. In this case, you specify tb_vend.vend_id and tb_prod.vend_id.

Types of Joins

There are two types of joins: Inner Join Outer Join

Inner Join

Inner Joins or Equi Joins are joins which include only the rows where the values in the joined columns match.


C3: Protected

Handout: DB2

You can code inner joins either by Implicit Syntax or Explicit Syntax. Example for Implicit syntax: SELECT vend_name, prod_name, prod_price

FROM tb_vend, tb_prod

WHERE tb_vend.vend_id = tb_prod.vend_id;

Example for Explicit syntax: SELECT vend_name, prod_name, prod_price

FROM tb_vend INNER JOIN tb_prod

ON tb_vend.vend_id = tb_prod.vend_id;

Outer Join

Outer Joins keep unmatched rows from the tables. Types of Outer Joins:

Left Outer Join Right Outer Join Full Outer Join

Join Keep unmatched rows from

Left Outer Join The outer table

Right Outer Join The inner table

Full Outer Join Both the tables

A full outer join can use only equals (=) comparison operator, but left and right outer joins can use any of the comparison operators. Each unmatched row is joined with the null row. Example: The following SELECT statement is a simple inner join. It retrieves a list of all customers and their orders: SELECT cust_id, order_num

FROM tb_cust INNER JOIN tb_order

ON tb_cust.cust_id = tb_order.cust_id;

To retrieve a list of all customers, including those who have placed no orders, you can use the following outer join: SELECT cust_id, order_num

FROM tb_cust LEFT OUTER JOIN tb_order

ON tb_cust.cust_id = tb_order.cust_id;

Each unmatched row is joined with the null row.


C3: Protected

Handout: DB2

Using Table Aliases

To shorten the SQL syntax, you use aliases. Alias will enable multiple uses of the same table within a single SELECT statement. Example: SELECT cust_name, cust_contact

FROM tb_cust C, tb_order O, tb_order_item OI

WHERE C.cust_id = O.cust_id AND

OI.order_num = O.order_num AND

prod_id = 'RGAN01';

Whenever possible, use a join instead of a subquery because:

It is usually easier to understand A join is more efficient because it makes better use of indexes

DML – Union

Using UNION, multiple SELECT statements can be specified, and their results can be combined into a single result set. A UNION must be comprised of two or more SELECT statements, each separated by the keyword UNION. Each query in a UNION must contain the same columns, expressions or aggregate functions Column data types must be compatible Example: You need a report on all customers in Illinois, Indiana, and Michigan. You also want to include all “Fun4All” customers, regardless of state. SELECT cust_name, cust_contact, cust_email

FROM tb_cust

WHERE cust_state IN ('IL','IN','MI')

UNION

SELECT cust_name, cust_contact, cust_email

FROM tb_cust

WHERE cust_name = 'Fun4All';

Including or Eliminating Duplicate Rows The UNION automatically removes any duplicate rows from the query result set. If you want all occurrences of all matches returned, then you can use UNION ALL instead of UNION. Example: SELECT cust_name, cust_contact, cust_email

FROM tb_cust


C3: Protected

Handout: DB2

WHERE cust_state IN ('IL','IN','MI')

UNION ALL

SELECT cust_name, cust_contact, cust_email

FROM tb_cust

WHERE cust_name = 'Fun4All';

DCL

Data should always be protected from would-e thieves or casual browsers. At the same time data must be accessible to users who need access to it, and so DB2 provide administrators with mechanisms by which to grant or restrict access to data. Database Security is managed through the SQL GRANT and REVOKE statements.

DCL - GRANT

Grants privileges to a user to access a DB2 object. Issued by one user to grant certain privileges on resources to another user The general command format is as follows. GRANT {privilege-list/All}

[ON resource-type resource-list] TO

{authorization-id-list/PUBLIC} [WITH GRANT OPTION]

Example: To grant SELECT privileges on the TB_EMPLOYE table to the user HERON

GRANT SELECT

ON EMPLOYEE TO USER HERON

DCL - REVOKE

Used to take away a certain privilege from a user Only privileges previously granted can be revoked Can be issued only by the granter or by a SYSADM user REVOKE {privilege-list/ALL}

[ON resource-type resource-list]

FROM {authorization-id-list/ PUBLIC}

Example: To revoke the SELECT privilege on the EMPLOYEE table from the user HERON REVOKE SELECT

ON EMPLOYEE FROM USER HERON


C3: Protected

Handout: DB2

Summary

Subquery is used to combine different queries. Joins are used to join different tables. It is always advisable to use joins over subqueries to avoid performance issues.

Clause Description

GROUP BY Group specification

HAVING Group-level filtering

UNION Combine the results of the multiple select statements

GRANT Privileges to a user to access a DB2 object

REVOKE Take away a certain privilege from a user


1. Explain about GROUP BY with HAVING clause. 2. What is a subquery? 3. List the operators used in the subquery. 4. Explain the types of subquery. 5. What is a join? 6. Explain about the different types of joins. 7. What is UNION operator? 8. Differentiate between UNION and UNION ALL. 9. What is DCL? 10. Explain about GRANT statement. 11. Explain about REVOKE statement.

Exercises

1. Select last names, first names and addresses (with the address lines displayed correctly) of all patients who have their corresponding addresses in the database. The output should look as follows.

LASTNAME FIRSTNAME ADDRESS

HAR BHU G3

HAR BHU HYDERABAD

HAR BHU KONDAPUR

MAHESH LATHA KUKATPALLY

MAHESH LATHA A12G3

MAHESH LATHA HYDERABAD


C3: Protected

Handout: DB2

2. Get the number of patients in each city. The result should look as follows ---------+---------+---------+---------+---------+--- CITY NUMBER_OF_PATIENTS ---------+---------+---------+---------+---------+---

3. Get the number of patients in the city where there is more than one patient. 4. Get the list of cities from which the patients have come. 5. Get the first name and the corresponding address of the patient. If there is no address

available for the patient the report should show Null values against their names. 6. Get the youngest patient’s first name. 7. Get the first name of the youngest male & female patient with their gender and date of

birth. 8. Get the patient number along with the City who resides in Hyderabad and Chennai. 9. Get the list of patient number only if all the patients are having their corresponding

address. Even when one patient doesn’t have the address, the output report should be empty.

10. Get the list of patient number for all the patients who don’t have address. 11. Get the list of patient number from the patient and patient address table without removing

the duplicate value of patient number. 12. The city name “BANGALORE” got changed to “BLR”. Reflect this change in the addresses

of the patients. 13. Delete the patient whose patient number is “A115” from the database.


C3: Protected

Handout: DB2

Session 21: Introduction to Simple COBOL DB2 Application Program

Learning Objectives

After completing this session, you will be able to: Write a simple COBOL DB2 application program

Embedded SQL

In order to access or modify the data in a DB2 database, as a first step, you need to include SQL statements within the COBOL program. These SQL statements which are being embedded in the COBOL program are referred as “Embedded SQL”. To make the system understand the concept that the SQL is a different language from the host language (COBOL) of the application program, you need to enclose all embedded SQL statements in an EXEC SQL block. Delimit the embedded SQL as follows. EXEC SQL

put text of SQL statement here

END-EXEC.

You must code the EXEC SQL and END-EXEC delimiter clauses in your application program in column 12 through 72, whether they are in the Data Division or in the Procedure Division.

You should not code the embedded SQL in a COPY member.

DCLGEN

While executing the SQL statements in the embedded SQL, you need to move the data from the program to DB2 or/and from DB2 to the program. In order to receive the data that is returned for a row or hold the data to update or add a row to a table, we need to define a structure called “Host Structure”. Although we can code this structure by ourselves, it is easier to let DB2 develop it from the data definitions of the database.

Deceleration Generator (DCLGEN) is the utility that comes with DB2 which generates the host structure for a table. The output of DCLGEN is stored as a member of a PDS (Partitioned Data Set).

The output of DCLGEN has two parts: o First part is “Table Declaration”: This is the “SQL DECLARE TABLE” statement

which names the table and defines each of its columns. o Second part is “Host Structure”: This contains the COBOL definition of the host

variables which can be used for a table in the application program. When we use DCLGEN for creating the COBOL definitions for the host structure, we

can be sure that the COBOL definitions correspond correctly to the DB2 data types. Although we are not required to declare DB2 tables in our application program, doing so is a good programming practice. So explicitly DECLARE all tables to be used by our application program.


C3: Protected

Handout: DB2

Include the DCLGEN output in the WORKING-STORAGE section in order to include table declaration and host structure. You need to use include command for including the DCLGEN output. This is similar to COPY command. This must be delimited by EXEC SQL and END-EXEC. You need to specify the DCLGEN member name in which you have created the DCLGEN output.

EXEC SQL

INCLUDE <declgen-member-name>

END-EXEC.

Options while creating DCLGEN

Following is the list of options available while creating DCLGEN through DB2I: o ACTION:

ADD: For new DCLGEN member REPLACE: For modifying the existing member

o COLUMN LABEL: Tells DCLGEN whether to include labels that are declared on any columns of the table or view as comments in the data declarations. (The SQL statement LABEL creates column labels to use as supplements to column names.) YES: To include column labels. NO: To ignore column labels. This is the default.

o STRUCTURE NAME: You can specify 01 level variable for the host structure. This is optional and if you do not specify, DCLGEN will create a system generated structure name.

o FIELD NAME PREFIX: Specifies a prefix that DCLGEN uses to form field names in the output. For example, if you choose ABCDE, the field names generated are ABCDE1, ABCDE2, and so on. If you leave this field blank, then the field names are the same as the column names in the table or view.

o DELIMIT DBCS: Tells DCLGEN whether to delimit DBCS (Double Byte Character String) table names and column names in the table declaration.

o COLUMN SUFFIX: Tells DCLGEN whether to form field names by attaching the column name as a suffix to the value you specify in FIELD NAME PREFIX. For example, if you specify YES, the field name prefix is NEW, and the column name is EMPNO, the field name is NEWEMPNO. If you specify YES, you must also enter a value in FIELD NAME PREFIX.

o INDICATOR VARS: Tells DCLGEN whether to generate an array of indicator variables for the host variable structure.

o RIGHT MARGIN: Specifies the break point for statement tokens that must be wrapped to one or more subsequent records.


C3: Protected

Handout: DB2

You will create a DCLGEN for a table TB_RATE in “THYD018.DCLGEN.COPYLIB(DRATE)”

Go to DB2I and select Option 2 in DB2I Primary Option Menu as follows:

Option 2 for DCLGEN


C3: Protected

Handout: DB2

In DCLGEN menu, enter appropriate values to create the DCLGEN.

Table Name

Dataset in which DCLGEN is created


C3: Protected

Handout: DB2

Once appropriate values are entered here press enter, we’ll get the following message for the successful creation of DCLGEN.

DCLGEN is created in “THYD018.DCLGEN.COPYLIB(DRATE)” as follows: Example: ******************************************************************

* DCLGEN TABLE(TB_RATE) *

* LIBRARY(THYD018.DCLGEN.COPYLIB(DRATE)) *

* ACTION(REPLACE) *

* LANGUAGE(COBOL) *

* QUOTE *

* ... IS THE DCLGEN COMMAND THAT MADE THE FOLLOWING STATEMENTS *

******************************************************************

EXEC SQL DECLARE TB_RATE TABLE

( RATE_CAT CHAR(1) NOT NULL,

RATE_PER_HOUR INTEGER NOT NULL

) END-EXEC.

******************************************************************

* COBOL DECLARATION FOR TABLE TB_RATE *

******************************************************************

01 DCLTB-RATE.

10 RATE-CAT PIC X(1).

Message for the successful creation of DCLGEN


C3: Protected

Handout: DB2

10 RATE-PER-HOUR PIC S9(9) USAGE COMP.

******************************************************************

* THE NUMBER OF COLUMNS DESCRIBED BY THIS DECLARATION IS 2 *

******************************************************************

Host Variables

An area of storage is allocated by the host language (COBOL) and referenced in an SQL statement and this area is called “Host Variable”. Host structure describes the rows in the table and the host variables are the fields that receive the data that is returned for a row or hold data to update or add a row to a table. We must define host variables in the DATA DIVISION of our program in the WORKING-STORAGE section or in the LINKAGE section. As we’ve seen before, this we’ve achieved by including DCLGEN output in the WORKING-STORAGE section.

When you use host variables in SQL statements, prefix them with a colon (:). When the same variable is referenced by the COBOL program outside the embedded SQL, do not prefix the variable with a colon.

You can use host variables in the following ways: o As output data areas in the INTO clause of the SELECT and FETCH statements o As input data areas for the SET clause of the UPDATE statement o As input data areas for the VALUES clause of the INSERT statement o As search fields in the WHERE clause for SELECT, INSERT, UPDATE, and DELETE

statements o As literals in the SELECT list of a SELECT statement

Example: How to use host variables: EXEC SQL

SELECT EMP_NO

INTO :HOSTVAR-EMPNO

FROM TB_EMP

END-EXEC.

EXEC SQL

UPDATE TB_EMP

SET EMP_SALARY = :HOSTVAR-SALARY

WHERE EMP_NO = :HOSTVAR-EMPNO

END-EXEC.

EXEC SQL

DELETE

FROM TB_EMP

WHERE EMP_DEPT = :HOSTVAR-DEPT

END-EXEC.

EXEC SQL


C3: Protected

Handout: DB2

INSERT INTO TB_DEPT (DEPT_NO)

VALUES (:HOSTVAR-DEPTNO)

END-EXEC.

SQLCA

While executing the application program, we need the information of describing the success or failure of the execution of an embedded SQL statement. For this purpose, you must include a structure called SQLCA (SQL Communication Area) in each DB2 application program. You do so by coding the following statement in our WORKING-STORAGE section: EXEC SQL

INCLUDE SQLCA

END-EXEC.

Following is the COBOL layout of the expanded SQLCA: 01 SQLCA.

05 SQLCAID PIC X(8).

05 SQLCABC PIC S9(9) COMPUTATIONAL.

05 SQLCODE PIC S9(9) COMPUTATIONAL.

05 SQLERRM.

49 SQLERRML PIC S9(4) COMPUTATIONAL.

49 SQLERRMC PIC X(70).

05 SQLERRP PIC X(8).

05 SQLERRD OCCURS 6 TIMES PIC S9(9) COMPUTATIONAL.

05 SQLWARN.

10 SQLWARN0 PIC X(1).








05 SQLEXT.



10 SQLWARNA PIC X(1).

10 SQLSTATE PIC X(5).


C3: Protected

Handout: DB2

SQLCODE

The field SQLCODE in SQLCA, contains the return code passed by DB2 to the application program. The return code provides information about the execution of the last SQL statement.

SQLCODE Value Meaning

Zero Statement successful

Positive Statement successful, but with some exceptional condition

+100 Row not found or end of data

Negative Statement failed and serious error detected

Try It Out

Problem Statement: Write a COBOL DB2 application program, to get the hourly rate for a particular rate category supplied by the user. Code: IDENTIFICATION DIVISION.

PROGRAM-ID. FIRSTCD.

ENVIRONMENT DIVISION.

DATA DIVISION.

WORKING-STORAGE SECTION.

******************************************************************

* VARIABLES FOR ERROR ROUTINE.

******************************************************************

01 WS-ERROR-MESSAGE.

10 FILLER PIC X(12) VALUE 'SQLCODE IS: '.

10 WS-SQLCODE PIC -9(3).

10 FILLER PIC X(5) VALUE SPACES.

10 WS-TABLE PIC X(15) VALUE SPACES.


10 WS-PARA PIC X(20) VALUE SPACES.

******************************************************************

* INCLUDE DCLGEN

******************************************************************

EXEC SQL

INCLUDE DRATE

END-EXEC.

******************************************************************

* INCLUDE SQLCA

******************************************************************

EXEC SQL

INCLUDE SQLCA


C3: Protected

Handout: DB2

END-EXEC.

LINKAGE SECTION.

01 PARM-VALUE.

05 PARM-LEN PIC S9(4) COMP.

05 PARM-TXT PIC X(4).

******************************************************************

* FIRST COBOL DB2 PROGRAM WHICH GIVES THE HOURLY RATE FOR A

* PARTICULAR RATE CATEGORY SUPPLIED BY THE USER.

******************************************************************

PROCEDURE DIVISION USING PARM-VALUE.

0000-MAIN-PARA.

MOVE PARM-TXT TO RATE-CAT.

EXEC SQL

SELECT RATE_CAT

,RATE_PER_HOUR

INTO :RATE-CAT

,:RATE-PER-HOUR

FROM TB_RATE

WHERE RATE_CAT = :RATE-CAT

END-EXEC.

EVALUATE SQLCODE

WHEN 0

PERFORM 1000-DISPLAY-RATE

THRU 1000-EXIT

WHEN +100

PERFORM 2000-ROW-NOT-FOUND

THRU 2000-EXIT

WHEN OTHER

MOVE SQLCODE TO WS-SQLCODE

MOVE 'TB_RATE' TO WS-TABLE

MOVE '0000-MAIN-PARA' TO WS-PARA

PERFORM 9999-DB2-ERROR-ROUTINE

THRU 9999-EXIT

END-EVALUATE.

STOP RUN.

1000-DISPLAY-RATE.

DISPLAY '-----------------------------------------------'.

DISPLAY 'RATE CATEGORY: ' RATE-CAT.

DISPLAY 'RATE PER HOUR: ' RATE-PER-HOUR.

DISPLAY '-----------------------------------------------'.

1000-EXIT.

EXIT.

2000-ROW-NOT-FOUND.

DISPLAY '------------------------------------------------'.

DISPLAY 'ROW NOT FOUND FOR THE RATE CATEGORY: ' RATE-CAT.


C3: Protected

Handout: DB2

DISPLAY '------------------------------------------------'.

2000-EXIT.

EXIT.

9999-DB2-ERROR-ROUTINE.

DISPLAY '-----------------------------------------------'.

DISPLAY 'ERROR DETECTED'.

DISPLAY WS-ERROR-MESSAGE.

DISPLAY '-----------------------------------------------'.

9999-EXIT.

EXIT.

Refer File Name: First_RatePerHour_Program_Session#21_Slide#12 to obtain soft copy of the program code

Summary

While developing COBOL DB2 application program, you need to perform the following tasks: 1. Embed the SQL statements and delimit them with EXEC SQL and END-EXEC 2. Include DCLGEN output for the tables used in the program in the WORKING-STORAGE

section, which: i. Explicitly declares the table ii. Defines the host structure

3. Include SQLCA in the WORKING-STORAGE section 4. Check SQLCODE field in SQLCA after executing an SQL statement


1. What is ESQL (Embedded SQL)? 2. What is a DCLGEN? 3. What is a host variable? 4. What is SQLCA? 5. What is SQLCODE?

Exercises

Develop a COBOL-DB2 application program which accepts “Patient Number” and displays Patient Information as follows:

Patient Number: xxxx Patient Name: <First name> <Last name> Gender: <x> Date of Birth: <DD/MM/YYYY>


C3: Protected

Handout: DB2

Session 26: Program Preparation and Execution

Learning Objectives

After completing this session, you will be able to: Develop a COBOL DB2 application program Execute a COBOL DB2 application program

Steps involved in Program Preparation

Following are the steps involved in preparing a COBOL-DB2 application program: o Precompilation o Bind o Compilation o Link Edit

Need for Precompilation

In early days, many companies had different machines for development and production. Development often took place on an older model machine and COBOL was the language of choice. The LOAD modules were moved onto a bigger production machine and companies rarely had a COBOL license on the production machine. So, DB2 had to allow development on one box with a COBOL compiler but without a DB2 subsystem and allow production runs on a different box with a DB2 subsystem but without a COBOL compiler. So programmers wrote COBOL programs and embed SQL and during compilation, to look for COBOL errors, they required a system to strip out the SQL, leaving only COBOL and that system is Precompiler.

Tasks of Precompiler

Expansion of “INCLUDE”: If the delimiters are surrounded an INCLUDE statement, the Precompiler goes to the INCLUDE library named in the job control language data definition statement and pulls the included MEMBERNAME into the program. This function is the same as a COBOL COPY MEMBERNAME, but the timing is different. COBOL Copybooks get copied in at COMPILE time; DB2 INCLUDEs get copied in at precompile time.

Syntax Check: If the delimiters surround an SQL statement, the precompiler does a very basic syntax check to make sure that the column and table names are valid. The Precompiler uses the top part of the DCLGEN (Table Declaration) to validate the SQL syntax. So Precompiler does not need DB2 to run.

Splitting the Program: Most important task performed by the DB2 Precompiler is to split the program into two parts: a COBOL part and a DB2 part. All of the SQL that are embedded is stripped out of the program and put into its own partitioned data set member, called a DBRM (Data Base Request Module).


C3: Protected

Handout: DB2

A single program containing two languages, COBOL and SQL, goes into the DB2 Precompiler and two pieces come out.

“Modified Source Code” which is the COBOL with all of the SQL commented out and replaced with the equivalent COBOL Calls.

“DBRM” which contains only SQL

As the “Modified Source Code” and “DBRM” will take different paths to get the runtime executables, in order to identify the correct pair during execution, the precompiler attaches timestamp both in “Modified Source Code” and in “DBRM” and is called “Consistency Token”. Following figure shows the functionality of Precompiler:

In the JCL, the Precompilation step is as follows: //**********************************************************************

//* DB2 PRECOMPILE THE COBOL PROGRAM *

//**********************************************************************

//DB2PCOMP EXEC PGM=DSNHPC,

// PARM='HOST(IBMCOB),XREF,SOURCE,FLAG(I),APOST,NEWFUN(NO)'

//STEPLIB DD DISP=SHR,DSN=DSN810.SDSNLOAD

//DBRMLIB DD DISP=SHR,DSN=&DBRMLIB(&LOADMEM)

//SYSCIN DD DSN=&&DSNHOUT,DISP=(NEW,PASS,DELETE),UNIT=SYSDA,

// SPACE=(800,(500,500))

//SYSLIB DD DISP=SHR,DSN=&INCLUDE

// DD DISP=SHR,DSN=&COBCOPY

//SYSPRINT DD SYSOUT=*

//SYSTERM DD SYSOUT=*


C3: Protected

Handout: DB2

//SYSUDUMP DD SYSOUT=*

//SYSUT1 DD SPACE=(800,(500,500),,,ROUND),UNIT=SYSDA


//SYSIN DD DISP=SHR,DSN=&SOURCE(&MEMNAME)

In the JCL, for the Precompilation we need to provide the following items. o Input:

SYSIN: COBOL-DB2 application program (member name with the PDS) SYSLIB: DCLGEN PDS name

o Output: DBRMLIB: DBRM member name with the PDS. SYSCIN: Modified source code. (Generally this has the temporary dataset which will be passed to the compilation step).

Bind

Tasks of Bind

Authorization Check: DB2 must make sure that the programmer has the BIND authority and the SQL authority to perform the requested SQL task. Syntax Check: BIND task is a bit redundant, like precompile, must also check the syntax of the SQL, but the BIND check is more sophisticated. BIND uses the DB2 CATALOG table information to make sure that the column names are valid, comparisons are numeric-to-numeric, and so on. Optimization: The most important BIND task is to come up with run-time instructions for the SQL in the DBRM. Each SQL statement is parsed and all of the possible methods for retrieving the desired columns and rows from the table are weighed, measured, and evaluated based on possible estimated I/O, CPU, and SORT overhead. After all that input (and more) is weighed and compared, the cheapest, most cost-effective access path is chosen, and the runtime instructions for that one path are created. This process of choosing the optimized access path is called “Optimization”. This is repeated for each SQL statement in the DBRM. These runtime instructions are stored in the “PLAN”.


C3: Protected

Handout: DB2

Plan

A plan is an executable module containing the access path logic produced by the DB2 optimizer. It can be composed of one or more DBRMs and packages.

There are two ways of doing BIND: o Bind DBRMs into PLANs o Bind DBRMs into PACKAGEs o

Need of Package

In the early releases of DB2, the DBRM was bound into a PLAN. This method worked just fine as long as the program was a standalone program that is, PGMA was bound to a PLANA. When PGMA needed to CALL PGMB, since only one PLAN could be named in an execute statement, the PLAN had to contain run-time instructions for both PGMA and PGMB. This problem was solved by having the BIND instruction for PLANA consists of a member list; the DBRMs for both PGMA and PGMB were listed as members and if PGMB called PGMC, then the three would be listed as members. Member lists got longer and longer.

Drawbacks of having a very long list: o While binding, authorization check, syntax check, optimized access path and the

creation of run time instructions for the chosen path is carried out. If the PLAN contains one member, PGMA, this process should be quick. But if there are 500 DBRMs in the member list, the BIND could take hours.

o If one of the programs (PGMA) changes in the list of 500 programs, the changed program must be precompiled and precompile changes the consistency token and creates a new DBRM. That new DBRM must be bound into the PLAN. When the PLAN is bound, all 500 DBRMs (not just the modified PGMA) will be rebound. It could take hours to BIND a PLAN, even though 499 of the 500 programs haven't changed.

o The same case that is, you need to bind the entire list if a new program is added to the list or any existing program is removed from the list.

To overcome these disadvantages, package concept came into picture.


C3: Protected

Handout: DB2

Package

A package is a single, bound DBRM with optimized access paths. By using packages, the table access logic is "packaged" at a lower level of granularity, at the program level. To execute a package, you must first 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.

Understanding Plan and Package more clearly

To help differentiate between plans and packages, consider a grocery store analogy. o 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 you pay 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).

o In a package environment, rather than actually removing the items from the shelf, you would mark on your shopping list the location of each item in the store. Upon checking out, you would give the list to the clerk at the counter. The clerk then would place the list in the bag—not the actual items. The plan (bag) contains a list pointing to the physical location of the packages (grocery items) that are still on the shelf. This approach is a good way to compare and contrast the two different environments.

Version

When using packages, you can keep multiple versions of a single package that refer to different versions of the corresponding application program. We can specify a version as a parameter to the DB2 precompiler.

Advantage of Version

The programmer can use a previous incarnation of a program without rebinding. Before the availability of packages, when programmers wanted to use an old version

of a program, they were forced to rebind the program's plan using the correct DBRM. If the DBRM was unavailable, they had to repeat the entire program preparation process.

Advantages of Package

Reduced bind time and bind overhead: 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.

Granularity of bind parameters: With packages, you can specify our bind options at the program level, such as the isolation level and release parameters. By specifying different parameters for specific packages and including these packages into a plan, many combinations of isolation level and release are possible. For example, 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.


C3: Protected

Handout: DB2

Versioning: Packages can be versioned, thus enabling us to have multiple versions of the same package existing at the same time. Simply by running the appropriate load module, DB2 chooses the correct package to execute. DB2 uses a package selection algorithm to execute the correct access path.

Collection

A collection is a user-defined name from 1 to 18 characters that the programmer must specify for every package. A collection is not an actual, physical database object.

Advantages of Collection

By specifying a different collection identifier for a package, the same DBRM can be bound into different packages. This capability permits program developers to use the same program DBRM for different packages, enabling easy access to tables that have the same structure (DDL) but different owners.

You could use collections to separate programs for different application areas, such as payroll and inventory.

In the JCL, the “Bind a DBRM into a Plan” is as follows: //**********************************************************************

//* BIND THE PROGRAM *

//**********************************************************************

//BIND EXEC PGM=IKJEFT01,COND=(4,LT,LINKEDIT)


//DBRMLIB DD DISP=OLD,DSN=&DBRMLIB(&LOADMEM)


//SYSTSPRT DD SYSOUT=*


//**********************************************************************

//* SPECIFY YOUR PLAN NAME WITHIN PLAN PARANTHESIS '()' *

//* SPECIFY YOUR PROGRAM NAME WITHIN MEMBER PARANTHESIS *

//* SPECIFY YOUR USERID WITHIN QUALIFIER PARANTHESIS *

//**********************************************************************

//SYSTSIN DD *

DSN S(DSN1)

BIND PLAN(PLANNAME) MEMBER(PROGRAM) QUALIFIER(USERID) -

ACTION(REP) RETAIN ISOLATION(UR) -

VALIDATE(BIND)

END

/*


C3: Protected

Handout: DB2

In the JCL, for the “Bind a DBRM into a Plan” you need to provide the following items: DBRMLIB: DBRM PDS SYSTSIN:

o DSN S or DSN SYSTEM: DB2 subsystem o PLAN: Name of the plan to be bound o MEMBER: DBRM Member name o QUALIFIER: USERID o ACTION: Add for new plan. If the plan exists, then it will be replaced. Otherwise a

new plan is added.

In the JCL, if you want to bind more than one DBRM into a same plan, specify the DBRM member list in MEMBER as follows: Example: //**********************************************************************




//**********************************************************************

//SYSTSIN DD *

DSN S(DSN1)

BIND PLAN(PLANNAME) MEMBER(PROGRAM1 PROGRAM2 PROGRAM3) QUALIFIER(USERID) -


VALIDATE(BIND)

END

/* In the JCL, if you want to bind a DBRM into a package, specify the PACKAGE name and DBRM member in MEMBER as follows. Example: //**********************************************************************

//* SPECIFY YOUR PACKAGE NAME WITHIN PACKAGE PARANTHESIS '()' *



//**********************************************************************

//SYSTSIN DD *

DSN S(DSN1)

BIND PACKAGE (PACKAGE NAME) MEMBER(PROGRAM) QUALIFIER(USERID) -


C3: Protected

Handout: DB2


VALIDATE(BIND)

END

/*

In the JCL, if you want to bind a list of packages into a plan, specify them in PKLIST as follows: Example: //**********************************************************************

//* SPECIFY YOUR PACKAGE NAME WITHIN PACKAGE PARANTHESIS '()' *



//**********************************************************************

//SYSTSIN DD *

DSN S(DSN1)

BIND PLAN (PLAN NAME) PKLIST(PACKAGE1, PACKAGE2) QUALIFIER(USERID) -


VALIDATE(BIND)

END

/*

Example: A DBRM bind to a plan

//SYSTSIN DD *

DSN SYSTEM(DSNG)

BIND PLAN(Z5938MHD) - (Give Plan Name)

ACT(REP) ISOLATION(CS) -

MEMBER(F5938MHD) - (Give DBRM Name)

OWNER(F5925AP1) -

VALIDATE(BIND) EXPLAIN(NO) -

QUALIFIER(F5925DBA)

END

A list of DBRMs bind to a plan

//SYSTSIN DD *

DSN SYSTEM(DSNG)

BIND PLAN(P5938PB5) - (Give Plan Name)

ACT(REP) ISOLATION(CS) -

MEMBER(F5938PB5 F5938LPL) - (Give DBRM Name)

OWNER(F5925AP1) -

VALIDATE(BIND) EXPLAIN(NO) -


C3: Protected

Handout: DB2

QUALIFIER(F5925DBA)

END

A DBRM bind to a package

DSN SYSTEM(DSNG) (Give Sub System)

BIND PACKAGE(F5938_T_PROV ) - (Give Package Name)

OWNER(F5925AP1) -

QUALIFIER(F5925DBA) -

MEMBER(F5938PPZ) - (Give DBRM Name)

VALIDATE(BIND) -

ISOLATION(CS) -

RELEASE(COMMIT) -

ACTION(REP ) -

END

A DBRM bind to a package with the collection and is bound to a plan.

In order to specify all the packages in the collection, we can specify as F6418_PB_F6418ACR.*

BIND PLAN(F6418PBP) -

OWNER(F6418DB) -

QUALIFIER(F6418DB) -

PKLIST(F6418_PB_F6418ACR.F6418ACR, - (Collection ID: F6418_PB_F6418ACR)

F6418_PB_F6418BA1.F6418BA1) -

ACT(REP) -

ISOLATION(CS) -

ACQUIRE(USE) -

RELEASE(COMMIT) -

VALIDATE(BIND)

============================================================

BIND PACKAGE (F6418_PB_F6418ACR.F6418ACR) -

ACT(ADD) -

ISOLATION(CS) -

QUALIFIER(F6418DB) -

OWNER(F6418DB) -

MEMBER(F641803T) -

RELEASE(COMMIT) -

VALIDATE(BIND)


C3: Protected

Handout: DB2

Packages and Plans Storage

Actual Plans and Packages are stored in DB2 Directory. Information about the Plans and the Packages are stored in the DB2 catalog.

Compile

In the JCL, the compilation for the COBOL is as follows: //**********************************************************************

//* COBOL COMPILE *

//**********************************************************************

//COBCOMP EXEC PGM=IGYCRCTL,COND=(4,LT,DB2PCOMP),

// PARM='LIB,XREF,OFFSET,MAP,RENT,RES,NODYNAM,TEST'

//SYSIN DD DSN=&&DSNHOUT,DISP=(OLD,DELETE)

//SYSLIB DD DSN=&COBCOPY,DISP=SHR

//SYSLIN DD DSN=&&LOADSET,DISP=(MOD,PASS),UNIT=SYSDA,

// SPACE=(800,(500,500))









C3: Protected

Handout: DB2



In the JCL, for compilation you need to provide the following items:

SYSIN: Modified source code SYSLIB: COBOL Copybook PDS SYSLIN: Object Module that Is generally specified as a temporary dataset

Link Edit

In the JCL, the link edit for the COBOL is as follows: //**********************************************************************

//* LINK EDIT THE PROGRAM *

//**********************************************************************

//LINKEDIT EXEC PGM=IEWL,COND=(4,LT,COBCOMP),

// PARM='MAP,LIST,XREF,LET,AMODE=31,RMODE=ANY,RENT,REUS'

//SYSLIB DD DISP=SHR,DSN=DSN810.SDSNLOAD

// DD DISP=SHR,DSN=CEE.SCEELKED

// DD DISP=SHR,DSN=CEE.SCEERUN

// DD DISP=SHR,DSN=ISP.SISPLOAD

// DD DISP=SHR,DSN=&LOADLIB

//SYSLIN DD DSN=&&LOADSET,DISP=(OLD,DELETE)

//SYSLMOD DD DISP=SHR,DSN=&LOADLIB(&LOADMEM)



//SYSUT1 DD SPACE=(1024,(50,50)),UNIT=SYSDA


C3: Protected

Handout: DB2

In the JCL, for link edit you need to provide the following items: SYSLIN: Object Module SYSLMOD: Load module member name with the PDS

Execution

At run time, the load module starts up and hits a paragraph containing a CALL to DB2. This CALL contains information such as a description of the consistency token, the content of the SQL host variables, and so on. The CALL invokes the COBOL-DB2 interface program, which connects to DB2 and finds the corresponding plan (or package) with the consistency token and the execution takes place. If there is no correct plan or package with the matching timestamp anywhere in DB2, then you get -805 or -818 error code. The JCL for execution is as follows: //COBDB2RN EXEC PGM=IKJEFT01,DYNAMNBR=20

//STEPLIB DD DSN=THYD018.DB2.LOADLIB,DISP=SHR Load Library name

// DD DSN=CEE.SCEERUN,DISP=SHR

// DD DSN=DSN810.SDSNLOAD,DISP=SHR

//DBRMLIB DD DSN=THYD018.DB2.DBRMLIB,DISP=SHR DBRM Name



//SYSTSIN DD *

DSN SYSTEM(DSN1) Subsystem name

RUN PROGRAM(FIRSTCD)- Load module name

PLAN(THYPL018) - Plan name

END

/*


C3: Protected

Handout: DB2

Try It Out

Problem Statement: Prepare and execute the program which you have created in Session # 21 (COBOL DB2 application program, to get the hourly rate for a particular rate category supplied by the user). Code: Program Preparation: //THYD018C JOB MSGCLASS=X,MSGLEVEL=(1,1),CLASS=B,

// REGION=5M,NOTIFY=&SYSUID

//*

//**********************************************************************

//* INPUT AREA *

//**********************************************************************

// SET MEMNAME=FIRSTCD <- PROGRAM NAME

// SET LOADMEM=FIRSTCD <- LOAD MODULE NAME

// SET DBRMLIB=THYD018.DB2.DBRMLIB <- DBRM LIBRARY

// SET INCLUDE=THYD018.DCLGEN.COPYLIB <- DB2 DCLGEN

// SET COBCOPY=THYD018.DB2.COPYLIB <- COBOL COPYBOOK

// SET LOADLIB=THYD018.DB2.LOADLIB <- LOAD LIBRARY

// SET SOURCE=THYD018.DB2.SRCLIB <- COBOL SOURCE

//**********************************************************************


C3: Protected

Handout: DB2

//* DB2 PRECOMPILE THE COBOL PROGRAM *

//**********************************************************************

//DB2PCOMP EXEC PGM=DSNHPC,

// PARM='HOST(IBMCOB),XREF,SOURCE,FLAG(I),APOST,NEWFUN(NO)'


//DBRMLIB DD DISP=SHR,DSN=&DBRMLIB(&LOADMEM)

//SYSCIN DD DSN=&&DSNHOUT,DISP=(NEW,PASS,DELETE),UNIT=SYSDA,

// SPACE=(800,(500,500))

//SYSLIB DD DISP=SHR,DSN=&INCLUDE

// DD DISP=SHR,DSN=&COBCOPY


//SYSTERM DD SYSOUT=*




//SYSIN DD DISP=SHR,DSN=&SOURCE(&MEMNAME)

//**********************************************************************

//* COBOL COMPILE *

//**********************************************************************

//COBCOMP EXEC PGM=IGYCRCTL,COND=(4,LT,DB2PCOMP),

// PARM='LIB,XREF,OFFSET,MAP,RENT,RES,NODYNAM,TEST'

//SYSIN DD DSN=&&DSNHOUT,DISP=(OLD,DELETE)

//SYSLIB DD DSN=&COBCOPY,DISP=SHR

//SYSLIN DD DSN=&&LOADSET,DISP=(MOD,PASS),UNIT=SYSDA,

// SPACE=(800,(500,500))










//**********************************************************************

//* LINK EDIT THE PROGRAM *

//**********************************************************************

//LINKEDIT EXEC PGM=IEWL,COND=(4,LT,COBCOMP),

// PARM='MAP,LIST,XREF,LET,AMODE=31,RMODE=ANY,RENT,REUS'

//SYSLIB DD DISP=SHR,DSN=DSN810.SDSNLOAD

// DD DISP=SHR,DSN=CEE.SCEELKED

// DD DISP=SHR,DSN=CEE.SCEERUN

// DD DISP=SHR,DSN=ISP.SISPLOAD

// DD DISP=SHR,DSN=&LOADLIB

//SYSLIN DD DSN=&&LOADSET,DISP=(OLD,DELETE)


C3: Protected

Handout: DB2

//SYSLMOD DD DISP=SHR,DSN=&LOADLIB(&LOADMEM)



//SYSUT1 DD SPACE=(1024,(50,50)),UNIT=SYSDA

//**********************************************************************

//* BIND THE PROGRAM *

//**********************************************************************

//BIND EXEC PGM=IKJEFT01,COND=(4,LT,LINKEDIT)


//DBRMLIB DD DISP=OLD,DSN=&DBRMLIB(&LOADMEM)




//**********************************************************************




//**********************************************************************

//SYSTSIN DD *

DSN S(DSN1)

BIND PLAN(THYPL018) MEMBER(FIRSTCD) QUALIFIER(THYD018) -


VALIDATE(BIND)

END

/*

//

Program Execution: //THYD018R JOB (ACCT#),'PGM STR',MSGCLASS=X,CLASS=A,

// REGION=5M,NOTIFY=&SYSUID

//COBDB2RN EXEC PGM=IKJEFT01,DYNAMNBR=20

//STEPLIB DD DSN=THYD018.DB2.LOADLIB,DISP=SHR

// DD DSN=CEE.SCEERUN,DISP=SHR

// DD DSN=DSN810.SDSNLOAD,DISP=SHR

//DBRMLIB DD DSN=THYD018.DB2.DBRMLIB,DISP=SHR



//SYSTSIN DD *

DSN SYSTEM(DSN1)

RUN PROGRAM(FIRSTCD)-

PLAN(THYPL018) -

PARM('A')

END

/*


C3: Protected

Handout: DB2

Refer File Name: ProgramPreparation_FIRSTCD_Session#27_Slide#7& ProgramExecution_FIRSTCD_Session#27_Slide#12 to obtain soft copy of the program code

Summary

The following figure summarizes the program preparation and execution of a COBOL-DB2 application program:

The developed COBOL-DB2 source program is precompiled to get the COBOL portion

of “Modified Source Code” and DB2 portion of “Database Request Module (DBRM)”. A “Consistency Token” is created both in modified source code and in DBRM.

“Modified Source Code” is compiled to get “Object Module”. “Object Module” is link edited to get “Load Module” which is the runtime executable of

COBOL portion. DBRM is bound either to a package and then to a plan or directly to a plan to get the

runtime executable of DB2 portion. Actual plan/package is stored in DB2 Directory. Information about the plan/package is stored in DB2 Catalog. During execution, when the load module encounters the DB2 call, the corresponding

plan is retrieved using the consistency token which is created during the precompilation and the execution takes place.


C3: Protected

Handout: DB2


1. What is the need for Precompilation? 2. Explain the tasks involved in Precompilation. 3. Explain the tasks involved in Bind. 4. What is a plan? 5. What is a package? 6. What is a version? 7. What is a collection? 8. What are the advantages of package over the plan? 9. What happens during the execution of COBOL-DB2 application program?

Exercises

Prepare and execute the COBOL-DB2 application program which you have developed in the previous session which is as follows: COBOL-DB2 application program which accepts “Patient Number” and displays Patient Information as follows:

Patient Number: xxxx Patient Name: <First name> <Last name> Gender: <x> Date of Birth: <DD/MM/YYYY>


C3: Protected

Handout: DB2

Session 31: Error Handling Session 31: Error Handling

Learning Objectives Learning Objectives

After completing the session, you will be able to: Debug errors in a COBOL-DB2 application program through several ways in addition

to SQLCODE check

Error Handling - Introduction

To facilitate error processing, DB2 provides: SQL Communication Area (SQLCA) A Subprogram DSNTIAR WHENEVER statement

SQLCA

SQLCA holds the information about the execution of the embedded SQL statements. SQLCODE in SQLCA contains the return code which provides information about the execution of the last SQL statement. In addition to SQLCODE, you have some other fields in SQLCA which are also useful while processing the COBOL-DB2 application programs. 01 SQLCA.

05 SQLCAID PIC X(8).

05 SQLCABC PIC S9(9) COMP-4.

05 SQLCODE PIC S9(9) COMP-4.

05 SQLERRM.

49 SQLERRML PIC S9(4) COMP-4.

49 SQLERRMC PIC X(70).

05 SQLERRP PIC X(8).

05 SQLERRD OCCURS 6 TIMES

PIC S9(9) COMP-4.

05 SQLWARN.

10 SQLWARN0 PIC X.

10 SQLWARN1 PIC X.

10 SQLWARN2 PIC X.

10 SQLWARN3 PIC X.

10 SQLWARN4 PIC X.

10 SQLWARN5 PIC X.

10 SQLWARN6 PIC X.

10 SQLWARN7 PIC X.

05 SQLEXT.

10 SQLWARN8 PIC X.

10 SQLWARN9 PIC X.

10 SQLWARNA PIC X.


C3: Protected

Handout: DB2

10 SQLSTATE PIC X(5).

The following table gives the description about the useful fields which are highlighted:

Field Description SQLCODE SQL Return Code indicating the status of the most recent SQL statement. This field is

unique to DB2 for MVS.

SQLERRD(3) Number of rows affected by an INSERT, UPDATE or DELETE statement

SQLWARN0 Contains W if any other SQLWARN field contains W

SQLWARN1 Contains W if a string was truncated when stored in a host variable

SQLWARN2 Contains W if null values were excluded during the processing of a column function

SQLWARN3 Contains W if the number of columns and host variables do not match

SQLWARN6 Contains W if an arithmetic operation produces an unusual date or timestamp. For example, if 4 months are added to 1997-01-31, the result is 1997-04-31. As April does not have 31 days, the results are converted to 1997-04-30.

SQLSTATE Contains a return code indicating the status of the most recent SQL statement. This field can be used across DB2 platforms (DB2 for MVS, OS/2, Windows NT)

DSNTIAR

DSNTIAR is an “Error Reporting Routine” supplied by IBM for DB2. This program takes error data, adds explanatory text and presents it in a more user friendly format. You can call DSNTIAR from a COBOL-DB2 application program to display a formatted error message. You have to pass three parameters while calling DSNTIAR routine.

Name of the SQL Communication Area Name of the working storage area where the routine will put the formatted error

message text Length of the text lines (must be between 72 and 240)

Example: WORKING-STORAGE SECTION.

01 WS-DB2-ERR-MESSAGE.

05 WS-DB2-ERR-MESG-LEN PIC S9(04) COMP VALUE +800.

05 WS-DB2-ERR-MESG-TEXT PIC X(80) OCCURS 10 TIMES INDEXED BY WS-DB2-ERRMSG-IDX.

01 WS-DB2-ERRMESG-LINE-LEN PIC S9(09) COMP VALUE +80.

As DSNTIAR returns a variable length message, the second parameter should contain:

Length Component Data Component


C3: Protected

Handout: DB2

Logic behind the numbers: Length of each line as set by the third parameter 80 Number of lines for the message 10 So the total length of the data component 800

Call statement in the Procedure Division DSNTIAR routine should be called as follows: CALL ‘DSNTIAR’ USING SQLCA

WS-DB2-ERR-MESSAGE

WS-DB2-ERRMESG-LINE-LEN.

DSNTIAR return codes Following is the list of return codes after calling DSTIAR:

Code Meaning

0 Successful execution

4 More data was available than could fit into the provided message area

8 The logical record length was not between 72 and 240 inclusive

12 The message area was not large enough, or the message length was 240 or greater

16 Error in TSO message routine

20 Module DSNTIA1 could not be loaded

24 SQLCA data error

WHENEVER

SQL has an error trapping statement called WHENEVER that you can embed in an application program. When the WHENEVER statement is processed, it applies to all subsequent SQL statements issued by the application program in which it is embedded. WHENEVER directs processing to continue or to branch to an error handling routine based on the SQLCODE returned for the statement. The syntax is as follows: EXEC SQL

WHENEVER {SQLERROR | SQLWARNING | NOT FOUND}

{ {GOTO | GO TO} paragraph-name | CONTINUE}

END-EXEC.


C3: Protected

Handout: DB2

The following table gives the meaning of the keywords used in WHENEVER:

Keyword Meaning SQLERROR The SQLCODE is negative

SQLWARNING The SQLCODE is positive but not +100 or SQLWARN0 equal to W

NOT FOUND The SQLCODE is equal to +100

GOTO or GO TO Branch to the paragraph name that follows

CONTINUE Continue with the statement that follows the SQL statement that caused the error condition

Avoid using the WHENEVER statement. It is almost always safer to code specific SQLCODE checks after each SQL statement and process accordingly. Additionally, you should avoid coding the GO TO verb as used by the WHENEVER statement. The GO TO construct is generally avoided in structured application programming methodologies. Example: EXEC SQL

WHENEVER NOT FOUND

CONTINUE

END-EXEC.

EXEC SQL

WHENEVER SQLWARNING

GO TO ERROR-PARAGRAPH

END-EXEC.

Try It Out

Problem Statement: Create a program which tries to insert the following row to TB_RATE table. As this row already exists in TB_RATE, the INSERT should give error. This error message needs to be formatted through DSNTIAR.

RATE_CATE RATE_PER_HOUR

D 50

Code: IDENTIFICATION DIVISION.

PROGRAM-ID. ERRORHAN.


DATA DIVISION.


******************************************************************


******************************************************************



C3: Protected

Handout: DB2







******************************************************************

* PARAMETERS FOR DSNTIAR

******************************************************************



05 WS-DB2-ERR-MESG-TEXT PIC X(80) OCCURS 10 TIMES

INDEXED BY WS-DB2-ERRMSG-IDX.

*


******************************************************************

* INCLUDE DCLGEN

******************************************************************

EXEC SQL

INCLUDE DRATE

END-EXEC.

******************************************************************

* INCLUDE SQLCA

******************************************************************

EXEC SQL

INCLUDE SQLCA

END-EXEC.

******************************************************************

* COBOL-DB2 PROGRAM WHICH SHOWS HOW TO HANDLE ERRORS BY USING

* DSNTIAR.

* THIS PROGRAM TRIES TO INSERT A ROW INTO TB_RATE TABLE WHICH

* ALREADY EXISTS IN THE TABLE.

******************************************************************

PROCEDURE DIVISION.

0000-MAIN-PARA.

PERFORM 1000-INSERT-PARA

THRU 1000-EXIT.

STOP RUN.

1000-INSERT-PARA.

MOVE 'D' TO RATE-CAT.

MOVE 50 TO RATE-PER-HOUR.

EXEC SQL

INSERT INTO TB_RATE

VALUES (:RATE-CAT

,:RATE-PER-HOUR)


C3: Protected

Handout: DB2

END-EXEC.

EVALUATE SQLCODE

WHEN 0

DISPLAY 'INSERT SUCCESSFUL FOR RATE CAT :' RATE-CAT

WHEN OTHER



MOVE '1000-INSERT-PARA' TO WS-PARA


THRU 9999-EXIT

END-EVALUATE.

1000-EXIT.

EXIT.


DISPLAY '-----------------------------------------------'.



DISPLAY '-----------------------------------------------'.

CALL 'DSNTIAR' USING SQLCA

WS-DB2-ERR-MESSAGE


IF RETURN-CODE = 0

PERFORM

VARYING WS-DB2-ERRMSG-IDX

FROM 1

BY 1

UNTIL WS-DB2-ERRMSG-IDX > 10

DISPLAY WS-DB2-ERR-MESG-TEXT(WS-DB2-ERRMSG-IDX)

END-PERFORM

ELSE

DISPLAY 'DSNTIAR ERROR - RETURN CODE: ' RETURN-CODE

END-IF.

EXEC SQL

ROLLBACK

END-EXEC.

9999-EXIT.

EXIT.

Refer File Name: ErrorHandling_Program_ERRORHAN_Session#31_Slide#7 to obtain soft copy of the program code


C3: Protected

Handout: DB2

Summary

To facilitate error processing, DB2 provides the following: SQL Communication Area (SQLCA) A Subprogram DSNTIAR WHENEVER statement


1. Explain about the useful fields in SQLCA. 2. Explain about DSNTIAR. 3. Explain about WHENEVER statement.

Exercises

Try to delete the patient number “A113” from the patient table and capture the formatted error message using DSNTIAR.


C3: Protected

Handout: DB2

Session 33: Commit and Rollback

Learning Objectives

After completing the session, you will be able to: Store the updated data of the database in the disk

COMMIT

When a program issues an INSERT, UPDATE, or DELETE statement, DB2 does not immediately write the table modification to disk. It logs the changes in a dataset and keeps track of the changes in virtual storage buffers. When it reaches the commit point it writes the logged changes to the disk. Types of Commit:

Implicit Commit Explicit Commit

Implicit Commit: This occurs when a program terminates normally by reaching a STOP or GOBACK statement. Explicit Commit This occurs when a program issues an SQL COMMIT statement. COMMIT statement should be issued in a program as follows: EXEC SQL

COMMIT

END-EXEC

Unit of Work or Unit of Recovery: This consists of the transactions that are logged between two commit points:

If the program does not include any COMMIT statements, none of the transactions are committed until the program terminates normally. This can seriously degrade the performance. So a program which deals with huge volumes of data should issue a COMMIT statement whenever a unit of recovery reaches an appropriate size.

You need to issue explicit commit when a resubmit of the failing program causes reprocessing of all the records.

You need to issue explicit commit in such a way that to achieve data integrity: o Issuing a DB2 COMMIT saves the updates done during a unit of work. o For Example, suppose you have an application that involved update of two tables

that are related to each other. Suppose the update of table is committed and the program abends before committing the UPDATE of the other. The data in the two tables will no longer be synchronous. To achieve data integrity, you must issue a COMMIT only when the processing reaches a logical end.


C3: Protected

Handout: DB2

Check point – Restart Logic: COBOL-DB2 application program which deals with large volumes of data should

include check point - restart logic which will minimize the impact to DB2 resources as well as the allotted batch processing window in the event of an application failure.

Check point – Restart logic in the program will basically stores the information about the last committed values so that during the application failure, you can restart the processing from the point of last committed row and not from the beginning.

Rollback

DB2 rolls back (or reverses) all of the transactions in the unit of recovery when a program terminates abnormally or when a program issues a ROLLBACK statement.

A ROLLBACK can be issued in the program as follows:

EXEC SQL

ROLLBACK

END-EXEC.

Try It Out

Problem Statement: Create a program which inserts the following row to TB_RATE table. Once the insert is successful the inserted row should be explicitly committed.

RATE_CATE RATE_PER_HOUR

F 20


PROGRAM-ID. COMTRLBK.


DATA DIVISION.


******************************************************************


******************************************************************








******************************************************************


******************************************************************


C3: Protected

Handout: DB2





*


******************************************************************

* INCLUDE DCLGEN

******************************************************************

EXEC SQL

INCLUDE DRATE

END-EXEC.

******************************************************************

* INCLUDE SQLCA

******************************************************************

EXEC SQL

INCLUDE SQLCA

END-EXEC.

******************************************************************

* COBOL-DB2 PROGRAM WHICH SHOWS HOW TO USE COMMIT AND ROLLBACK

******************************************************************

PROCEDURE DIVISION.

0000-MAIN-PARA.


THRU 1000-EXIT.

STOP RUN.

1000-INSERT-PARA.

MOVE 'F' TO RATE-CAT.

MOVE 20 TO RATE-PER-HOUR.

EXEC SQL

INSERT INTO TB_RATE

VALUES (:RATE-CAT

,:RATE-PER-HOUR)

END-EXEC.

EVALUATE SQLCODE

WHEN 0

PERFORM 1100-COMMIT-PARA

THRU 1100-EXIT

WHEN OTHER





THRU 9999-EXIT

END-EVALUATE.


C3: Protected

Handout: DB2

1000-EXIT.

EXIT.

1100-COMMIT-PARA.

EXEC SQL

COMMIT

END-EXEC

EVALUATE SQLCODE

WHEN 0

DISPLAY 'SUCCESSFULLY COMMITTED - RATE CAT: ' RATE-CAT

WHEN OTHER



MOVE '1100-COMMIT-PARA' TO WS-PARA


THRU 9999-EXIT

END-EVALUATE.

1100-EXIT.

EXIT.


DISPLAY '-----------------------------------------------'.



DISPLAY '-----------------------------------------------'.


WS-DB2-ERR-MESSAGE


IF RETURN-CODE = 0

PERFORM


FROM 1

BY 1



END-PERFORM

ELSE


END-IF.

EXEC SQL

ROLLBACK

END-EXEC.

9999-EXIT.

EXIT.

Refer File Name: CommitRollback_Program_COMTRLBK_Session#33_Slide#7 to obtain soft copy of the program code.


C3: Protected

Handout: DB2

Summary

Commit saves the updates done during the unit of work. Rollback reverses the updates done during the unit of work.


1. Explain about the COMMIT statement. 2. Explain about the ROLLBACK statement.


C3: Protected

Handout: DB2

Session 35: Cursor

Learning Objectives

After completing the session, you will be able to: Identify data with multiple rows

Cursor - Introduction

COBOL operates on data a row at a time; SQL operates on data a set at time. You have to use cursors to process a result table that contains more than one row in a COBOL program. If multiple rows are returned by a SELECT statement not coded using a cursor, then DB2 returns a -811 SQLCODE. A cursor is a pointer that identifies the current row in a result table. As a programmer:

You declare a cursor and define an SQL statement for that cursor. After that, you can use the cursor in much the same manner as a sequential file. The

cursor is opened, rows are fetched from the cursor one row at a time and then the cursor is closed.

Cursor Processing

SQL statements used for Cursor processing and their COBOL equivalent file processing statements are as follows:

SQL Statement Description COBOL equivalent for File Processing

DECLARE CURSOR Defines a result table and names a cursor for it.

None

Open <cursor-name> Creates the result table and positions the cursor before the first row in the table

OPEN <file-name>

FETCH <cursor-name> Fetches the next row from the result table READ <file-name>

CLOSE <cursor-name> Close the result table CLOSE <file-name>


C3: Protected

Handout: DB2

Cursor Declaration

The DECLARE cursor syntax is as follows. EXEC SQL

DECLARE <cursor-name> CURSOR [WITH HOLD] FOR

<SQL Select clause>

[FOR UPDATE OF <update-column1, update-column2, …>]

END-EXEC.

The DECLARE cursor defines the cursor, gives it a name unique to the program in which it is embedded, and assigns an SQL statement to the cursor name. The DECLARE statement does not execute the SQL statement; it merely defines the SQL statement. You can code the DECLARE statement in the Working-Storage Section or in the Procedure Division, as long as it appears before any other statements that refer to the cursor. As it is a declarative statement and not an action statement, it is advisable to keep it in Working-Storage Section WITH HOLD When there is an explicit COMMIT statement in the COBOL program while processing the cursor, the commit will automatically close the cursor. But if you need your cursor to be opened even after the explicit commit, you need to declare the cursor with “WITH HOLD” which prevents the cursor from being closed as a result of the explicit commit.

Cursor Open

OPEN is an executable statement. It executes the SQL statement, and builds the result table specified by the DECLARE CURSOR statement and positions the cursor before the first row. The syntax is as follows: EXEC SQL

OPEN <cursor-name>

END-EXEC

Cursor Fetch

The FETCH syntax is as follows EXEC SQL

FETCH <cursor-name>

INTO :<host-variable1>,

:< host-variable2>,….

END-EXEC

The INTO clause specifies either the list of host variables or host structure where a row in the result table is stored in the COBOL program. When a FETCH statement is executed DB2 advances the cursor one row in the result table. Then, it moves the column data from the current row into the COBOL host variables. A FETCH statement is typically coded in a loop that reads and processes each row in succession until there are no more rows in the result table. When there are no more rows in the result table and a FETCH statement is executed, DB2 places a value of +100 in the SQLCODE field. So the program can test for this condition for terminating the loop.


C3: Protected

Handout: DB2

Cursor Close

The CLOSE syntax is as follows: EXEC SQL

CLOSE <cursor-name>

END-EXEC

During CLOSE, DB2 releases all resources used by the cursor. DB2 closes the entire cursor-controlled result table when a program ends and while executing the explicit COMMIT.

Using Cursor for Data Modification

UPDATE and DELETE SQL statements, like the SELECT statement, operate on data a set at a time. To first read the data before modifying it, you declare the cursor with a special FOR UPDATE OF clause. In the UPDATE or DELETE statement, we need to use WHERE CURRENT OF. Example: EXEC SQL

DECLARE CS-C1 CURSOR FOR

SELECT DEPT_NO, DEPT_MGRNO

FROM TB_DEPT

WHERE DEPT_ADMRDEPT = :DEPT-ADMRDEPT

FOR UPDATE OF DEPT_MGRNO

END-EXEC.

The corresponding UPDATE statement is as follows. EXEC SQL

FETCH CS-C1

INTO :DEPT-NO, :DEPT-NAME, :DEPT-MGRNO

END-EXEC.

IF SQLCODE = 0

EXEC SQL

UPDATE TB_DEPT

SET DEPT_MGRNO = '000060'

WHERE CURRENT OF CS-C1

END-EXEC

ELSE

….

“FOR UPDATE OF” clause ensures data integrity. This causes a lock to be taken on the data page when it is fetched, ensuring that no other process can modify the data before our program processes it. If the program simply FETCHs without the FOR UPDATE OF specification and then issues an SQL statement to modify the data, another process can modify the data in between, thereby invalidating our program's modification, overwriting our program's modification or both.


C3: Protected

Handout: DB2

Try It Out

Problem Statement: Create a program which displays all the rows of TB_RATE table. Code: IDENTIFICATION DIVISION.

PROGRAM-ID. CURSORPG.


DATA DIVISION.


******************************************************************


******************************************************************








******************************************************************


******************************************************************





*


******************************************************************

* SWITCH

******************************************************************

01 WS-AT-END-SW PIC X(1).

88 WS-NOT-AT-END VALUE 'N'.

88 WS-AT-END VALUE 'Y'.

******************************************************************

* INCLUDE DCLGEN

******************************************************************

EXEC SQL

INCLUDE DRATE

END-EXEC.

******************************************************************

* INCLUDE SQLCA

******************************************************************


C3: Protected

Handout: DB2

EXEC SQL

INCLUDE SQLCA

END-EXEC.

******************************************************************

* DECLARE CURSOR

******************************************************************

EXEC SQL

DECLARE CS-RATE CURSOR FOR

SELECT *

FROM TB_RATE

END-EXEC.

******************************************************************

* COBOL-DB2 PROGRAM WHICH SHOWS HOW TO RETRIEVE ALL THE ROWS FROM

* TB_RATE TABLE USING CURSOR TO SHOW PROCESSING WITH CURSOR.

******************************************************************

PROCEDURE DIVISION.

0000-MAIN-PARA.

PERFORM 1000-OPEN-PARA

THRU 1000-EXIT.

PERFORM 2000-PROCESS-PARA

THRU 2000-EXIT.

PERFORM 3000-CLOSE-PARA

THRU 3000-EXIT.

STOP RUN.

1000-OPEN-PARA.

EXEC SQL

OPEN CS-RATE

END-EXEC.

EVALUATE SQLCODE

WHEN 0

SET WS-NOT-AT-END TO TRUE

WHEN OTHER



MOVE '1000-OPEN-PARA' TO WS-PARA


THRU 9999-EXIT

END-EVALUATE.

1000-EXIT.

EXIT.

2000-PROCESS-PARA.

PERFORM 2100-FETCH-PARA

THRU 2100-EXIT

UNTIL WS-AT-END.

2000-EXIT.


C3: Protected

Handout: DB2

EXIT.

2100-FETCH-PARA.

EXEC SQL

FETCH CS-RATE

INTO :RATE-CAT

,:RATE-PER-HOUR

END-EXEC.

EVALUATE SQLCODE

WHEN 0

DISPLAY 'RATE CATEGORY: ' RATE-CAT

DISPLAY 'RATE PER HOUR: ' RATE-PER-HOUR

DISPLAY '**********************************************'

WHEN +100

SET WS-AT-END TO TRUE

WHEN OTHER



MOVE '2100-FETCH-PARA' TO WS-PARA


THRU 9999-EXIT

END-EVALUATE.

2100-EXIT.

EXIT.

3000-CLOSE-PARA.

EXEC SQL

CLOSE CS-RATE

END-EXEC.

EVALUATE SQLCODE

WHEN 0

SET WS-NOT-AT-END TO TRUE

WHEN OTHER



MOVE '3000-CLOSE-PARA' TO WS-PARA


THRU 9999-EXIT

END-EVALUATE.

3000-EXIT.

EXIT.


DISPLAY '-----------------------------------------------'.



DISPLAY '-----------------------------------------------'.



C3: Protected

Handout: DB2

WS-DB2-ERR-MESSAGE


IF RETURN-CODE = 0

PERFORM


FROM 1

BY 1



END-PERFORM

ELSE


END-IF.

EXEC SQL

ROLLBACK

END-EXEC.

9999-EXIT.

EXIT.

Refer File Name: Cursor_Program_CURSORPG_Session#36_Slide#07 to obtain soft copy of the program code

Summary

You need to use cursors while retrieving more than one row:

SQL Statement Description COBOL equivalent for File Processing

DECLARE CURSOR Defines a result table and names a cursor for it

None

Open <cursor-name> Creates the result table and positions the cursor before the first row in the table

OPEN <file-name>

FETCH <cursor-name> Fetches the next row from the result table

READ <file-name>

CLOSE <cursor-name> Close the result table CLOSE <file-name>


1. Why do you need to use Cursor? 2. Explain the different SQL statements to be used for Cursor Processing. 3. How and why do you need to use cursor for updating the data?

Exercises

Develop and execute a COBOL-DB2 program which displays all the patient information available in the Patient table.


C3: Protected

Handout: DB2

Session 42: Handling Null

Learning Objectives

After completing this session, you will be able to: Identify data with the Null value in a COBOL-DB2 application program

Null - Introduction

As you have seen already, a null value is a special value that DB2 interprets to mean that no data is present. Null value is an unknown value and is not zero or blank. By Default, a column is allowed to be Null. Nulls can be prohibited by declaring the table column as “NOT NULL” during the table creation. When a table column is not defined as not null, then the column can either contain data or null.

Null Indicator

In order to determine whether the column value is null, you need to use an indicator variable in the COBOL program. An indicator variable is half word binary field that tells whether the field it applies to is null. Following table shows the value of the indicator variable and the corresponding column’s value:

Value of the Indicator Variable

Value of the corresponding column

-1 Null

0 Not Null

-2 Null because of conversion error

Positive value If DB2 has to truncate the value it returns to a host variable, it returns the original length in the indicator variable as the positive value

When you retrieve a column with an indicator variable, DB2 puts the appropriate value in the indicator. To refer to an indicator variable in the INTO clause of a SELECT or FETCH statement, you need to code the column name, a colon, and the name of the indicator variable with no intervening spaces as shown below. Example: EXEC SQL

SELECT TEST_NULL_COL

INTO :TEST-NULL-COL:IND-TEST-NULL-COL

FROM TB_TEST

END-EXEC.


C3: Protected

Handout: DB2

Indicator variable “IND-TEST-NULL-COL” is defined in the working-storage section as follows: Example: 01 IND-TEST-NULL-COL PIC S9(4) COMP.

When you update or insert a column with a null value, you need to move a value of -1 to the indicator variable, because you cannot move a null value into a COBOL host variable. Example: MOVE -1 TO IND-TEST-NULL-COL

EXEC SQL

INSERT INTO TB_TEST(TEST_NULL_COL)

VALUES (:TEST-NULL-COL:IND-TEST-NULL-COL)

END-EXEC.

If you do not supply an indicator variable for a column and an SQL statement retrieves a row with null value, then the statement will fail with the SQLCODE of -305.

Try It Out

Problem Statement: Create a program which populates the table TB_EMPLOYE from an Input file and

creates the output file which has the records from all the rows of TB_EMPLOYE table which include the data recently populated by using the Input file.

Structure of input and output file is same as table. Input File Content is as follows. If the Input file’s field has space, then populate null

value into the table column. If the column contains null value, then populate the output file with the value of space.

EMPLOYEE ID

EMPLOYEE LAST NAME

EMPLOYEE FIRST NAME

EMPLOYEE GENDER

EMPLOYEE DOB EMPLOYEE RATE CAT

E031 Divya F 1978-09-16 C

E032 Narayanasamy Gangaraj M 1979-09-17 C

E033 Vanitha F 1980-09-18 D


C3: Protected

Handout: DB2


PROGRAM-ID. NULLPRGM.


INPUT-OUTPUT SECTION.

FILE-CONTROL.

SELECT IN-FILE ASSIGN TO INFILE.

SELECT OUT-FILE ASSIGN TO OUTFILE.

DATA DIVISION.

FILE SECTION.

FD IN-FILE.

01 IN-REC.

05 IN-EMP-ID PIC X(4).

05 IN-EMP-LAST-NAME PIC X(15).

05 IN-EMP-FIRST-NAME PIC X(15).

05 IN-EMP-GENDER PIC X(1).

05 IN-EMP-DOB PIC X(10).

05 IN-EMP-RATE-CAT PIC X(1).

FD OUT-FILE.

01 OUT-REC.

05 OUT-EMP-ID PIC X(4).

05 OUT-EMP-LAST-NAME PIC X(15).

05 OUT-EMP-FIRST-NAME PIC X(15).

05 OUT-EMP-GENDER PIC X(1).

05 OUT-EMP-DOB PIC X(10).

05 OUT-EMP-RATE-CAT PIC X(1).


******************************************************************


******************************************************************








******************************************************************


******************************************************************





*


C3: Protected

Handout: DB2


******************************************************************

* SWITCH

******************************************************************

01 WS-AT-END-CUR-SW PIC X(1).

88 WS-NOT-AT-END-CUR VALUE 'N'.

88 WS-AT-END-CUR VALUE 'Y'.

* END OF FILE SWITCH

01 WS-EOF-SW PIC X(1).

88 WS-NOT-EOF VALUE 'N'.

88 WS-EOF VALUE 'Y'.

******************************************************************

* INCLUDE DCLGEN

******************************************************************

EXEC SQL

INCLUDE DEMPLOYE

END-EXEC.

******************************************************************

* INCLUDE SQLCA

******************************************************************

EXEC SQL

INCLUDE SQLCA

END-EXEC.

******************************************************************

* INDICATOR VARIABLE

******************************************************************

01 WS-INDICATOR.

05 IND-EMPLOYE-LAST-NAME PIC S9(4) COMP.

******************************************************************

* DECLARE CURSOR

******************************************************************

EXEC SQL

DECLARE CS-EMPLOYE CURSOR FOR

SELECT *

FROM TB_EMPLOYE

END-EXEC.

******************************************************************

* COBOL-DB2 PROGRAM WHICH SHOWS HOW TO DEAL WITH THE NULL VALUES

******************************************************************

PROCEDURE DIVISION.

0000-MAIN-PARA.

PERFORM 1000-INITIALIZE-PARA

THRU 1000-EXIT.


THRU 2000-EXIT.


C3: Protected

Handout: DB2

PERFORM 3000-FINALIZE-PARA

THRU 3000-EXIT.

STOP RUN.

1000-INITIALIZE-PARA.

OPEN INPUT IN-FILE

OUTPUT OUT-FILE.

SET WS-NOT-EOF TO TRUE.

1000-EXIT.

EXIT.

2000-PROCESS-PARA.

PERFORM 2100-POPULATE-PARA

THRU 2100-EXIT.


THRU 2200-EXIT.

PERFORM 2300-RETRIEVE-PARA

THRU 2300-EXIT.

2000-EXIT.

EXIT.

2100-POPULATE-PARA.

PERFORM 2110-READ-PARA

THRU 2110-EXIT.


THRU 2120-EXIT

UNTIL WS-EOF.

2100-EXIT.

EXIT.

2110-READ-PARA.

READ IN-FILE

AT END SET WS-EOF TO TRUE.

2110-EXIT.

EXIT.

2120-INSERT-PARA.

PERFORM 2121-POPULATE-HOST-VAR-PARA

THRU 2121-EXIT.

PERFORM 2122-SET-NULL-PARA

THRU 2122-EXIT.

EXEC SQL

INSERT INTO TB_EMPLOYE

(EMPLOYE_ID,

EMPLOYE_LAST_NAME,

EMPLOYE_FIRST_NAME,

EMPLOYE_GENDER,

EMPLOYE_DOB,

EMPLOYE_RATE_CAT)

VALUES (:EMPLOYE-ID,


C3: Protected

Handout: DB2

:EMPLOYE-LAST-NAME:IND-EMPLOYE-LAST-NAME,

:EMPLOYE-FIRST-NAME,

:EMPLOYE-GENDER,

:EMPLOYE-DOB,

:EMPLOYE-RATE-CAT)

END-EXEC.

EVALUATE SQLCODE

WHEN 0

DISPLAY 'INSERT SUCCESSFUL'

DISPLAY 'EMPLOYE_ID : ' EMPLOYE-ID

DISPLAY '**********************************************'

WHEN OTHER


MOVE 'TB_EMPLOYE' TO WS-TABLE



THRU 9999-EXIT

END-EVALUATE.


THRU 2110-EXIT.

2120-EXIT.

EXIT.

2121-POPULATE-HOST-VAR-PARA.

MOVE IN-EMP-ID TO EMPLOYE-ID.

MOVE IN-EMP-FIRST-NAME TO EMPLOYE-FIRST-NAME-TEXT.

MOVE IN-EMP-GENDER TO EMPLOYE-GENDER.

MOVE IN-EMP-DOB TO EMPLOYE-DOB.

MOVE IN-EMP-RATE-CAT TO EMPLOYE-RATE-CAT.

2121-EXIT.

EXIT.

2122-SET-NULL-PARA.

IF IN-EMP-LAST-NAME = SPACE

MOVE -1 TO IND-EMPLOYE-LAST-NAME

MOVE IN-EMP-LAST-NAME TO EMPLOYE-LAST-NAME-TEXT

ELSE

MOVE 0 TO IND-EMPLOYE-LAST-NAME


END-IF.

2122-EXIT.

EXIT.

2200-COMMIT-PARA.

EXEC SQL

COMMIT

END-EXEC.

EVALUATE SQLCODE


C3: Protected

Handout: DB2

WHEN 0

DISPLAY 'SUCCESSFULLY COMMITTED'

WHEN OTHER





THRU 9999-EXIT

END-EVALUATE.

2200-EXIT.

EXIT.

2300-RETRIEVE-PARA.

PERFORM 2310-OPEN-CURSOR-PARA

THRU 2310-EXIT.


THRU 2320-EXIT

UNTIL WS-AT-END-CUR.

PERFORM 2330-CLOSE-CURSOR-PARA

THRU 2330-EXIT.

2300-EXIT.

EXIT.

2310-OPEN-CURSOR-PARA.

EXEC SQL

OPEN CS-EMPLOYE

END-EXEC.

EVALUATE SQLCODE

WHEN 0

SET WS-NOT-AT-END-CUR TO TRUE

WHEN OTHER



MOVE '2310-OPEN-CURSOR-PARA'

TO WS-PARA


THRU 9999-EXIT

END-EVALUATE.

2310-EXIT.

EXIT.

2320-FETCH-PARA.

EXEC SQL

FETCH CS-EMPLOYE

INTO :EMPLOYE-ID,



:EMPLOYE-GENDER,


C3: Protected

Handout: DB2

:EMPLOYE-DOB,

:EMPLOYE-RATE-CAT

END-EXEC.

EVALUATE SQLCODE

WHEN 0

PERFORM 2321-CHECK-NULL-PARA

THRU 2321-EXIT

PERFORM 2322-POPULATE-OUT-FILE-PARA

THRU 2322-EXIT

PERFORM 2323-WRITE-OUT-FILE-PARA

THRU 2323-EXIT

WHEN +100

SET WS-AT-END-CUR TO TRUE

WHEN OTHER





THRU 9999-EXIT

END-EVALUATE.

2320-EXIT.

EXIT.

2321-CHECK-NULL-PARA.

IF IND-EMPLOYE-LAST-NAME = -1

MOVE SPACE TO OUT-EMP-LAST-NAME

ELSE

MOVE EMPLOYE-LAST-NAME-TEXT

TO OUT-EMP-LAST-NAME

END-IF.

2321-EXIT.

EXIT.

2322-POPULATE-OUT-FILE-PARA.

MOVE EMPLOYE-ID TO OUT-EMP-ID.

MOVE EMPLOYE-FIRST-NAME-TEXT

TO OUT-EMP-FIRST-NAME.

MOVE EMPLOYE-GENDER TO OUT-EMP-GENDER.

MOVE EMPLOYE-DOB TO OUT-EMP-DOB.

MOVE EMPLOYE-RATE-CAT TO OUT-EMP-RATE-CAT.

2322-EXIT.

EXIT.

2323-WRITE-OUT-FILE-PARA.

WRITE OUT-REC.

2323-EXIT.

EXIT.

2330-CLOSE-CURSOR-PARA.


C3: Protected

Handout: DB2

EXEC SQL

CLOSE CS-EMPLOYE

END-EXEC.

IF SQLCODE NOT= 0



MOVE '2330-CLOSE-CURSOR-PARA'

TO WS-PARA


THRU 9999-EXIT

END-IF.

2330-EXIT.

EXIT.

3000-FINALIZE-PARA.

CLOSE IN-FILE

OUT-FILE.

3000-EXIT.

EXIT.


DISPLAY '-----------------------------------------------'.



DISPLAY '-----------------------------------------------'.


WS-DB2-ERR-MESSAGE


IF RETURN-CODE = 0

PERFORM


FROM 1

BY 1



END-PERFORM

ELSE


END-IF.

EXEC SQL

ROLLBACK

END-EXEC.

9999-EXIT.

EXIT.

Refer File Name: Null_Program_NULLPRGM_Session#43_Slide#7 to obtain soft copy of the program code


C3: Protected

Handout: DB2

Summary

A null value is a special value that DB2 interprets to mean that no data is present. In order to determine whether the column value is null, you need to use an indicator

variable in the COBOL program.


1. What is null? 2. Explain about the behavior of null with different situations. 3. What is a Null indicator and how can you use it in a COBOL-DB2 program?

Exercises

Develop and execute a COBOL-DB2 Program which inserts the rows of PATIENT table from an Input file. The content of the Input file is as follows:


A121 NULL KISHOREKUMARREDDY M 8/27/1980

A122 NULL SRIVIDHYA F 8/27/1982

Store all the rows of the PATIENT Table into one Output File whose Layout is same as Input File. If a particular Patient does not have Last name, then for that particular record, the last name field of the file should show a value of “NO LAST NAME”. Note: The Number of records in the output file should be 12.


C3: Protected

Handout: DB2

Session 46: Handling VARCHAR

Learning Objectives

After completing this session, you will be able to: Identify data with the variable length columns of the DB2 table

VARCHAR - Introduction

In the DCLGEN, the host variable for the variable length column has two components: Length Component Text Component

Length Component gives the actual number of characters in the text portion when the data in the column is retrieved or the actual number of characters to be populated to the column. Text component contains the actual text and it provides for the maximum number of characters that the column can contain.

VARCHAR - Behavior

In the employee table the values for the first four rows are as follows: EMPLOY

E_ID EMPLOYE_LAS

T_NAME EMPLOYE_FIRS

T_NAME EMPLOYE_GE

NDER EMPLOYE_

DOB EMPLOYE_RATE_

CAT E001 AWALGAONKAR MADHURI F 1980-08-17 C

E002 BORRA VAMSHI M 1975-06-30 A

E003 CHINTALAPHANI

VARUN M 1970-07-19 B

E004 DABBIRU ANIL M 1985-04-28 E

If you fetch the data from this table and write it into the file, the content of the file will be as follows:

OUT-EMP-ID

OUT-EMP-LAST-NAME

OUT-EMP-FIRST-NAME

OUT-EMP-GENDER

OUT-EMP-DOB

OUT-EMP-RATE-CAT

E001 AWALGAONKAR MADHURI F 1980-08-17 C

E002 BORRAAONKAR VAMSHII M 1975-06-30 A

E003 CHINTALAPHANI VARUNII M 1970-07-19 B

E004 DABBIRUAPHANI ANILNII M 1985-04-28 E


C3: Protected

Handout: DB2

In the second record of the output file, in the last name field, in addition to the current content “BORRA”, the previous content is also overlapped. That is why you get the last name field as “BORRAAONKAR”. The characters “AONKAR” is derived from the first record’s last name field which is “AWALGAONKAR” If you examine the host variable content, then it is as follows:

EMPLOYE-ID EMPLOYE-LAST-NAME-LEN EMPLOYE-LAST-NAME-TEXT

E001 11 AWALGAONKAR

E002 5 BORRAAONKAR

The same phenomenon has happened for the first name field also. DB2 does not replace the entire text portion of a host variable with the next value that is retrieved. In order to avoid this, you need to initialize that is, move spaces to the text component of the variable length field before the next retrieval. When you retrieve variable length data, DB2 will automatically puts the actual length value to the length component. When you update or add variable length data to a table, your program should put the actual length in the length component and the text into the text component before UPDATE or INSERT.

Try It Out

Problem Statement: Create a program which populates the table TB_EMPLOYE from an Input file and creates the output file which has the records from all the rows of TB_EMPLOYE table which include the data recently populated by using the Input file. Structure of Input and Output file is same as table. Input File Content is as follows. If the Input file’s field has space, then populate null value into the table column. If the column contains null value, then populate the output file with the value of space. The output should be proper.

EMPLOYEE ID

EMPLOYEE LAST NAME

EMPLOYEE FIRST NAME

EMPLOYEE GENDER

EMPLOYEE DOB

EMPLOYEE RATE CAT

E031 Divya F 1978-09-16 C

E032 Narayanasamy Gangaraj M 1979-09-17 C

E033 Vanitha F 1980-09-18 D


PROGRAM-ID. VARCNULL.


INPUT-OUTPUT SECTION.

FILE-CONTROL.

SELECT IN-FILE ASSIGN TO INFILE.

SELECT OUT-FILE ASSIGN TO OUTFILE.

DATA DIVISION.


C3: Protected

Handout: DB2

FILE SECTION.

FD IN-FILE.

01 IN-REC.

05 IN-EMP-ID PIC X(4).

05 IN-EMP-LAST-NAME PIC X(15).

05 IN-EMP-FIRST-NAME PIC X(15).

05 IN-EMP-GENDER PIC X(1).

05 IN-EMP-DOB PIC X(10).

05 IN-EMP-RATE-CAT PIC X(1).

FD OUT-FILE.

01 OUT-REC.

05 OUT-EMP-ID PIC X(4).

05 OUT-EMP-LAST-NAME PIC X(15).

05 OUT-EMP-FIRST-NAME PIC X(15).

05 OUT-EMP-GENDER PIC X(1).

05 OUT-EMP-DOB PIC X(10).

05 OUT-EMP-RATE-CAT PIC X(1).


******************************************************************


******************************************************************








******************************************************************


******************************************************************





*


******************************************************************

* SWITCH

******************************************************************

01 WS-AT-END-CUR-SW PIC X(1).

88 WS-NOT-AT-END-CUR VALUE 'N'.

88 WS-AT-END-CUR VALUE 'Y'.

* END OF FILE SWITCH

01 WS-EOF-SW PIC X(1).


C3: Protected

Handout: DB2

88 WS-NOT-EOF VALUE 'N'.

88 WS-EOF VALUE 'Y'.

******************************************************************

* INCLUDE DCLGEN

******************************************************************

EXEC SQL

INCLUDE DEMPLOYE

END-EXEC.

******************************************************************

* INCLUDE SQLCA

******************************************************************

EXEC SQL

INCLUDE SQLCA

END-EXEC.

******************************************************************

* INDICATOR VARIABLE

******************************************************************

01 WS-INDICATOR.

05 IND-EMPLOYE-LAST-NAME PIC S9(4) COMP.

******************************************************************

* DECLARE CURSOR

******************************************************************

EXEC SQL

DECLARE CS-EMPLOYE CURSOR FOR

SELECT *

FROM TB_EMPLOYE

END-EXEC.

******************************************************************

* COBOL-DB2 PROGRAM WHICH SHOWS HOW TO HANDLE VARCHAR FIELDS

******************************************************************

PROCEDURE DIVISION.

0000-MAIN-PARA.

PERFORM 1000-INITIALIZE-PARA

THRU 1000-EXIT.


THRU 2000-EXIT.

PERFORM 3000-FINALIZE-PARA

THRU 3000-EXIT.

STOP RUN.

1000-INITIALIZE-PARA.

OPEN INPUT IN-FILE

OUTPUT OUT-FILE.

SET WS-NOT-EOF TO TRUE.

1000-EXIT.

EXIT.


C3: Protected

Handout: DB2

2000-PROCESS-PARA.

PERFORM 2100-POPULATE-PARA

THRU 2100-EXIT.


THRU 2200-EXIT.

PERFORM 2300-RETRIEVE-PARA

THRU 2300-EXIT.

2000-EXIT.

EXIT.

2100-POPULATE-PARA.


THRU 2110-EXIT.


THRU 2120-EXIT

UNTIL WS-EOF.

2100-EXIT.

EXIT.

2110-READ-PARA.

READ IN-FILE

AT END SET WS-EOF TO TRUE.

2110-EXIT.

EXIT.

2120-INSERT-PARA.

PERFORM 2121-POPULATE-HOST-VAR-PARA

THRU 2121-EXIT.

PERFORM 2122-SET-NULL-PARA

THRU 2122-EXIT.

PERFORM 2123-HANDLE-VARCHAR-PARA

THRU 2123-EXIT.

EXEC SQL

INSERT INTO TB_EMPLOYE

(EMPLOYE_ID,

EMPLOYE_LAST_NAME,

EMPLOYE_FIRST_NAME,

EMPLOYE_GENDER,

EMPLOYE_DOB,

EMPLOYE_RATE_CAT)

VALUES (:EMPLOYE-ID,



:EMPLOYE-GENDER,

:EMPLOYE-DOB,

:EMPLOYE-RATE-CAT)

END-EXEC.

EVALUATE SQLCODE


C3: Protected

Handout: DB2

WHEN 0

DISPLAY 'INSERT SUCCESSFUL'

DISPLAY 'EMPLOYE_ID : ' EMPLOYE-ID

DISPLAY '**********************************************'

WHEN OTHER





THRU 9999-EXIT

END-EVALUATE.


THRU 2110-EXIT.

2120-EXIT.

EXIT.

2121-POPULATE-HOST-VAR-PARA.

MOVE IN-EMP-ID TO EMPLOYE-ID.

MOVE IN-EMP-FIRST-NAME TO EMPLOYE-FIRST-NAME-TEXT.

MOVE IN-EMP-GENDER TO EMPLOYE-GENDER.

MOVE IN-EMP-DOB TO EMPLOYE-DOB.

MOVE IN-EMP-RATE-CAT TO EMPLOYE-RATE-CAT.

2121-EXIT.

EXIT.

2122-SET-NULL-PARA.

IF IN-EMP-LAST-NAME = SPACE

MOVE -1 TO IND-EMPLOYE-LAST-NAME


ELSE

MOVE 0 TO IND-EMPLOYE-LAST-NAME


END-IF.

2122-EXIT.

EXIT.

2123-HANDLE-VARCHAR-PARA.

MOVE LENGTH OF IN-EMP-LAST-NAME

TO EMPLOYE-LAST-NAME-LEN.

MOVE LENGTH OF IN-EMP-FIRST-NAME

TO EMPLOYE-FIRST-NAME-LEN.

2123-EXIT.

EXIT.

2200-COMMIT-PARA.

EXEC SQL

COMMIT

END-EXEC.

EVALUATE SQLCODE


C3: Protected

Handout: DB2

WHEN 0

DISPLAY 'SUCCESSFULLY COMMITTED'

WHEN OTHER





THRU 9999-EXIT

END-EVALUATE.

2200-EXIT.

EXIT.

2300-RETRIEVE-PARA.

PERFORM 2310-OPEN-CURSOR-PARA

THRU 2310-EXIT.


THRU 2320-EXIT

UNTIL WS-AT-END-CUR.

PERFORM 2330-CLOSE-CURSOR-PARA

THRU 2330-EXIT.

2300-EXIT.

EXIT.

2310-OPEN-CURSOR-PARA.

EXEC SQL

OPEN CS-EMPLOYE

END-EXEC.

EVALUATE SQLCODE

WHEN 0

SET WS-NOT-AT-END-CUR TO TRUE

WHEN OTHER



MOVE '2310-OPEN-CURSOR-PARA'

TO WS-PARA


THRU 9999-EXIT

END-EVALUATE.

2310-EXIT.

EXIT.

2320-FETCH-PARA.

PERFORM 2321-INITIALIZE-VARCHAR-PARA

THRU 2321-EXIT.

EXEC SQL

FETCH CS-EMPLOYE

INTO :EMPLOYE-ID,



C3: Protected

Handout: DB2


:EMPLOYE-GENDER,

:EMPLOYE-DOB,

:EMPLOYE-RATE-CAT

END-EXEC.

EVALUATE SQLCODE

WHEN 0

PERFORM 2322-CHECK-NULL-PARA

THRU 2322-EXIT

PERFORM 2323-POPULATE-OUT-FILE-PARA

THRU 2323-EXIT

PERFORM 2324-WRITE-OUT-FILE-PARA

THRU 2324-EXIT

WHEN +100

SET WS-AT-END-CUR TO TRUE

WHEN OTHER





THRU 9999-EXIT

END-EVALUATE.

2320-EXIT.

EXIT.

2321-INITIALIZE-VARCHAR-PARA.

MOVE SPACE TO EMPLOYE-LAST-NAME-TEXT.

MOVE SPACE TO EMPLOYE-FIRST-NAME-TEXT.

2321-EXIT.

EXIT.

2322-CHECK-NULL-PARA.

IF IND-EMPLOYE-LAST-NAME = -1

MOVE SPACE TO OUT-EMP-LAST-NAME

ELSE

MOVE EMPLOYE-LAST-NAME-TEXT

TO OUT-EMP-LAST-NAME

END-IF.

2322-EXIT.

EXIT.

2323-POPULATE-OUT-FILE-PARA.

MOVE EMPLOYE-ID TO OUT-EMP-ID.

MOVE EMPLOYE-FIRST-NAME-TEXT

TO OUT-EMP-FIRST-NAME.

MOVE EMPLOYE-GENDER TO OUT-EMP-GENDER.

MOVE EMPLOYE-DOB TO OUT-EMP-DOB.

MOVE EMPLOYE-RATE-CAT TO OUT-EMP-RATE-CAT.


C3: Protected

Handout: DB2

2323-EXIT.

EXIT.

2324-WRITE-OUT-FILE-PARA.

WRITE OUT-REC.

2324-EXIT.

EXIT.

2330-CLOSE-CURSOR-PARA.

EXEC SQL

CLOSE CS-EMPLOYE

END-EXEC.

IF SQLCODE NOT= 0



MOVE '2330-CLOSE-CURSOR-PARA'

TO WS-PARA


THRU 9999-EXIT

END-IF.

2330-EXIT.

EXIT.

3000-FINALIZE-PARA.

CLOSE IN-FILE

OUT-FILE.

3000-EXIT.

EXIT.


DISPLAY '-----------------------------------------------'.



DISPLAY '-----------------------------------------------'.


WS-DB2-ERR-MESSAGE


IF RETURN-CODE = 0

PERFORM


FROM 1

BY 1



END-PERFORM

ELSE


END-IF.

EXEC SQL


C3: Protected

Handout: DB2

ROLLBACK

END-EXEC.

9999-EXIT.

EXIT.

Refer File Name: Varchar_Program_VARCNULL_Session#46_Slide#7 to obtain soft copy of the program code

Summary

In the DCLGEN, the host variable for the variable length column has two components: o Length Component o Text Component

While retrieving the data from the variable length column, you need to initialize the text component of the host variable, prior to each retrieval.

While updating or adding the data for a variable length column, you need to move the actual length in the length component and the text in the text component of the host variable before the UPDATE or INSERT.


1. How is the host variable of the VARCHAR column different from any other column? 2. How do you have to retrieve the data of variable length column? 3. How do you have to update or add the data for the variable length column?

Exercises

Get the proper output in the output file of the last session’s program. Last session’s program is as follows. Develop and execute a COBOL-DB2 Program which inserts the rows of PATIENT table from an Input file. The content of the Input file is as follows:


A121 NULL KISHOREKUMARREDDY M 8/27/1980

A122 NULL SRIVIDHYA F 8/27/1982

Store all the rows of the PATIENT Table into one Output File whose Layout is same as Input File. If a particular Patient doesn’t have Last name, then for that particular record, the last name field of the file should show a value of “NO LAST NAME”. Note: The Number of records in the output file should be 12.


C3: Protected

Handout: DB2

Session 51: Locks

Learning Objectives

After completing this session, you will be able to: Describe how DB2 achieves the two conflicting goals of data integrity and data

concurrency

Lock - Introduction

DB2 automatically guarantees the integrity of data by enforcing several locking strategies. These strategies permit multiple users from multiple environments to access and modify data concurrently. DB2 locks prevent one program from accessing data that has been changed, but not yet committed, by another program. Locking process is controlled by DB2’s IRLM (Inter System Resource Lock Manager). However, whenever practical, DB2 tries to lock pages without going to the IRLM. This type of lock is called a latch.

Table Space - Recap

Data is actually stored in a structure known as table space. Each table space correlates to one or more individual physical VSAM data sets in the DASD volumes of a storage Group. Each table space contains one or more tables. There are three different types of table space and are as follows:

Simple table space Segmented table space Partitioned table space

Simple Table Space

In a simple table space, the space is divided into pages without any higher level structure. Simple table space can contain data from more than one table. As data rows from different tables can reside on the same page, concurrency will be reduced a lot. After DB2 version 2.1, the simple table spaces are almost obsolete.


C3: Protected

Handout: DB2

Segmented Table Space

In a segmented table space, the space is divided into equal sized group of pages called “Segments”. Each segment can contain rows from only one table. This is the most efficient type of table space because it maximizes concurrency.

Partitioned Table Space

In the partitioned table space, the space is divided into units called “Partitions”. Each partition contains part of one table and resides on a separate VSAM data set. Each partition table space can contain only one table. This is suitable for large tables that contain one million or more pages.

Lock Size

When a table space is defined or altered, the LOCKSIZE clause specifies a default lock size. The lock size can be:

ROW

PAGE

TABLE

TABLESPACE

ANY

When the LOCKSIZE(ANY) option is used, DB2 selects the optimum lock size for each processing situation.


C3: Protected

Handout: DB2

Lock Escalation

Lock hierarchy is as follows:

If the number of locks in one level exceeds an installation default, then DB2 locks a larger unit. This is called Lock escalation. In a non-segmented table space, the page or row lock is escalated to table space lock. In a segmented table space, the page or row lock is first escalated to table and then if necessary to a table space lock.

Lock Duration

Lock duration refers to the length of the time that a lock is maintained. The duration of a lock is based on the BIND options chosen for the program requesting locks. Locks can be acquired either immediately when the plan is requested to be run or iteratively as needed during the execution of the program. Bind parameters affecting table space and table Locks

ACQUIRE(ALLOCATE):

o Locks will be acquired when the plan is allocated, which normally occurs when the first SQL statement is issued.

o This is used for batch processing. ACQUIRE(USE):

o Locks will be acquired only as they are required, SQL statement by SQL statement.

o This is used for online processing. RELEASE (DEALLOCATE): Locks are not released until the plan is terminated and is

used for batch processing. RELEASE(COMMIT): Locks are released when a COMMIT is issued and is used for

online processing.


C3: Protected

Handout: DB2

Bind parameters affecting page and row Locks ISOLATION level:

o Repeatable Read (RR): This holds page and row locks until a COMMIT point is reached. No other program can modify the data. If the data is accessed twice during the unit of work, the same exact data will be returned.

o Read Stability (RS): This holds page and row locks until a COMMIT point is reached. But other programs can INSERT new data. If data is accessed twice during the unit of work, new rows may be returned, but old rows will not have changed.

o Cursor Stability (CS): This acquires and releases page or row locks as pages or rows are read and processed. This provides the greatest level of concurrency. But there is a chance of different data being returned by the same cursor if it is processed twice during the same unit of work.

o Uncommitted Read (UR): This is also known as dirty read processing. UR avoids locking altogether. Data can be read that may never actually exist in the database. We can use this for working with the table that is rarely updated. Regardless of the ISOLATION level chosen, all page locks are released when a COMMIT is encountered.

Summary

The lock size can be: ROW

PAGE

TABLE

TABLESPACE

ANY

Type of Tablespace Space Division Contains

Simple No hierarchy; Only pages A page can contain rows from different tables

Segmented Segments One Segment – One Table

Partitioned Partitions Entire Partition table space – One table

Bind parameters affecting table and tablespace locks:

Lock Duration Locks are acquired or released Recommendation

ACQUIRE(ALLOCATE) When plan is allocated Use for batch processing

ACQUIRE(USE) As they are needed Use for online processing

RELEASE(DEALLOCATE) When plan is terminated

Use for batch processing

RELEASE(COMMIT) When a commit occurs Use for online processing


C3: Protected

Handout: DB2

Bind parameters affecting page and row locks: o Isolation level:

Repeatable Read (RR) Read Stability (RS) Cursor Stability (CS) Uncommitted Read (UR)


1. Explain about the three types of tablespaces. 2. Explain about the options available in the lock size. 3. What is lock escalation? 4. What is lock duration and how is it being achieved? 5. Explain about the different isolation levels.


C3: Protected

Handout: DB2

Session 52: Locks

Learning Objectives

After completing this session, you will be able to: Describe the remaining concepts of lock

Lock Mode

Lock Mode determines what the program that owns the lock and what concurrent programs can do with the locked resource. Following is the list of modes of table and table space locks:

Lock Meaning Access Acquired Access Allowed to Others

S SHARE Read only Read only

U UPDATE Read with intent to update Read only

X EXCLUSIVE Update No access

IS INTENT SHARE Read only Update

IX INTENT EXCLUSIVE Update Update

SIX SHARE/INTENT EXCLUSIVE

Read or update Read only

The following list tells you how tablespace locks are acquired:

Type of Processing LOCKSIZE Isolation Initial Lock Acquired

MODIFY ANY CS IX

MODIFY PAGE/ROW CS IX

MODIFY TABLESPACE CS X

MODIFY ANY RR X

MODIFY PAGE/ROW RR X

MODIFY TABLESPACE RR X

SELECT ANY CS IS

SELECT PAGE/ROW CS IS

SELECT TABLESPACE CS S

SELECT ANY RR S

SELECT PAGE/ROW RR S

SELECT TABLESPACE RR S


C3: Protected

Handout: DB2

The following list tells us how Table Locks are acquired

Type of Processing

LOCKSIZE Isolation Table space Lock Acquired

Table Lock Acquired

MODIFY ANY CS IS IX

MODIFY PAGE CS IS IX

MODIFY TABLE CS IS X

MODIFY ANY RR IS X

MODIFY PAGE RR IS X

MODIFY TABLE RR IS X

SELECT ANY CS IS IS

SELECT PAGE CS IS IS

SELECT TABLE CS IS S

SELECT ANY RR IS S

SELECT PAGE RR IS S

SELECT TABLE RR IS S

Following is the modes of page and row locks.

Lock Meaning Access Acquired Access Allowed to Others

S SHARE Read only Read only

U UPDATE Read with intent to update Read only

X EXCLUSIVE Update No access

The following list tells us how page Locks are acquired.

Type of Processing Page Lock Acquired Pages Affected SELECT/FETCH S Page by page as they are fetched

OPEN CURSOR for S All pages affected SELECT

SELECT/FETCH FOR UPDATE OF

U Page by page as they are fetched

UPDATE X Page by page

INSERT X Page by page

DELETE X Page by page

The following list tells us how row Locks are acquired

Type of Processing Row Lock Acquired Rows Affected

SELECT/FETCH S Row by row as they are fetched

OPEN CURSOR for SELECT S All rows affected

SELECT/FETCH FOR UPDATE OF U Row by row as they are fetched


C3: Protected

Handout: DB2


C3: Protected

Type of Processing Row Lock Acquired Rows Affected

UPDATE X Row by row

INSERT X Row by row

DELETE X Row by row

Suspension

The longer a lock is held, the greater the potential impact on other applications. When an application requests a lock that is already held by another process, and the lock cannot be shared, that application is suspended. A suspended process temporarily stops running until the lock can be acquired. Lock suspensions can be a significant barrier to acceptable performance and application availability.

Timeout

When an application has been suspended for a predetermined period of time, it will be terminated. When a process is terminated because it exceeds this period of time, it is said to be time out. A timeout is caused by the unavailability of a given resource. A sample scenario is as follows. This figure illustrates the flow of various transactions of two programs which have been executed simultaneously and how DB2 handles the integrity and concurrency.

Program 1 Program 2

Update Table A/Page 1

Lock established

Intermediate processing Update Table A/Page 1

. Lock (wait)

. Lock suspension

. Timeout -911 received

If Program 2, holding no other competitive locks, then requests a lock currently held by Program 1, DB2 tries to obtain the lock for a period of time. Then it quits trying. This example illustrates a timeout.

Deadlock

A deadlock occurs when two separate processes compete for resources held by one another. To break the deadlock, DB2 rolls back the current unit of work for one of the programs after the preset time interval for deadlocks and then terminates that program with the SQLCODE of -911 or -913. This program is called victim. This will free the locks and allow the remaining program to continue.

Handout: DB2

Sample Scenario is as follows. This figure depicts how a deadlock scenario will happen by describing the flow of tasks in two programs executed simultaneously.

Program 1 Program 2

Update Table B/Page 1 Update Table A/Page 1

Lock established Lock established

Intermediate processing Intermediate processing

Update Table A/Page 1 Update Table B/Page 1

Lock (wait) Deadlock Lock (wait)

A deadlock occurs when Program 1 requests a lock for a data page held by Program 2 and Program 2 requests a lock for a data page held by Program 1. DB2's solution for the deadlock is to target one of the two programs as the victim of the deadlock and deny that program's lock request by setting the SQLCODE to -911.

Constructs that affect locking

COBOL provides three constructs that affect locking: WITH clause WITH HOLD clause LOCK TABLE statement

WITH Clause: This can be used to override the isolation level of a bound plan or package. This can be used in the following:

SELECT statement SELECT INTO statements Searched deletes Searched updates INSERT statement that uses subquery

This cannot be used in subqueries except in INSERT statements. The isolation level in the WITH clause is effective only for the statement in which it appears. Example: SELECT *

FROM TB_PROJECT

WITH UR;

WITH HOLD Clause: As you have already seen the cursor position is maintained past a commit point. So the locks needed to maintain the position are not released even if they were acquired with ISOLATION(CS) and RELEASE(COMMIT). You need to clearly monitor the use of WITH HOLD clause because this will increase the number of suspensions and timeouts.


C3: Protected

Handout: DB2

LOCK TABLE statement: LOCK TABLE <table-name> IN SHARE MODE

The LOCK TABLE statement is appropriate in a high priority program. The LOCK TABLE statement is also appropriate in a program that frequently acquires many row or page locks for a table before these locks are escalated to a next level. If the table specified in this statement is not in a segmented table space, DB2 applies the lock to all of the tables in the table space, not just the one named.

Summary

Lock modes available for tablespaces and tables are: o S o U o X o IS o IX o SIX

Lock modes available for pages and rows are: o S o U o X

When an application requests a lock that is already held by another process, and the lock cannot be shared, then that application is suspended.

When an application has been suspended for a predetermined period of time, it will be terminated and it is timed out.

A deadlock occurs when two separate processes compete for resources held by one another.

COBOL provides three constructs that affect locking: o WITH clause o WITH HOLD clause o LOCK TABLE statement


1. Explain about the lock modes of tablespace, table, page, and row locks. 2. What is suspension? 3. What is timeout and how can you resolve the problem? 4. What is deadlock and how is it resolved by DB2? 5. Explain about the different COBOL constructs that affect locking.


C3: Protected

Handout: DB2

Session 54: Miscellaneous

Learning Objectives

After completing this session, you will be able to: Identify important bind parameters Explain common SQL Error Codes List the Application Programming Guidelines Describe about EXPLAIN

Bind Parameters

Some important bind parameters are as follows: MEMBER(&MEMBER.) -

QUALIFIER(NAME) -

ACTION(REPLACE) -

RETAIN -

VALIDATE(BIND) -

ACQUIRE(USE) -

RELEASE(COMMIT) -

ISOLATION(CS) -

DEGREE(ANY) -

EXPLAIN(YES)

MEMBER(&MEMBER.): Specifies the name of the DBRM to be bound to a plan. QUALIFIER: Specifies an identifier to be used by the bind process to qualify all

tables referenced by SQL statements in the DBRM being bound. For example, the DSN8510.TB_DEPT table, is accessed if the following statement is embedded in a program bound to a plan specifying a QUALIFIER of DSN8510: EXEC SQL

SELECT DEPT_NO, DEPT_NAME

INTO :DEPT-NO, :DEPT-NAME

FROM TB_DEPT

END-EXEC.

ACTION: You can specify two types of actions, namely ADD or REPLACE o ADD indicates that the plan is new. o REPLACE indicates that an old plan by the same name will be replaced. o Specifying ACTION (REPLACE) for a new plan does not cause the bind to fail—it

merely causes confusion. RETAIN: Indicates that all bind and execute authority granted for this plan will be

retained. If we fail to specify the RETAIN parameter, all authority for the plan is revoked. This is only for BIND PLAN.


C3: Protected

Handout: DB2

VALIDATE: A validation strategy refers to the method of checking for the existence and validity of DB2 tables and DB2 access authorization. o You can use two types of validation strategies: VALIDATE(BIND) or

VALIDATE(RUN). o VALIDATE(BIND), the preferred option, validates at bind time. If a table is invalid

or proper access authority has not been granted, the bind fails. o VALIDATE(RUN) validates DB2 table and security each time the plan is executed.

This capability is useful if a table is changed or authority is granted after the bind is issued. It does, however, impose potentially severe performance degradation because each SQL statement is validated each time it is executed.

ACQUIRE: You have seen this in detail in previous sessions. The options for the ACQUIRE parameter are USE and ALLOCATE. o When you specify USE, tablespace locks are taken when the tablespace is

accessed. o With ALLOCATE, table space locks are taken when the plan is first allocated. o The preferred options for online application is USE and for batch is ALLOCATE.

RELEASE: The options for RELEASE are COMMIT and DEALLOCATE. o When you specify the COMMIT option, locks are released at commit time. o When you specify DEALLOCATE, all locks are held until the plan finishes and is de-

allocated. o The preferred option for online application is COMMIT and for batch is

DEALLOCATE. ISOLATION: You have seen this in detail in previous sessions. The isolation level

determines the mode of page / row locking implemented by the program as it runs.You can specify the following four isolation levels: o Repeatable read (RR) o Read stability (RS) o Cursor stability (CS) o Uncommitted read (UR)

DEGREE: When DEGREE(ANY) is specified, DB2 will attempt to execute queries using parallel engines whenever possible. Parallel queries are typically deployed against partitioned table spaces

EXPLAIN: EXPLAIN(YES) allows the proper monitoring of the access path selection made by DB2.

Common SQL Errors

Following list shows some of the common SQL error codes:

SQLCODE Description

-104 Illegal symbol encountered in SQL statement.

-118 Table or view is illegally named in both data modification clause (UPDATE or DELETE) and the FROM clause.

-181 Not a valid DATE, TIME, or TIMESTAMP value.

-204 Undefined object name.

-305 Null indicator variable is missing.


C3: Protected

Handout: DB2


C3: Protected

SQLCODE Description

-408 Value cannot be inserted or updated because it is incompatible with the column's data type.

-532 Deletion violates the named referential constraint.

-545 INSERT or UPDATE caused a check constraint violation.

-803 Cannot insert row because it would violate the constraints of a unique index.

-811 Must use a cursor when more than one row is returned as the result of an embedded select statement.

-818 Plan <—> load module timestamp mismatch. The DBRM in the executing plan was not created from the same precompilation as the load module.

-904 The specified resource is unavailable

-905 Resource limit has been exceeded.

-911 The current unit of work has been rolled back.

-913 Unsuccessful execution caused by either a deadlock or a timeout.

Application Programming Guidelines

Code modular DB2 programs and make them as small as possible Use unqualified SQL statements; this enables movement from one environment to

another (Test to Production) Never use Select * in an embedded SQL program Use Joins rather than subqueries Use WHERE clause wherever possible and filter out data Use cursors when fetching multiple rows, though they add overheads Use FOR UPDATE OF clause for UPDATE or DELETE with cursor - this ensures data

integrity. Use INSERTs minimally; use LOAD utility instead of INSERT, if the inserts are not

application dependent.

Using EXPLAIN

You can use the EXPLAIN feature to detail the access paths chosen by the DB2 optimizer for SQL statements. EXPLAIN should be a key component for the performance monitoring strategy. A single SQL statement or a series of SQL statements in a package or plan, can be the subject of an EXPLAIN.

Handout: DB2

When EXPLAIN is requested, the SQL statements are passed through the DB2 optimizer, and the following three activities are performed:

The access paths that DB2 chooses are externalized, in coded format, into a PLAN_TABLE.

Cost estimates for the SQL statements are formulated and inserted into a DSN_STATEMNT_TABLE.

The user-defined functions that will be used are placed into a DSN_FUNCTION_TABLE.

To EXPLAIN a single SQL statement, precede the SQL statement with the EXPLAIN command as follows: EXPLAIN ALL SET QUERYNO = integer FOR

SQL statement ;

It can be executed in the same way as any other SQL statement. QUERYNO, which you can set to any integer, is used for identification in the PLAN_TABLE. Example: The following EXPLAIN statement populates the PLAN_TABLE with the access paths chosen for the indicated sample table query: EXPLAIN ALL SET QUERYNO = 1 FOR

SELECT FIRSTNME, MIDINIT, LASTNAME

FROM DSN8610.EMP

WHERE EMPNO = '000240';

Another method of issuing an EXPLAIN is as a part of the BIND command. If you indicate EXPLAIN(YES) when binding a package or a plan, DB2 externalizes

the access paths chosen for all SQL statements in that DBRM (or DBRMs) to the PLAN_TABLE.

Summary

In this session you have seen the common bind parameters, common SQL error codes, application programming guidelines, and how to apply EXPLAIN.


1. Explain about the different bind parameters. 2. Explain the common SQL error codes. 3. Explain the guidelines for application programming. 4. Describe about EXPLAIN.


C3: Protected

Handout: DB2


Learning Objectives

After completing this session, you will be able to: Describe DB2 Catalog Explain DB2 Directory

Table-Based Infrastructure of DB2

DB2 has a set of tables that functions as a repository for all DB2 objects. These tables define the infrastructure of DB2, enabling simple detection of and access to DB2 objects. Two sets of tables store all the data related to DB2 objects which are:

DB2 Catalog DB2 Directory

DB2 Catalog

The entire DBMS relies on the system catalog, or the DB2 Catalog. If the DB2 optimizer is the heart and soul of DB2, then DB2 Catalog is its brain or memory. The knowledge base of every object known to DB2 is stored in the DB2 Catalog. Following list is a short description of each table in the DB2 Catalog:

Table Contents IPNAMES To set up distributed TCP/IP connections

LOCATIONS Contains distributed location information for every accessible remote server

LULIST Contains the list of LUNAMEs for a given distributed location (when multiple LUNAMEs are associated with a single location)

LUMODES Information on distributed conversation limits

LUNAMES Contains information for every SNA client or server that communicates with the DB2 subsystem

MODESELECT Information assigning mode names to conversations supporting outgoing SQL requests

SYSAUXRELS Information on the auxiliary tables required for LOB columns

SYSCHECKDEP Column references for CHECK constraints

SYSCHECKS CHECK constraint specifications

SYSCOLAUTH The UPDATE privileges held by DB2 users on table or view columns

SYSCOLDIST The non-uniform distribution statistics for the 10 most frequently occurring values in a column

SYSCOLDISTSTATS The non-uniform distribution statistics for the 10 most frequently occurring values for the first key column in a partitioned index


C3: Protected

Handout: DB2


C3: Protected

Table Contents SYSCOLSTATS The partition statistics for selected columns

SYSCOLUMNS Information about every column of every DB2 table and view

SYSCONSTDEP Information regarding columns that are dependent on check constraints and user-defined defaults

SYSCOPY Information on the execution of DB2 utilities required by DB2 recovery

SYSDATABASE Information about every DB2 database

SYSDATATYPES Information about the user-defined distinct types defined to the DB2 subsystem

SYSDBAUTH Database privileges held by DB2 users

SYSDBRM DBRM information only for DBRMs bound into DB2 plans

SYSDUMMY1 Contains no information; this table is for use in SQL statements requiring a table reference without regard to data content

SYSFIELDS Information on field procedures implemented for DB2 tables

SYSFOREIGNKEYS Information about all columns participating in foreign keys

SYSINDEXES Information about every DB2 index

SYSINDEXPART Information about the physical structure and storage of every DB2 index

SYSINDEXSTATS Partitioned index statistics by partition

SYSKEYS Information about every column of every DB2 index

SYSLINKS Information about the links between DB2 Catalog tables

SYSLOBSTATS Statistical information for LOB tablespaces

SYSPACKAGE Information about every package known to DB2

SYSPACKAUTH Package privileges held by DB2 users

SYSPACKDEP A cross-reference of DB2 objects required for DB2 packages

SYSPACKLIST The package list for plans bound specifying packages

SYSPACKSTMT All SQL statements contained in each DB2 package

SYSPARMS Parameters for defined routines

SYSPKSYSTEM The systems (such as CICS, IMS or batch) enabled for DB2 packages

SYSPLAN Information about every plan known to DB2

SYSPLANAUTH Plan privileges held by DB2 users

SYSPLANDEP A cross-reference of DB2 objects required by DB2 plans

SYSPLSYSTEM The systems (such as CICS, IMS, or batch) enabled for DB2 plans

Handout: DB2


C3: Protected

Table Contents SYSPROCEDURES The stored procedures available to the DB2 subsystem

SYSRELS The referential integrity information for every relationship defined to DB2

SYSRESAUTH Resource privileges held by DB2 users

SYSROUTINEAUTH Privileges held by DB2 users on routines

SYSROUTINES Information about every routine (that is, user-defined functions and stored procedures) defined to the DB2 subsystem

SYSSCHEMAAUTH Schema privileges granted to users

SYSSTMT All SQL statements contained in each DB2 plan bound from a DBRM

SYSSTOGROUP Information about every DB2 storage group

SYSSTRINGS Character conversion information

SYSSYNONYMS Information about every DB2 synonym

SYSTABAUTH Table privileges held by DB2 users

SYSTABLEPART Information about the physical structure and storage of every DB2 tablespace

SYSTABLES Information about every DB2 table

SYSTABLESPACE Information about every DB2 tablespace

SYSTABSTATS Partitioned tablespace statistics by partition

SYSTRIGGERS Information about every trigger defined to the DB2 subsystem

SYSUSERAUTH System privileges held by DB2 users

SYSVIEWDEP A cross-reference of DB2 objects required by DB2 views

SYSVIEWS The SQL CREATE VIEW statement for every DB2 view

SYSVLTREE A portion of the internal representation of complex or long views

SYSVOLUMES A cross-reference of DASD volumes assigned to DB2 storage groups

SYSVTREE The first 4000 bytes of the internal representation of the view; the remaining portion of longer or complex views is stored in SYSVLTREE

USERNAMES Outbound and inbound ID translation information

When a CREATE, DROP or ALTER statement is issued, information is recorded or updated in the DB2 Catalog. The same is true for security SQL data control language statements. The GRANT and REVOKE statements cause information to be added or removed from DB2 Catalog tables. Data manipulation language SQL statements use the DB2 Catalog to ensure that the statements accurately reference the DB2 objects being manipulated.

Handout: DB2

Following figure shows the effect of DDL on the DB2 catalog:


C3: Protected

Handout: DB2

Following figure shows the effect of DCL on the DB2 catalog:

DB2 Directory

DB2 uses a second dictionary-like structure in addition to the DB2 Catalog. This is the DB2 Directory. This is used for storing detailed, technical information about aspects of DB2's operation and DB2 Directory is for DB2's internal use only.

Summary

Two sets of tables store all the data related to DB2 objects, which are as follows: DB2 Catalog DB2 Directory


1. Explain about the different DB2 Catalog tables. 2. What is a DB2 Directory?


C3: Protected

Handout: DB2


Learning Objectives

After completing the session, you will be able to: Identify the different DB2 Utilities

Utilities - Introduction

DB2 has a comprehensive collection of utility programs to help us organize and administer DB2 databases. DB2 utility programs are divided into four broad categories:

Data Consistency Utilities Backup and Recovery Utilities Data Organization Utilities Catalog Manipulation Utilities

Data Consistency Utilities

Following are the data consistency utilities: CHECK

REPAIR

REPORT

DIAGNOSE

CHECK Utility

The CHECK utility checks the integrity of DB2 data structures. It has the following purposes.

The first is to check referential integrity between two tables, displaying and potentially resolving referential constraint violations by moving the erroneous rows to exception tables.

The second purpose of the CHECK utility is to ensure that data values conform to the check constraints specified for the table.

The third and final purpose is to check DB2 indexes for consistency. This consists of comparing the key values of indexed columns to their corresponding table values, as well as evaluating RIDs (Row Identifiers) in the tables and indexes being checked.

The CHECK utility can delete invalid rows and copy them to an exception table.


C3: Protected

Handout: DB2

Sample JCL code which runs CHECK utility is as follows: Example: //****************************************************************

//*

//* DB2 CHECK DATA UTILITY

//*

//****************************************************************

//*

//UTIL EXEC DSNUPROC,SYSTEM=DSN,UID='CHEKDATA',UTPROC=''

//*

//* UTILITY WORK DATASETS

//*

//DSNUPROC.SORTWK01 DD UNIT=SYSDA,SPACE=(CYL,(5,1))

//DSNUPROC.SORTWK02 DD UNIT=SYSDA,SPACE=(CYL,(5,1))

//DSNUPROC.SORTOUT DD DSN=&&SORTOUT,

// UNIT=SYSDA,SPACE=(CYL,(5,1))

//DSNUPROC.SYSERR DD DSN=&&SYSERR,


//DSNUPROC.SYSUT1 DD DSN=&&SYSUT1,


//DSNUPROC.UTPRINT DD SYSOUT=X

//*

//* UTILITY INPUT CONTROL STATEMENTS

//* This CHECK DATA statement checks DSN8510.DEPT for

//* referential constraint violations, deletes all

//* offending rows, and places them into the exception

//* table, DSN8510.DEPT_EXCPTN.

//*

//DSNUPROC.SYSIN DD *

CHECK DATA TABLESPACE DSN8D61A.DSN8S61D

FOR EXCEPTION IN DSN8610.DEPT

USE DSN8610.DEPT_EXCPTN

SCOPE ALL DELETE YES

/*

REPAIR Utility

The REPAIR utility is designed to modify DB2 data and associated data structures when there is an error or problem. You can use the REPAIR utility to perform the following tasks:

Test DBD (database descriptor) definitions Repair DBDs by synchronizing DB2 Catalog database information with the DB2

Directory DBD definition


C3: Protected

Handout: DB2

o The REPAIR utility can be used to test, maintain, and modify DB2 database information.

o DB2 maintains database information in the DB2 Catalog SYSIBM.SYSDATABASE table.

o An object known as a DBD is also maintained in the DB2 Directory in the SYSIBM.DBD01 table.

Reset a pending status on a table space or index Verify the contents of data areas in table spaces and indexes Replace the contents of data areas in table spaces and indexes Delete a single row from a table space Produce a hexadecimal dump of an area in a table space or index

The REPAIR utility can be used to test, maintain, and modify DB2 database information. DB2 maintains database information in the DB2 Catalog SYSIBM.SYSDATABASE table. An object known as a DBD is also maintained in the DB2 Directory in the SYSIBM.DBD01 table. A sample JCL to REPAIR the DBD for the DSN8D51A sample database is as follows: Example: //****************************************************************

//*

//* DB2 REPAIR UTILITY : : DBD REPAIR

//*

//****************************************************************

//*

//UTIL EXEC DSNUPROC,SYSTEM=DSN,UID='REPRDBD',UTPROC=''

//*


//* The first REPAIR statement builds a DBD based on

//* the DB2 Catalog and compares it to the corresponding

//* DBD in the DB2 Directory.

//* The second REPAIR statement reports inconsistencies,

//* if any exist.

//*


REPAIR DBD TEST DATABASE DSN8D61A

REPAIR DBD DIAGNOSE DATABASE DSN8D61A OUTDDN SYSREC

/*

When the REPAIR utility is executed with the SET option, it can be used to reset copy pending, check pending, and recover pending flags. Pending flags can be set at the partition level, as well as at the table space level. In general, these flags are maintained by DB2 to indicate the status of table spaces and indexes.


C3: Protected

Handout: DB2

When DB2 turns on a flag for a table space or index, it indicates that the object is in an indeterminate state. When the copy pending flag is set, it indicates that the COPY utility must be used to back up the table space or partition to ensure adequate recoverability. Copy pending status is set when unlogged changes have been made to DB2 table spaces, or when a reference to a full image copy is no longer available in the DB2 Catalog. The check pending flag indicates that the CHECK DATA utility should be run because data has been inserted into a table containing a referential constraint without ensuring that the data conforms to the referential integrity. The recover pending flag indicates that the table space or the index must be recovered because a utility operating on that object has ended abnormally, possibly causing inconsistent or corrupted data. The rebuild pending flag indicates that an index does not match the table data and needs to be rebuilt. Sometimes, however, these flags are set by DB2 but the corresponding utility does not need to be run because of other application factors. In this case, the REPAIR SET utility can be run to reset the appropriate pending flag. JCL that can be used to reset check pending, copy pending, and recover pending restrictions for the sample table spaces. It also contains a REPAIR statement to reset the recover pending status for an index on one of the sample tables.

Example: //****************************************************************

//*

//* DB2 REPAIR UTILITY : : RESET PENDING FLAGS

//*

//****************************************************************

//*

//UTIL EXEC DSNUPROC,SYSTEM=DSN,UID='REPRSETP',UTPROC=''

//*


//* 1. The first REPAIR statement resets the copy pending

//* status for the named tablespace.

//* 2. The second REPAIR statement resets the check pending

//* status for two tablespaces.

//* 3. The third REPAIR statement resets the recover pending

//* status for the named tablespace.

//* 4. The fourth and final REPAIR statement resets the

//* copy pending status for the named index.


C3: Protected

Handout: DB2

//*


REPAIR SET TABLESPACE DSN8D61A.DSN8S61E NOCOPYPEND

REPAIR SET TABLESPACE DSN8D61A.DSN8S61E NOCHECKPEND

SET TABLESPACE DSN8D61A.DSN8S61C NOCHECKPEND

REPAIR SET TABLESPACE DSN8D61A.DSN8S61R NORCVRPEND

REPAIR SET INDEX DSN8610.XPROJAC1 NORCVRPEND

/*

REPORT Utility

Two types of reports can be generated with the REPORT utility: The first is a table space set report showing the names of all table spaces and tables

tied together by referential integrity. The second type deals with recovery.

Sample code for REPORT TABLESPACESET utility is as follows:

The input to the utility is a single table space. The output is a report of all related table spaces and tables.

//****************************************************************

//*

//* DB2 REPORT TABLESPACESET UTILITY

//*

//****************************************************************

//*

//UTIL EXEC DSNUPROC,SYSTEM=DSN,UID='REPORTTS',UTPROC=''

//*


//* The REPORT statement generates a report of all objects

//* referentially tied to the named table space

//*


REPORT TABLESPACESET TABLESPACE DSN8D61A.DSN8S61D

/*

DIAGNOSE Utility

The DIAGNOSE utility is an online utility that can be used to diagnose problems, especially problems with other DB2 utilities.


C3: Protected

Handout: DB2

Sample JCL is as follows: //****************************************************************

//*

//* DB2 DIAGNOSE UTILITY

//*

//****************************************************************

//*

//UTIL EXEC DSNUPROC,SYSTEM=DSN,UID='DIAGNOSE',UTPROC=''

//*

//* Display all records in the SYSIBM.SYSUTIL DB2 Directory table

//*


DIAGNOSE DISPLAY SYSUTIL

/*

Backup and Recovery Utilities

Backup and Recovery utilities are: COPY Utility MERGECOPY Utility QUIESCE Utility RECOVER Utility REBUILD INDEX Utility REPAIR Utility REPORT RECOVERY Utility

COPY Utility

The COPY utility is used to create an image copy backup data set for a complete tablespace, a single partition of a tablespace, or a complete indexspace.

It can be executed so that a full image copy or an incremental image copy is created. A full image copy is a complete copy of all the data stored in the tablespace,

tablespace partition, or index being copied. An incremental image copy is a copy of only the tablespace pages that have been

modified due to inserts, updates, or deletes since the last full or incremental image copy.

Sample JCL for a full image copy for a DB2 tablespace: //****************************************************************

//*

//* DB2 COPY UTILITY::FULL COPY

//*

//****************************************************************

//*

//COPY EXEC DSNUPROC,SYSTEM=DSN,UID='FULLCOPY',UTPROC=''


C3: Protected

Handout: DB2

//*

//DSNUPROC.COPY1 DD DSN=CAT.FULLCOPY.SEQ.DATASET1(+1),

// DISP=(MOD,CATLG),DCB=SYS1.MODEL,

// SPACE=(CYL,(5,2),RLSE),UNIT=3390

//DSNUPROC.COPY2 DD DSN=CAT.FULLCOPY.SEQ.DATASET2(+1),

// DISP=(MOD,CATLG),DCB=SYS1.MODEL,

// SPACE=(CYL,(5,2),RLSE),UNIT=3390


COPY TABLESPACE DSN8D61A.DSN8S61D

COPYDDN (COPY1, COPY2)

SHRLEVEL REFERENCE

DSNUM ALL FULL YES

/*

MERGECOPY Utility

The MERGECOPY utility combines multiple incremental image copy data sets into a new full or incremental image copy data set. Sample JCL is as follows. The first control card depicts the merging of image copy data sets for the DSN8D61A.DSN8S61D tablespace into a full image copy. The second control card shows statements that create a new incremental image copy data set for the DSN8D61A.DSN8S61E tablespace. //****************************************************************

//*

//* DB2 MERGECOPY UTILITY

//*

//****************************************************************

//*

//COPY EXEC DSNUPROC,SYSTEM=DSN,UID='MERGCOPY',UTPROC=''

//*


//*

//DSNUPROC.SYSUT1 DD DSN=CAT.SYSUT1,DISP=(MOD,CATLG,CATLG),

// UNIT=SYSDA,SPACE=(CYL,(10,1)),DCB=BUFNO=20

//DSNUPROC.SYSCOPY1 DD DSN=CAT.FULLCOPY.SEQ.DATASETD(+1),

// DISP=(MOD,CATLG),DCB=(SYS1.MODEL, BUFNO=20),

// SPACE=(CYL,(5,1),RLSE),UNIT=TAPE

//DSNUPROC.SYSCOPY2 DD DSN=CAT.INCRCOPY.SEQ.DATASETE(+1),

// DISP=(MOD,CATLG),DCB=(SYS1.MODEL, BUFNO=20),

// SPACE=(CYL,(2,1),RLSE),UNIT=TAPE

//*


//* The first MERGECOPY statement creates a new full

//* image copy for the DSN8D61A.


C3: Protected

Handout: DB2

//* The second statement creates a new incremental copy

//* for the named tablespace.

//*


MERGECOPY TABLESPACE DSN8D61A.DSN8S61D

DSNUM ALL NEWCOPY YES

COPYDDN SYSCOPY1

MERGECOPY TABLESPACE DSN8D61A.DSN8S61E

DSNUM ALL NEWCOPY NO

COPYDDN SYSCOPY2

/*

QUIESCE Utility

The QUIESCE utility is used to record a point of consistency for a tablespace, partition, tablespace set, or list of tablespaces and tablespace sets.

QUIESCE ensures that all tablespaces in the scope of the QUIESCE are referentially intact. Running QUIESCE improves the probability of a successful RECOVER or COPY. Sample JCL for the QUIESCE utility is as follows: //****************************************************************

//*

//* DB2 QUIESCE UTILITY

//*

//* Step 1: STARTUT: Start all tablespaces in the

//* tablespace set in utility-only mode.

//* Step 2: QUIESCE: Quiesce all tablespaces in the

//* tablespace set.

//* Step 3: STARTRW: Start all tablespaces in the

//* tablespace set in read/write mode.

//*

//****************************************************************

//*

//STARTUT EXEC PGM=IKJEFT01,DYNAMNBR=20

//STEPLIB DD DSN=DSN610.DSNLOAD,DISP=SHR



//SYSOUT DD SYSOUT=*


//SYSTSIN DD *

DSN SYSTEM (DSN)

-START DATABASE (DSN8D61A) ACCESS (UT)

END

/*


C3: Protected

Handout: DB2

//QUIESCE EXEC DSNUPROC,SYSTEM=DSN,UID='QUIESCTS',UTPROC='',

// COND=(0,NE,STARTUT)


QUIESCE TABLESPACE DSN8D61A.DSN8S61C

TABLESPACE DSN8D61A.DSN8S61D

TABLESPACE DSN8D61A.DSN8S61E

TABLESPACE DSN8D61A.DSN8S61R

TABLESPACE DSN8D61A.ACT

TABLESPACE DSN8D61A.PROJ

TABLESPACE DSN8D61A.PROJACT

TABLESPACE DSN8D61A.EMPPROJA WRITE YES

/*

//STARTRW EXEC PGM=IKJEFT01,DYNAMNBR=20,COND=EVEN

//STEPLIB DD DSN=DSN610.DSNLOAD,DISP=SHR

//*



//SYSOUT DD SYSOUT=*


//SYSTSIN DD *

DSN SYSTEM (DSN)

-START DATABASE (DSN8D61A) ACCESS (RW)

END

/*

RECOVER Utility

RECOVER can be used to recover tablespaces or indexes by restoring data from an image copy data set and then applying subsequent changes from the log files. Sample JCL for full recovery to the current point for a tablespace is as follows. //****************************************************************

//*

//* DB2 RECOVER UTILITY :: FULL RECOVERY

//*

//****************************************************************

//*

//RCVR EXEC DSNUPROC,SYSTEM=DSN,UID='FULLRECV',UTPROC=''

//*


//* 1. The first RECOVER statement recovers the

//* DSN8D61A.DSN8S61C tablespace to the current point

//* in time.

//* 2. The second RECOVER statement recovers all indexes

//* in the tablespace.


C3: Protected

Handout: DB2

//*


RECOVER TABLESPACE DSN8D61A.DSN8S61C DSNUM ALL

REBUILD INDEX(ALL) TABLESPACE DSN8D61A.DSN8S61C

/*

REBUILD Utility

This can be used to re-create indexes from current data.

REBUILD INDEX scans the table on which the index is based and regenerates the index based on the current data. Sample JCL is as follows: //****************************************************************

//*

//* DB2 REBUILD INDEX UTILITY

//*

//****************************************************************

//*

//UTIL EXEC DSNUPROC,SYSTEM=DSN,UID='RBLDINDX',UTPROC=''

//*


//*

//DSNUPROC.SORTWK01 DDUNIT=SYSDA,SPACE=(CYL,(2,1))


//DSNUPROC.SYSUT1 DD DSN=&&SYSUT1,



//*


//* 1. The first REBUILD INDEX statement rebuilds the

//* DSN8610.XPROJ2 index.

//* 2. The second REBUILD INDEX statement rebuilds only

//* the third partition of the DSN8610.XEMP1

//* partitioning index.

//* 3. The third and final REBUILD INDEX statement

//* rebuilds all indexes on all tables in the

//* DSN8D61A.DSN8S61C tablespace.

//*


REBUILD INDEX (DSN8610.XPROJ2)

REBUILD INDEX (DSN8610.XEMP1) DSNUM 3

REBUILD INDEX (ALL) TABLESPACE DSN8D61A.DSN8S61C

/*


C3: Protected

Handout: DB2

REPORT RECOVERY Utility

The REPORT RECOVERY utility is the second type of REPORT utility provided by DB2. It can be used to generate a report on tablespace recovery information. //****************************************************************

//*

//* DB2 REPORT RECOVERY UTILITY

//*

//****************************************************************

//*

//UTIL EXEC DSNUPROC,SYSTEM=DB2T,UID='REPORTRC',UTPROC=''


REPORT RECOVERY TABLESPACE DSN8D61A.DSN8S61E

/*

Summary

The Data Consistency utilities are: CHECK

REPAIR

REPORT

DIAGNOSE

The Backup and Recovery utilities are: COPY Utility MERGECOPY Utility QUIESCE Utility RECOVER Utility REBUILD INDEX Utility REPAIR Utility REPORT RECOVERY Utility


1. Explain about the different utilities of the category “Data Consistency”. 2. Explain about the different utilities of the category “Backup and Recovery”.


C3: Protected

Handout: DB2


Learning Objectives

After completing the session, you will be able to: Describe DB2 utilities Identify DB2 commands

Data Organization Utilities

The data organization utilities affect the physical data sets of the DB2 objects for which they are run. Rows of data and their sequence are affected by these utilities. The data organization utilities are as follows:

LOAD Utility REORG Utility

LOAD Utility

The LOAD utility is used to accomplish bulk inserts to DB2 tables. It can add rows to a table, retaining the current data, or it can replace existing rows with the new data. Sample LOAD JCL is as follows: Example: //* DB2 LOAD UTILITY (RESTARTABLE)

//*

//****************************************************************

//*

//UTIL EXEC DSNUPROC,SYSTEM=DSN,UID='LOADDATA',UTPROC=''

//*

//* UTILITY WORK DATAETS

//*



//DSNUPROC.SORTOUT DD DSN=CAT.SORTOUT,DISP=(MOD,CATLG,CATLG),


//DSNUPROC.SYSMAP DD DSN=CAT.SYSUT1,DISP=(MOD,DELETE,CATLG),


//DSNUPROC.SYSUT1 DD DSN=CAT.SYSUT1,DISP=(MOD,DELETE,CATLG),


//DSNUPROC.SYSDISC DD DSN=CAT.SYSDISC,DISP=(MOD,DELETE,CATLG),


//DSNUPROC.SYSERR DD DSN=CAT.SYSERR,DISP=(MOD,DELETE,CATLG),



C3: Protected

Handout: DB2

//DSNUPROC.SYSREC00 DD DSN=CAT.LOAD.INPUT.DATASETA,DISP=SHR,DCB=BUFNO=20


//*


//* The LOAD statement reloads the DSN8610.ACT table

//*


LOAD DATA REPLACE INDDN SYSREC00 LOG NO

INTO TABLE DSN8610.ACT

(ACTNO POSITION ( 1 ) SMALLINT,

ACTKWD POSITION ( 3 ) CHAR ( 6 ),

ACTDESC POSITION ( 9 ) VARCHAR

)

/*

REORG Utility

The REORG utility can be used to reorganize DB2 tablespaces and indexes, thereby improving the efficiency of access to those objects. Reorganization is required periodically to ensure that the data is situated in an optimal fashion for subsequent access. The sample REORG JCL is as follows: Example: //****************************************************************

//*

//* DB2 REORG UTILITY (RESTARTABLE)

//*

//****************************************************************

//*

//UTIL EXEC DSNUPROC,SYSTEM=DSN,UID='REORGTS',UTPROC=''

//*


//*



//DSNUPROC.SORTOUT DD DSN=CAT.SORTOUT,DISP=(MOD,DELETE,CATLG),


//DSNUPROC.SYSUT1 DD DSN=CAT.SYSUT1,DISP=(MOD,DELETE,CATLG),


//DSNUPROC.SYSREC DD DSN=OUTPUT.DATASETD,DISP=(MOD,CATLG,CATLG),

UNIT=SYSDA,SPACE=(CYL,(15,5)),DCB=BUFNO=20

//DSNUPROC.SYSPRINT DD SYSOUT=*

//DSNUPROC.UTPRINT DD SYSOUT=*

//*


C3: Protected

Handout: DB2


//* The REORG statement reorganizes the second partition

//* of DSN8D61A.DSN8S61E.

//*


REORG TABLESPACE DSN8D61A.DSN8S61E PART 2

/*

Catalog Manipulation Utilities

Following are the Catalog Manipulation Utilities: CATMAINT Utility MODIFY Utility MODIFY RECOVERY Utility RUNSTATS Utility STOSPACE Utility

CATMAINT Utility

The CATMAINT utility is used when migrating from one version or release of DB2 to another. It changes the structure of the DB2 Catalog by altering and creating DB2 tables and indexes using the special links and hashes in the DB2 Catalog database. The CATMAINT utility modifies the DB2 Catalog objects in place.

MODIFY Utility

The MODIFY utility is used to delete rows from DB2 Catalog and DB2 Directory tables. MODIFY is the clean-up utility. When COPY information in the DB2 Catalog or DB2 Directory is no longer relevant or desirable, MODIFY can be used to delete the unwanted rows. The MODIFY RECOVERY utility deletes rows related to data recovery from both the DB2 Catalog and DB2 Directory.

RUNSTATS Utility

The RUNSTATS utility collects statistical information for DB2 tables, tablespaces, partitions, indexes, and columns. It can place this information into DB2 Catalog tables or simply produce a report of the statistical information. The statistics in these tables are used for two primary reasons:

To provide organizational information for DBAs To be used as input to the DB2 optimizer during the BIND process to determine

optimal access paths for SQL queries. The statistical information can also be queried using SQL.


C3: Protected

Handout: DB2

Sample RUNSTATS TABLESPACE JCL: //****************************************************************

//*

//* DB2 RUNSTATS TABLESPACE UTILITY

//*

//****************************************************************

//*

//UTIL EXEC DSNUPROC,SYSTEM=DSN,UID='STATSTS',UTPROC=''

//*


//* 1. The first statement accumulates statistics for the

//* given tablespace based on the named index columns.

//* 2. The second statement accumulates statistics only for

//* the named table and columns in the named tablespace.

//*


RUNSTATS TABLESPACE DSN8D61A.DSN8S61D

INDEX (ALL) SHRLEVEL REFERENCE

RUNSTATS TABLESPACE DSN8D61A.DSN8S61E

TABLE (DSN8610.EMO)

COLUMN (FIRSTNME,MIDINIT,LASTNAME,SALARY,BONUS,COMM)

SHRLEVEL REFERENCE

/*

STOSPACE Utility

The STOSPACE utility is executed on a STOGROUP or list of STOGROUPs. It populates the DB2 Catalog with tablespace and index data set DASD usage statistics. Sample JCL for STOSPACE utility. Example: //****************************************************************

//*

//* DB2 STOSPACE UTILITY

//*

//****************************************************************

//*

//UTIL EXEC DSNUPROC,SYSTEM=DSN,UID='STOSPACE',UTPROC=''


STOSPACE STOGROUP (*)

/*


C3: Protected

Handout: DB2

DB2 Commands

DB2 commands are operator-issued requests that administer DB2 resources and environments. You will introduce you about some commands which may be useful for Developer’s point of view. You can execute DB2 commands either through online (DB2I) or through batch. In order to execute DB2 commands through DB2I, choose the option “DB2 COMMANDS” in “DB2I PRIMARY OPTION MENU”

DB2 Commands


C3: Protected

Handout: DB2

Execute the commands as follows:

Enter DB2 Command to be executed

Following is the JCL needed to issue the command in a batch job. //****************************************************************

//*

//* JCL TO ISSUE DB2 COMMAND

//*

//****************************************************************

//*

//JOBLIB DD DSN=DSN510.DSNLOAD,DISP=SHR

//BATCHCOM EXEC PGM=IKJEFT01,DYNAMNBR=20




//SYSTSIN DD *

DSN SYSTEM(DSN)

- DISPLAY DATABASE (DSNDB06)

END

/*


C3: Protected

Handout: DB2

Following is the list of information-gathering DB2 environment commands. This can be used to monitor DB2 objects and resources. They can return the status of DB2 databases, threads, utilities, and traces, as well as monitor the Resource Limit Facility and distributed data locations. The DISPLAY command is used for information gathering.

Command Description -DISPLAY ARCHIVE Displays input archive log information.

-DISPLAY BUFFERPOOL Displays the current status of active and/or inactive bufferpools.

-DISPLAY DATABASE Displays the status and pending information for DB2 databases, tablespaces, and indexes.

-DISPLAY DATABASE LOCKS Displays the locks for the DB2 databases, tablespaces, and indexes (including transaction locks and drain locks). An option for the command, CLAIMS, shows claims that are being held on a resource.

-DISPLAY FUNCTION SPECIFIC Displays statistics about external DB2 user-defined functions.

-DISPLAY GROUP Displays information about the data sharing group.

-DISPLAY GROUPBUFFERPOOL Displays information about the status of DB2 group bufferpools.

-DISPLAY LOCATION Displays information for distributed threads.

-DISPLAY LOG Displays information about the DB2 logs and the status of the log offload task.

-DISPLAY PROCEDURE Displays information about stored procedures.

-DISPLAY RLIMIT Displays the status of the Resource Limit Facility, including the ID of the active RLST (Resource Limit Specification Table).

-DISPLAY THREAD Displays active and in-doubt connections to DB2 for a specified connection or all connections.

-DISPLAY TRACE Displays a list of active trace types and classes along with the specified destinations for each; consult Chapter 22, "Traditional DB2 Performance Monitoring," for a discussion of DB2 trace types and classes.

-DISPLAY UTILITY Displays the status of all active, stopped, or terminating utilities.

DSN Commands: DSN (Data Source Name) is a control program that enables users to issue DB2 environment commands, plan management commands, and commands to develop and run application programs. DSN commands can be run in TSO (Time Sharing Option) foreground, either directly or indirectly, or in TSO background. DSN command can be issued in foreground through DB2I. DSN commands can be issued in the background with the IKJEFT01 terminal monitor program.


C3: Protected

Handout: DB2

There are nine DSN commands as follows:

Command Description DSN A command processor that enables the user to issue DB2 environment commands

from a TSO session or in a batch job. The DSN command processor must be invoked before any DSN command that follows can be issued.

ABEND Used to request and obtain a dump when problems are suspected with another DSN subcommand.

BIND Builds an application plan or package from one or more database request modules.

DCLGEN Produces the SQL DECLARE TABLE specification and a working storage data declaration section for COBOL

END Terminates the DSN session and returns the user to TSO.

FREE Deletes application plans and packages.

REBIND Rebuilds an application plan or package when SQL statements in a program's DBRM have not been changed. REBIND also can modify the BIND parameters.

RUN Executes an application program. The program can contain SQL statements, but this is not required.

SPUFI Executes the SPUFI program. This subcommand can be issued only when processing under ISPF; it cannot be submitted in a batch job.

Summary

The data organization utilities are: LOAD Utility REORG Utility

The Catalog Manipulation utilities are: CATMAINT Utility MODIFY Utility MODIFY RECOVERY Utility RUNSTATS Utility STOSPACE Utility

You have seen about the following DB2 Commands: DB2 environment commands that gather information DSN Commands


1. Explain about the different utilities under the category of Data Organization. 2. Explain about the different utilities under the category of Catalog Manipulation. 3. Explain about different DB2 commands.


C3: Protected

Handout: DB2


Learning Objectives

After completing the session, you will be able to: Explain the features of dynamic SQL Explain application program using dynamic SQL Describe the performance of static and dynamic SQL

Dynamic SQL - Introduction

Static SQL is hard-coded, and only the values of host variables in predicates can change. Dynamic SQL is characterized by its capability to change columns, tables, and predicates during a program's execution. In dynamic SQL, the SQL statements are prepared and executed within a program while the program is running. The SQL source is contained in host language variables rather than being written into the application program. The SQL statement can change several times while the program is running and the Optimization will be performed at run time. Performance of dynamic SQL is poorer than that of static SQL. In general, dynamic SQL is less efficient than static SQL.

Dynamic SQL - Types

Four classes of dynamic SQL are as follows: Execute immediate SQL Non-select dynamic SQL Fixed-list select SQL Varying-list Select SQL

When to use Dynamic SQL

Consider using dynamic SQL under the following conditions: When the nature of the application program is truly changeable, not just a series of

static SQL statements When the columns to be retrieved can vary from execution to execution When the predicates can vary from execution to execution When benefit can be accrued from interacting with other dynamic SQL applications,

for example, using the QMF (Query Management Facility) callable interface

Execute Immediate SQL

“Execute Immediate” SQL statement implicitly prepares and executes complete SQL statements coded in host variables. This cannot use select statement, which implies that data cannot be retrieved from tables.


C3: Protected

Handout: DB2

Steps for constructing a program containing execute immediate: Accept into or move SQL statement to Host Variable. Issue “EXECUTE IMMEDIATE” statement specifying host variable as argument.

Sample code to delete rows from a table

IDENTIFICATION DIVISION.

.

.


.

.

EXEC SQL

INCLUDE SQLCA

END-EXEC.

.

.

01 HV-STAT.

49 HV-STAT-LEN PIC S9(4) COMP.

49 HV-STAT-TEXT PIC X(100).

PROCEDURE DIVISION.

MOVE +45 TO HV-STAT-LEN.

MOVE “DELETE FROM STORES

WHERE STOR_ID = ‘A123‘ “ to HV-STAT-TEXT.

EXEC SQL

EXECUTE IMMEDIATE :HV-STAT

END-EXEC.

The delete statement in the above program can be replaced by any of the following:

CREATE

ALTER

DROP

EXPLAIN

GRANT

REVOKE

INSERT

SET

UPDATE

LOCK TABLE

COMMIT

ROLLBACK


C3: Protected

Handout: DB2

Non-select dynamic SQL

This includes PREPARE and EXECUTE statements to issue SQL statements. This cannot use Select statement, which implies that data cannot be retrieved from tables. A sample program using non-select dynamic SQL to delete records from a table is as follows: IDENTIFICATION DIVISION.

.


.

.

EXEC SQL

INCLUDE SQLCA

END-EXEC.

.

.

01 HV-STAT.



PROCEDURE DIVISION.



WHERE STOR_ID = ‘A123‘ “ to HV-STAT-TEXT.

EXEC SQL

PREPARE STMT1 FROM :HV-STAT;

END-EXEC.

EXEC SQL

EXECUTE STMT1

END-EXEC.

The delete statement in the above program can be replaced by any of the following:

CREATE

ALTER

DROP

INSERT

SET

UPDATE

COMMIT

ROLLBACK

GRANT

REVOKE

EXPLAIN

LOCK


C3: Protected

Handout: DB2

Parameter marker

Non-select dynamic SQL can use a powerful feature of dynamic SQL known as parameter marker, which is a placeholder for host variables in a dynamic SQL statement because dynamic SQL cannot contain host variables. Sample Program: In this program, a question mark (?) is used as a parameter marker, replacing the ‘A123’ in the predicate. When the statement is executed, a value is moved to the host variable (:TVAL) and is coded as a parameter to the Execute statement with the USING clause. When executed, the host variable value replaces the parameter marker IDENTIFICATION DIVISION.

.


.

EXEC SQL

INCLUDE SQLCA

END-EXEC.

.

.

01 HV-STAT.



PROCEDURE DIVISION.



WHERE STOR_ID = ? “ to HV-STAT-TEXT.

EXEC SQL

PREPARE STMT1 FROM :HV-STAT;

END-EXEC.

MOVE ‘A123‘ TO TVAL.

EXEC SQL

EXECUTE STMT1 USING :TVAL;

END-EXEC.

Fixed-list select

This is used to explicitly prepare and execute SQL select statements when the columns to be retrieved by the application program are known and unchanging. It is necessary to create proper working-storage declaration for variables in the program


C3: Protected

Handout: DB2

Varying-list select SQL

This is used to explicitly prepare and execute SQL Select statements when the columns to be retrieved in the application program are unknown. This provides flexibility for dynamic Select statements. This can change tables, columns, predicates on the fly. Since everything about the query can change during one invocation of the program, the number and type of host variables needed to store the retrieved rows cannot be known beforehand. Varying-list select statements are very complicated to be executed Note: Dynamic SQL statements are bound during runtime unlike the static SQL statements. Static SQL should be sufficient for the programming needs of at least 90% of the applications you develop. If static SQL does not provide enough flexibility for the design of changeable SQL statements, consider using dynamic SQL.

Summary

The dynamic SQL statements are prepared and executed within a program while the program is running. The four classes of dynamic SQL are:

Execute immediate SQL: Implicitly prepares and executes complete SQL statements coded in host variables

Non-select dynamic SQL: Includes PREPARE and EXECUTE statements to issue SQL statements

Fixed-list select SQL: Used to explicitly prepare and execute SQL select statements when the columns to be retrieved by the application program are known and unchanging

Varying-list select SQL: Used to explicitly prepare and execute SQL Select statements when the columns to be retrieved in the application program is unknown


1. Explain about the dynamic SQL programming.


C3: Protected

Handout: DB2


Learning Objectives

After completing this session, you will be able to: Describe Stored Procedure

Stored Procedure - Introduction

Stored procedures are specialized programs that are executed under the control of the relational database management system. Stored procedures are as similar to other database objects such as tables, views, and indexes. A stored procedure must be directly and explicitly invoked before it can be executed. The major uses of the stored procedures are as follows:

Reusability Consistency Data integrity Maintenance Performance Security

Stored Procedure - Development

You can design and develop stored procedures in a similar manner to the way you develop any other application program. LE/370 is mandatory for the use of stored procedures.

Parameters o Parameters are essential to the effective use of stored procedures. o Parameters allow data to be sent to and received from a stored procedure. o We must define parameters in the LINKAGE SECTION. o Be sure to set all input parameters to an appropriate value in the calling program

prior to issuing the CALL to the stored procedure. Result Set

o A stored procedure can return multiple row result sets back to the calling program. o The RESULT_SETS parameter is specified on the CREATE or ALTER PROCEDURE

statement and indicates the maximum number of result sets that can be returned by the stored procedure.

o To enable the stored procedure to return result sets, we must set the RESULTS SET parameter to a value greater than 0.

o We need to specify the WITH RETURN clause on each OPEN cursor statement for which result sets are to be returned.

o The cursors must not be closed by the stored procedure.


C3: Protected

Handout: DB2

You need to code the calling program to accept the result sets from the stored procedure: o The calling program should declare a result set locator variable. o The calling program issues the CALL to execute the stored procedure. o The calling program issues the ASSOCIATE LOCATOR statement to assign a value

to the result set locator that was previously defined. o The calling program then issues the ALLOCATE CURSOR statement to associate

the query with the result set. o Finally, the program can execute a loop to FETCH the rows of the result set. o Special SQL statements—DESCRIBE PROCEDURE and DESCRIBE CURSOR are

available when the calling program does not know in advance the number of result sets that a stored procedure can return.

Preparing Stored Procedure Programs o The program code must be precompiled, compiled, and then link-edited into an

executable form. o The DBRM must be bound into a package; no plan is required for the stored

procedure. o When the program is link-edited, the LE/370 program library must be included. o No impact to the program preparation process is required for the calling program o A plan is still required for the calling program. Only the stored procedure (the

called program) does not require a plan.

Creating Stored Procedures

Stored procedures are registered and managed within DB2 like other DB2 objects, using standard DDL statements—ALTER, CREATE and DROP. CREATE PROCEDURE SYSPROC.PROCNAME(INOUT CHAR(20))

LANGUAGE COBOL

EXTERNAL NAME LOADNAME

PARAMETER STYLE GENERAL

NOT DETERMINISTIC

MODIFIES SQL DATA

WLM ENVIRONMENT WLMNAME

STAY RESIDENT YES

RESULT SETS 1;

This statement creates a stored procedure named PROCNAME in the SYSPROC schema using an external load module name of LOADNAME. The stored procedure is written in COBOL and runs in WLM-managed SPAS. It returns one result set. The parameters to be used by DB2 stored procedures must be specified in parentheses after the procedure name in the CREATE PROCEDURE statement. You can define three types of parameters:

IN: An input parameter OUT: An output parameter INOUT: A parameter that is used for both input and output


C3: Protected

Handout: DB2

Managing Stored Procedures

After you have registered the stored procedure to DB2, you must start it by using a DB2 command: -START PROCEDURE(procedure name)

A stored procedure cannot be executed until it has first been started. To disable subsequent executions of the named stored procedure. -STOP PROCEDURE(procedure name) ACTION(REJECT | QUEUE)

You can specify the ACTION parameter to indicate whether future attempts to run the

stored procedure will be entirely rejected or queued to be run when the stored procedure is started again.

You can use the DISPLAY command to monitor the status of stored procedures. -DISPLAY PROCEDURE(procedure name)

To run a stored procedure, you must explicitly issue a CALL statement in the application program. EXEC SQL

CALL SAMPLE('ABC')

END-EXEC.

This calls a stored procedure named SAMPLE, sending a literal string as a parameter.

Executing a Stored Procedures

Stored procedures run in a separate DB2 address space known as the Stored Procedure Address Space (SPAS). You can use multiple stored procedure address spaces. Doing so requires the use of the MVS Workload Manager (WLM). WLM allows stored procedures to be isolated in a particular address space based on the type of processing being performed. To execute a stored procedure, a program must issue the SQL CALL statement. When the CALL is issued, the name of the stored procedure, its schema name, and its list of parameters are sent to DB2. DB2 searches SYSIBM.SYSROUTINES for the appropriate row that defines the stored procedure to be executed. If the row is not found, the stored procedure does not run. If the row is found, DB2 retrieves the pertinent information, including the actual load module, to allow the stored procedure to execute. DB2 then finds a TCB (Task Control Block) to use for the stored procedure in the appropriate SPAS and indicates to the SPAS that the stored procedure is to be executed. The SPAS reuses the thread of the calling program to run the stored procedure. The stored procedure runs, assigns values to input/output and output parameters, and returns control to the calling program. The calling program receives the input/output and output parameters and continues processing. The entire processing within the stored procedure is within the same unit of work as the CALL in the calling program. Locks acquired within the stored procedure continue to be held until released by the calling program (with a COMMIT or ROLLBACK).


C3: Protected

Handout: DB2

Summary

Stored procedures are a powerful feature of DB2. They enable you to execute multiple data access statements with a single request. Additionally, they are controlled and managed by DB2, providing a consistent and

reusable point of reference for frequently executed database code.


1. Explain about how to develop, create, and execute stored procedures.


C3: Protected

Handout: DB2

Glossary This glossary describes the major terms as you have used them within the context of this hand out. Aggregate Functions: These are functions that operate on a set of rows to calculate and return a single value. Alias: Alias is an alternative name for a table or view which can reside in the local or remote DB2 subsystem. It can be used by anyone including its creator and is not dropped even when it’s corresponding Table/View is dropped. Bind: To get the runtime executable for the SQL part of the application program. Tasks of Bind are as follows:

Authorization Check Syntax Check Optimization

Buffer Pool: Buffer Pools are areas of virtual storage in which DB2 temporarily stores pages of table spaces or indexes. CASCADE: It allows the deletion of the primary key row and also deletes the foreign key rows that relate to it. Cardinality: This refers the type of relationship between the entities. They are One-to-one relationships One-to-many and many-to-one relationships Many-to-many relationships Check Constraint: A check constraint is a rule that specifies the values that are allowed in one or more columns of every row of a table. Clustered Index: The leaf level (the lowest level of the tree) is the data and for a table that has a clustered index, the data is actually stored in the order of the index. Collection: A collection is a user-defined name from 1 to 18 characters that the programmer must specify for every package. COMMIT: When a program issues an INSERT, UPDATE or DELETE statement, DB2 does not immediately write the table modification to disk. It logs the changes in a dataset and keeps track of the changes in virtual storage buffers. When it reaches the commit point it writes the logged changes to the disk. Composite Key: If a primary key is made up of more than one attribute, then it is called as “Composite Key”.


C3: Protected

Handout: DB2

Consistency Token: As the “Modified Source Code” and “DBRM” will take different paths to get the runtime executables, in order to identify the correct pair during execution, the precompiler attaches timestamp both in “Modified Source Code” and in “DBRM” and is called “Consistency Token”. Cursor: You have to use cursors to process a result table that contains more than one row in a COBOL program. A cursor is a pointer that identifies the current row in a result table. Database: A database is a collection of data stored in some organized fashion. Database Model: A database model refers to the way a DBMS organizes information internally. The major DBMS database models are:

Hierarchical Network Relational

DBRM: During precompilation, all of the SQL that are embedded in a COBOL-DB2 application program is stripped out of the program and put into its own partitioned data set member, called a DBRM (Data Base Request Module) DBMS: A Database Management System (DBMS) is a set of programs designed for the purpose of managing databases. DB2: DB2 or Database 2 is a Relational Database Management System offered by IBM that runs on IBM Mainframe, AS/400 and PC. DB2 Catalog: The knowledge base of every object known to DB2 is stored in the DB2 Catalog. DB2 Commands: DB2 commands are operator-issued requests that administer DB2 resources and environments. DB2 Utilities: DB2 has a comprehensive collection of utility programs to help us organize and administer DB2 databases. DB2I: It is DB2 Interactive and is a TSO-based DB2 application. DCL: It is a Data Control Language which manipulates data using the following statements.

GRANT: Privileges to a user to access a DB2 object REVOKE: Take away a certain privilege from a user

DCLGEN: Deceleration Generator (DCLGEN), is the utility that comes with DB2 which generates the host structure for a table.


C3: Protected

Handout: DB2

DDL: It is a Data Definition Language which creates and maintains physical data structures using the following statements.

Create: Creating the objects. Alter: Changing the characteristics of the existing objects. Drop: Deleting the objects.

Deadlock: A deadlock occurs when two separate processes compete for resources held by one another. Denormalization: Denormalization is the intentional duplication of columns in multiple tables, and the consequence is increased data redundancy and is recommended to avoid performance problems occur as a result of normalization. DISTINCT: SQL uses DISTINCT to remove duplicates from the result set. DML: It is a Data Manipulation Language which manipulates data using the following statements.

INSERT: Populate the data into table or view UPDATE: Update the data in the table or view DELETE: Delete the data from table or view SELECT: Columns or expressions to be returned

Domain integrity: It defines the possible values of a column and is enforced using

Data Type and Length

Default Values

NULL Values

Check constraint

DSNTIAR: It is an “Error Reporting Routine” supplied by IBM for DB2. Dynamic SQL: The SQL statements are prepared and executed within a program while the program is running. Embedded SQL: SQL statements which are being embedded in the COBOL program are referred as “Embedded SQL”. Entity: It is the significant objects of interest Entity integrity: It means that each occurrence of an entity must be uniquely identifiable and it requires the specification of a primary key (PK) for each table. E-R Diagram: An entity-relationship (ER) diagram is a specialized graphic that illustrates the interrelationships between entities in a database of a Logical data modeling. EXPLAIN: You can use the EXPLAIN feature to detail the access paths chosen by the DB2 optimizer for SQL statements.


C3: Protected

Handout: DB2

GROUP BY: Grouping divides the data into logical sets so that we can perform aggregate calculations on each group. Host Structure: An area of storage is allocated by the host language (COBOL) and referenced in an SQL statement, in order to receive the data that is returned for a row or hold the data to update or add a row to a table. Index: It is an ordered set of pointers to rows in a base table. Index Space: This represents an index correlates to one or more VSAM data sets in the DASD volumes of storage Group. IRLM: Locking process is controlled by DB2’s IRLM (Inter System Resource Lock Manager) ISOLATION level Bind parameters affecting page and row Locks:

Repeatable Read (RR): This holds page and row locks until a COMMIT point is reached. No other program can modify the data.

Read Stability (RS): This holds page and row locks until a COMMIT point is reached. But other programs can INSERT new data.

Cursor Stability (CS): This acquires and releases page or row locks as pages or rows are read and processed. This provides the greatest level of concurrency

Uncommitted Read (UR): This is also known as dirty read processing. UR avoids locking altogether.

JOIN: A join is a mechanism used to associate tables within a SELECT statement. Types of Joins are as follows:

Inner Join: Inner Joins or Equi Joins are joins which include only the rows where the values in the joined columns match.

Outer Join: Outer Joins keep unmatched rows from the tables. o Types of Outer Join:

Left Outer Join Right Outer Join Full Outer Join

Lock duration: Lock duration refers to the length of the time that a lock is maintained. Lock Escalation: If the number of locks in one level exceeds an installation default, DB2 locks a larger unit. This is called Lock escalation. Lock Mode: Lock Mode determines what the program that owns the lock and what concurrent programs can do with the locked resource. Non-clustered Index: The leaf contains bookmarks to the actual data and the bookmarks in non-clustered indexes are in RID format (Row ID), that is, direct pointers to the physical location the row is stored in.


C3: Protected

Handout: DB2

Normalization: It is the process of decomposing large tables into smaller tables to reduce the redundancy and inconsistency. Normal Form: It is a series of guidelines developed by the database community for ensuring that databases are normalized.

First Normal Form: o All entities must have a unique identifier, or key, that can be composed of one or

more attributes o Eliminate repeating groups and non-atomic data from an entity.

Second Normal Form: o Should be in First Normal Form o Every non-key attribute is fully dependent on the key

Third Normal Form: o Should be in Second Normal Form o Every non-key attribute is non-transitively dependent on the primary key that is,

every attribute in the entity should depend only on the key not on any other non-key attributes.

NULL Values: A null value is a special value that DB2 interprets to mean that no data is present. It is an unknown value and is not zero or blank Null Indicator: In order to determine whether the column value is null, we need to use an indicator variable in the COBOL program. Operator: A special keyword used to join or change clauses within a WHERE clause. This is also known as logical operators. Optionality: It is the types of Participation. They are as follows:

Mandatory Optional

Optimization: The most important BIND task is to come up with run-time instructions for the SQL in the DBRM. Package: A package is a single, bound DBRM with optimized access paths. By using packages, the table access logic is "packaged" at a lower level of granularity, at the program level. Plan: A plan is an executable module containing the access path logic produced by the DB2 optimizer. It can be composed of one or more DBRMs and packages.


C3: Protected

Handout: DB2

Precompilation: Tasks of Pre-compiler are as follows:

Expansion of “INCLUDE” Syntax Check Splitting the Program

o Modified Source Code” which is the COBOL with all of the SQL commented out and replaced with the equivalent COBOL Calls.

o “DBRM” which contains only SQL Primary Key: A primary key is a unique identifier for an Entity QMF: It is a Query Management Facility and is an interactive query tool used to produce formatted query output. RDBMS: Relational Database Management System is a type of database management system (DBMS) that stores data in the form of related tables. Referential integrity (RI): It is a database concept that ensures that the relationships between tables remain consistent and it means each row in a dependent table must have a foreign key that is equal to a primary key in the parent table. (The table with the primary key is called parent table and the table with the foreign key is called dependent table (or child table)). Relationships: A connection established between a pair of tables is known as a relationship. RESTRICT: It disallows the deletion of the primary key row if any foreign keys relate to that row. ROLLBACK: DB2 rolls back (or reverses) all of the transactions in the unit of recovery when a program terminates abnormally or when a program issues a ROLLBACK statement. SET TO NULL: It allows the deletion of the primary key row and, instead of deleting all related foreign key rows, sets the foreign key columns to NULL. SQL: It is a Structured Query Language and is a language designed specifically for communicating with databases. SQLCA: While executing the application program, we need the information of describing the success or failure of the execution of an embedded SQL statement. For this purpose, we must include a structure called SQLCA (SQL Communication Area) in each DB2 application program. SQLCODE: The field SQLCODE in SQLCA, contains the return code passed by DB2 to the application program. SPUFI: It is SQL Processor Using File Input and is intended primarily for application programmers who wish to test the SQL portions of their programs, or administrators who wish to perform SQL operations.


C3: Protected

Handout: DB2

Storage Group: It is a set of volumes on DASD which contains VSAM datasets. Stored procedure: Stored procedures are specialized programs that are executed under the control of the relational database management system. Subquery: Subqueries are used to combine different queries into one single statement. Types of subqueries:

Non-correlated subquery: In the subquery if the inner query and the outer query work independently, then the subquery is called Non-correlated subquery.

Correlated subquery: In correlated subquery, the inner query does not work independently of the outer query. In this, the inner query is performed once for each row of the outer query

Suspension: When an application requests a lock that is already held by another process, and the lock cannot be shared, that application is suspended. Synonym: This is an alternative name for a table or view which should reside in the local DB2 subsystem. This can be used only by its creator and is dropped when it’s corresponding Table/View is dropped. Table Space: This represents one or more tables correlates to one or more VSAM data sets in the DASD volumes of storage Group. Types of table space:

Simple Table Space: In a simple table space, the space is divided into pages without any higher level structure.

Segmented Table Space: In a segmented table space, the space is divided into equal sized group of pages called “Segments”.

Partitioned Table Space: In the partitioned table space, the space is divided into units called “Partitions”.

Table: Table consists of data logically arranged in columns and rows. Timeout: When an application has been suspended for a predetermined period of time, it will be terminated. When a process is terminated because it exceeds this period of time, it is said to time out. UNION: Using UNION, multiple SELECT statements can be specified, and their results can be combined into a single result set. Unique Constraint: A unique constraint is similar to a primary key constraint which also enforces unique values on an individual or a group of columns. The only difference is a table can contain multiple unique constraints. Unique Index: In order to ensure uniqueness either in the Primary key constraint or in the unique constraint, in DB2 unique index need to be created explicitly after creating the table and before using the table.


C3: Protected

Handout: DB2

Unit of Work or Unit of Recovery: This consists of the transactions that are logged between two commit points. Version: When using packages, we can keep multiple versions of a single package that refer to different versions of the corresponding application program. View: It is a virtual table that accesses data from one or more tables or views. Wildcard Filtering: Wildcards are special characters used to match parts of a value and to use wildcards in search clauses; the LIKE operator must be used. Wildcard searching can be used only with text fields (strings).The Percent Sign (%) Wildcard means match any number of occurrences of any character. The underscore (_) is used to match a single character.


C3: Protected

Handout: DB2

References

Websites

http://publib.boulder.ibm.com

Books

DB2 Developer’s Guide by Craig Mullins An Introduction to Database Systems by C. J Date Database Administration: The Complete Guide to Practices and Procedures by Craig

S. Mullins DB2 for the COBOL Programmer by Curtis Garvin and Steve Eckols


C3: Protected

Handout: DB2


C3: Protected

STUDENT NOTES:

Documents

DB2 Handout v1.0