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
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 Learning Objectives ....................................................................................................................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 Test Your Understanding............................................................................................................38 Exercises ....................................................................................................................................39 Session 07: Data Integrity............................................................................................................40 Learning Objectives ....................................................................................................................40 Introduction to Data Integrity ......................................................................................................40 Entity Integrity .............................................................................................................................40 Referential Integrity ....................................................................................................................41 Rules ensuring RI: ......................................................................................................................41 Domain Integrity..........................................................................................................................42 Summary ....................................................................................................................................45 Test Your Understanding............................................................................................................46 Session 08: Interaction with DB2 ................................................................................................47 Learning Objectives ....................................................................................................................47 Interaction with DB2: Overview ..................................................................................................47 DB2I ............................................................................................................................................48 SPUFI .........................................................................................................................................49 QMF ............................................................................................................................................53 Summary ....................................................................................................................................58 Test Your Understanding............................................................................................................59 Session 09: SQL ...........................................................................................................................60 Learning Objectives ....................................................................................................................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
Handout: DB2
Try It Out .....................................................................................................................................66 DDL Alter Tablespace .............................................................................................................67 Summary ....................................................................................................................................68 Test Your Understanding............................................................................................................68 Session 10: SQL ...........................................................................................................................69 Learning Objectives ....................................................................................................................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 Test Your Understanding............................................................................................................82 Exercises ....................................................................................................................................82 Session 11: SQL ...........................................................................................................................83 Learning Objectives ....................................................................................................................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
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 Test Your Understanding............................................................................................................94 Exercises ....................................................................................................................................94 Session 12: SQL ...........................................................................................................................96 Learning Objectives ....................................................................................................................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
Handout: DB2
Test Your Understanding..........................................................................................................115 Exercises ..................................................................................................................................115 Session 26: Program Preparation and Execution ...................................................................116 Learning Objectives ..................................................................................................................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 Test Your Understanding..........................................................................................................132 Exercises ..................................................................................................................................132 Session 31: Error Handling .......................................................................................................133 Learning Objectives ..................................................................................................................133 Error Handling - Introduction ....................................................................................................133 SQLCA......................................................................................................................................133 DSNTIAR ..................................................................................................................................134 WHENEVER .............................................................................................................................135 Try It Out ...................................................................................................................................136 Summary ..................................................................................................................................139 Test Your Understanding..........................................................................................................139 Exercises ..................................................................................................................................139 Session 33: Commit and Rollback............................................................................................140
Handout: DB2
Learning Objectives ..................................................................................................................140 COMMIT ...................................................................................................................................140 Rollback ....................................................................................................................................141 Try It Out ...................................................................................................................................141 Summary ..................................................................................................................................144 Test Your Understanding..........................................................................................................144 Session 35: Cursor .....................................................................................................................145 Learning Objectives ..................................................................................................................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 Test Your Understanding..........................................................................................................151 Exercises ..................................................................................................................................151 Session 42: Handling Null .........................................................................................................152 Learning Objectives ..................................................................................................................152 Null - Introduction......................................................................................................................152 Null Indicator .............................................................................................................................152 Try It Out ...................................................................................................................................153 Summary ..................................................................................................................................161 Test Your Understanding..........................................................................................................161 Exercises ..................................................................................................................................161 Session 46: Handling VARCHAR ..............................................................................................162 Learning Objectives ..................................................................................................................162 VARCHAR - Introduction ..........................................................................................................162 VARCHAR - Behavior ...............................................................................................................162 Try It Out ...................................................................................................................................163 Summary ..................................................................................................................................171 Test Your Understanding..........................................................................................................171 Exercises ..................................................................................................................................171
Handout: DB2
Session 51: Locks ......................................................................................................................172 Learning Objectives ..................................................................................................................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 Test Your Understanding..........................................................................................................176 Session 52: Locks ......................................................................................................................177 Learning Objectives ..................................................................................................................177 Lock Mode ................................................................................................................................177 Suspension ...............................................................................................................................179 Timeout .....................................................................................................................................179 Deadlock ...................................................................................................................................179 Constructs that affect locking ...................................................................................................180 Summary ..................................................................................................................................181 Test Your Understanding..........................................................................................................181 Session 54: Miscellaneous ........................................................................................................182 Learning Objectives ..................................................................................................................182 Bind Parameters .......................................................................................................................182 Common SQL Errors ................................................................................................................183 Application Programming Guidelines .......................................................................................184 Using EXPLAIN ........................................................................................................................184 Summary ..................................................................................................................................185 Test Your Understanding..........................................................................................................185 Session 55: Miscellaneous ........................................................................................................186 Learning Objectives ..................................................................................................................186 Table-Based Infrastructure of DB2 ...........................................................................................186 DB2 Catalog .............................................................................................................................186 DB2 Directory ...........................................................................................................................190 Summary ..................................................................................................................................190 Test Your Understanding..........................................................................................................190
Handout: DB2
Session 56: Miscellaneous ........................................................................................................191 Learning Objectives ..................................................................................................................191 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 Test Your Understanding..........................................................................................................201 Session 57: Miscellaneous ........................................................................................................202 Learning Objectives ..................................................................................................................202 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 Test Your Understanding..........................................................................................................209 Session 58: Miscellaneous ........................................................................................................210 Learning Objectives ..................................................................................................................210 Dynamic SQL - Introduction .....................................................................................................210 Dynamic SQL - Types ..............................................................................................................210 When to use Dynamic SQL ......................................................................................................210 Execute Immediate SQL...........................................................................................................210 Non-select dynamic SQL ..........................................................................................................212
Handout: DB2
Parameter marker .....................................................................................................................213 Fixed-list select .........................................................................................................................213 Varying-list select SQL .............................................................................................................214 Summary ..................................................................................................................................214 Test Your Understanding..........................................................................................................214 Session 59: Miscellaneous ........................................................................................................215 Learning Objectives ..................................................................................................................215 Stored Procedure - Introduction ...............................................................................................215 Stored Procedure - Development .............................................................................................215 Creating Stored Procedures .....................................................................................................216 Managing Stored Procedures ...................................................................................................217 Executing a Stored Procedures ................................................................................................217 Summary ..................................................................................................................................218 Test Your Understanding..........................................................................................................218 Glossary ......................................................................................................................................219 References ..................................................................................................................................227 Websites ...................................................................................................................................227 Books ........................................................................................................................................227 STUDENT NOTES: ......................................................................................................................228
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
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
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.
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.
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.
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 Table Column Row Formal Terms Relation Attribute Tuple Many Database Manuals Table Field 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.
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
Handout: DB2
You need to retrieve the customers who had ordered a specific product. The column details are as follows. Table Column cust_id Customers cust_name cust_contact order_num Orders cust_id order_num OrderDetails 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 querythe 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.
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 An alternative name for a table or view which can reside in the local DB2 subsystem reside in the local or remote DB2 subsystem Can be used only by its creator Is dropped when its corresponding Table/View is dropped Can be used by anyone including its creator Not dropped even when its corresponding Table/View is dropped
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:
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.
Handout: DB2
Test Your Understanding

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. What is a storage group? What is a database? What is a table space? What is an index space? What is a table? What is an index? What is a View? What is the difference between Synonym and Alias? State the logical and physical objects among the DB2 objects and their hierarchy. How the data is being stored physically? What is a buffer pool?
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 lets 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
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.
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
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.
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.
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.
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).
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
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 2907 StudentName Smith, Jacob R MajorID MAT StudentMajor Mathematics CourseNum MAT0011 CourseName Discrete Math CourseCompDate 8/1/2002
MAT0027 EGL0010 4019 Patterson, Jane K PHI Philosophy PHI0010 CS00100
Calculus I English Classics I Intro to Philosophy Programming Languages Ascent of Man Origin of Jazz Ascent of Man
4/30/2002 12/30/2001 2002-04-30 200204-30
5145 6132
Neeld, Norris B Morrison, Xavier Q Brown, Richard E Juarez, Samantha
EGL MUS
English Literature Music
SOC0102 MUS0002 SOC0102
8/1/2002 2002-04-30 200208-01
7810 8966
CS EGL
Computer Science English Literature EGL0010 EGL0101 English Classics I Shakespeare II 2001-12-30 200208-01
Handout: DB2
STUDENT Entity in 1NF StudentID 2907 4019 5145 6132 7810 8966 LastName Smith Patterson Neeld Morrison Brown Juarez FirstName Jacob Jane Norris Xavier Richard Samantha MiddleInit R K B Q E MajorID MAT PHI EGL MUS CS EGL StudentMajor Mathematics Philosophy English Literature Music Computer Science English Literature
COURSE Entity in 1NF StudentID 2907 2907 2907 4019 4019 5145 6132 6132 8966 8966 CourseNum MAT0011 MAT0027 EGL0010 PHI0010 CS00100 SOC0102 MUS0002 SOC0102 EGL0010 EGL0101 CourseName Discrete Math Calculus I English Classics I Intro to Philosophy Programming Languages Ascent of Man Origin of Jazz Ascent of Man English Classics I Shakespeare II CourseCompDate 8/1/2002 4/30/2002 12/30/2001 4/30/2002 4/30/2002 8/1/2002 4/30/2002 8/1/2002 12/30/2001 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:
Handout: DB2
ENROLLMENT Entity in 2NF StudentID

2907 2907
CourseNum
MAT0011 MAT0027
CourseCompDate
2002-08-01 2002-04-30
2907 4019 4019 5145 6132 6132 8966 8966
EGL0010 PHI0010 CS00100 SOC0102 MUS0002 SOC0102 EGL0010 EGL0101
2001-12-30 2002-04-30 2002-04-30 2002-08-01 2002-04-30 2002-08-01 2001-12-30 2002-08-01
COURSE Entity in 2NF CourseNum MAT0011 MAT0027 EGL0010 PHI0010 CS00100 SOC0102 MUS0002 CourseName Discrete Math Calculus I English Classics I Intro to Philosophy Programming Languages Ascent of Man Origin of Jazz Credits 3 4 3 3 3 3 3
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 2907 4019 5145 6132 7810 8966 LastName Smith Patterson Neeld Morrison Brown Juarez FirstName Jacob Jane Norris Xavier Richard Samantha MiddleInit R K B Q E MajorID MAT PHI EGL MUS CS EGL
MAJOR Entity in 3NF MajorID MAT PHI EGL MUS CS StudentMajor Mathematics Philosophy English Literature Music 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.
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 weve 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.
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.
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 Hardware Independence OS Independence Ease of development DB2 PC to mainframe NT, Unix and OS/390 Standard SQL Stored procedure & triggers Ease of maintenance Security Referential Integrity Query Interface Performance Standard SQL High degrees of security DB2 enforces it Easy to view/modify Better for even large data Optimizer handles Performance Tuning Can be tuned anytime Can be at SQL level Tools available for aiding Abundant tuning skills Reorganization Direct reorganization Online reorg possible Recovery Managed by DB2 Always recoverable From log / backup Auto Recovery Backup Online backup possible Incremental backup Disaster Recovery Data Archival Supported by DB2 Selective archival VSAM Only Mainframe Only OS/390 Not so simple No such option Difficult Only at Dataset level Developers responsibility Not available Better when data is less Developer responsible Depends on initial design Only application level No tuning aids Tuning skills are rare Delete & recreate Downtime needed Managed by CICS/IMS No recovery in batch From backup only Manual Restore Downtime needed No incremental backup Part of DASD recovery No Selective archival
Handout: DB2
Feature DB2 Selective retrieval Up to row level archival Data types Images, Video, Audio, and so on. Contents can be in file VSAM No Selective retrieval Dataset level archival Text only No such option
Summary
Database Design involves:
o o o
Logical Database Design Physical Database Design 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 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 o o o
Entities into tables Instances into rows Attributes into columns 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. 2. 3. 4. 5. 6. What are the tasks involved in database design? What is logical data modeling? What is ER Model? What are all the symbols used in ER model? Describe the key activities involved in designing logical data modeling using ER model? What is a Primary key?
Handout: DB2
7. 8. 9. 10. 11. 12. 13. 14. 15. What are all the different types of relationship? What is Cardinality and Optionality? What is Normalization? What are the goals and benefits of Normalization? State the different types of Normal forms. Describe the tasks involved in the physical database design. When will you do Denormalization? State the activities involved in implementing and altering database design. 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.
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.
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 A table can contain only one primary key constraint and multiple unique constraints Cannot allow NULL values Supports Referential Integrity Column other than primary/unique constraint but defined with unique index A table can contain multiple unique indexes Can allow NULL values 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.
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 Insert Child Table Allowed if the foreign key value matches the value of Primary key of the parent table. Allowed if the foreign key value matches the value of Primary key of the parent table. Allowed. Parent Table Allowed as long as the primary key value is unique. Allowed if there are no foreign key references in the child tables. 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
Update
Delete
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.
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 CHAR(n) VARCHAR(n) SMALLINT INTEGER DECIMAL(p,s) COBOL PIC PIC X(n) PIC X(n) PIC S9(4) PIC S9(9) PIC S9(p)V9(s) COBOL USAGE DISPLAY DISPLAY COMP OR COMP-4 COMP OR COMP-4 COMP-3 Default Blanks Empty String 0 0 0 Description Fixed length character (EBCDIC) data Variable length character data Half word integer data Full word integer data Packed decimal data. p number of decimal digits s number of digits to the right side of the decimal point DATE TIME TIMESTAMP PIC X(10) PIC X(8) PIC X(26) DISPLAY DISPLAY DISPLAY Current Date Current Time Current timestamp Date data (yyyy-mm-dd) Time data (hh.mm.ss) Date and Time data with microseconds (yyyy-mm-ddhh.mm.ss.mmmmmm) GRAPHIC VARGRAPHIC FLOAT(n) PIC G(n) PIC G(n) None DISPLAY-1 DISPLAY-1 COMP-1 or COMP-2 Blanks Empty String 0 Double byte character set (DBCS) data Variable length DBCS data Floating point data in single or double precision format
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
Handout: DB2
logically reasonableif 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 o o
Entity Integrity Referential Integrity 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:
Handout: DB2
Operation Insert
Child Table
Parent Table
Allowed as long as the primary key value Allowed if the foreign key value matches the value of Primary key is unique. of the parent table. Allowed if there are no foreign key Allowed if the foreign key value matches the value of Primary key references in the child tables. of the parent table. 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
Update
Delete
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 NULL Values: Unknown or missing value Check constraint: Enforces business rules and allows only the predefined values
o o

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. What is data integrity? What is entity integrity and how do you achieve it? Can you create a table without a primary key? Can a primary key column hold a value of null? State the importance of unique index in the primary key. What is a unique constraint? Differentiate between the primary key constraint and unique constraint. State the differences between primary key index and unique index. What is a foreign key? What is a referential integrity? 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. What is domain integrity and how to achieve it? State the different DB2 data types. What is Null? What is check constraint?
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
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 o o
o o
SPUFI: SQL Processor Using File Input. DCLGEN: Declaration Generator. PROGRAM PREPARATION: Prepares a program containing embedded SQL for execution. PRECOMPILE: Program containing embedded SQL is parsed to retrieve all SQL and replace it with calls to a runtime interface to DB2 BIND/REBIND/FREE: Provides the capability to bind a DB2 plan & package, rebound a plan & package, remove plan & package from the system RUN: enables to run a DB2 application program DB2 COMMANDS: Enables to submit DB2 commands using TSO.
Handout: DB2
o
UTILITIES: Provides panels that ease the administrative burdens of DB2 utility processing 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. 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
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.
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
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 oncethe first time someone uses SPUFI. ISPF saves the defaults entered from session to session. 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. All the remaining installation defaults are appropriate. So keep them as they are. EXECUTE: When Y is specified, the SQL in the input file is read and executed.
o o
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. 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:
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
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.
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
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
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 o
Online mode Batch mode DB2I QMF
The most common online mode includes:

o o
DB2I (DB2 Interactive) is a TSO-based DB2 application, which increases the TSO DB2 developer's productivity.
Handout: DB2
DB2I helps application programmers and administrators to:
o o o o o
Run queries (SPUFI) Generate declare code (DCLGEN) Prepare programs (precompile, bind, rebind, free, run) Issue DB2 commands 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. 2. 3. 4. 5. 6. 7. 8. 9. 10. What is an attachment facility? What is a thread? How does TSO interact with DB2? List the common TSO Online modes through which DB2 interaction happens. What is DB2I? List the different options in DB2I. What is SPUFI? Explain the different options in SPUFI. What is QMF? Explain the important functionalities available in QMF.
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
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>
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. If you omit the BUFFERPOOL clause, then the default BP, BP0 is used. Specifies the default buffer pool name to be used for the indexes created within the database. If you omit the INDEXBP clause, the default BP, BP0 is used.
INDEXBP:
o
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 o
Specifies the default encoding scheme for data stored in the database. 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
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> BUFFERPOOL <bp-name> INDEXBP <bp-name> STOGROUP <stogroup-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> BUFFERPOOL <bp-name>
Handout: DB2
CCSID <ASCII/EBCDIC/UNICODE> CLOSE <YES/NO> COMPRESS <YES/NO> LOCKMAX <integer> LOCKSIZE <ANY/TABLESPACE/TABLE/PAGE/ROW> MAXROWS <integer> SEGSIZE <integer> <using-block>: USING VCAT <catalog-name> STOGROUP <stogroup-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
o o
Specifies how often to leave a page of free space when the table space is loaded or reorganized. You must specify an integer in the range 0 to 255. 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. Indicates what percentage of each page to be left as free space when the table space is loaded or reorganized. Integer can range from 0 to 99. 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.
PCTFREE:
o
o o
DEFINE:
Handout: DB2
o
Specifies at which point (when) the underlying data sets for the table space are physically created. YES: The data sets are created when the table space is created. This is the default. 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: Specifies that changes that are made to the data in the specified table space are recorded in the log. NOT LOGGED: Specifies that changes that are made to data in the specified table space are not recorded in the log.
LOGGED:
o
TRACKMOD: Specifies whether DB2 tracks modified pages in the space map pages of the table space.
o o
YES: Tracked. This is the default. 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 o
The leaf contains bookmarks to the actual data. 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. Indicates that the table space is partitioned. Integer is the number of partitions. Specifies to which partition the subsequent using-block or free-block applies. Integer can range from 1 to the number of partitions given by NUMPARTS.
NUMPARTS:
o o
PARTITION:
o o
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.
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 o
Specifies that the table space will be a segmented. 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.
Handout: DB2
Code: CREATE TABLESPACE SALESHX IN DSN8D91A USING STOGROUP DSN8G910 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> BUFFERPOOL <bp-name> CCSID <ASCII/EBCDIC/UNICODE> CLOSE <YES/NO> COMPRESS <YES/NO> LOCKMAX <integer> LOCKSIZE <ANY/TABLESPACE/TABLE/PAGE/ROW> MAXROWS <integer> MAXPARTITIONS <integer> <using-block>: USING VCAT <catalog-name> STOGROUP <stogroup-name> PRIQTY <integer> SECQTY <integer> ERASE <YES/NO> <free-block>: FREEPAGE <integer>
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 o o
DDL (Data Definition Language) DML (Data Manipulation Language) DCL (Data Control Language) Create Alter Drop Object Storage Group Storage Group Database Database Tablespace Tablespace Operation Creation Alteration Creation Alteration Creation Alteration DDL CREATE STOGROUP ALTER STOGROUP CREATE DATABASE ALTER DATABASE CREATE TABLESPACE ALTER TABLESPACE
DDL can do the following operations:

o o o

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

Learning Objectives
After completing this session, you will be able to: Create the following objects: o o o o o Table Index View Alias 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] [columnconstraint-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>
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 o
NULL is a default. NOT NULL: Prevents the column from containing null values. Omission of NOT NULL implies that the column can contain null values. 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 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. You must use a table-level constraint if you are constraining more than one column. Names the constraint and is optional. If a constraint name is not specified, then a unique constraint name is generated. 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. The FOREIGN KEY constraint is defined with the REFERENCES keyword. The FOREIGN KEY constraint (referential integrity constraint), ensures that the values in the foreign key correspond to values of a primary key. When defining a FOREIGN KEY constraint on a table, the column name does not have to be identical to the column name it references. By default the foreign key constraint is of type DELETE RESTRICT: Parent rows cannot be deleted if child rows exist. ON DELETE 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. To enforce unique values on an individual or a group of columns. UNIQUE constraint column should not contain NULL values. A table can contain one or more UNIQUE constraints. The PRIMARY KEY ensures all values in the column/columns are unique. The clause must not be specified more than once and the identified columns must be defined as NOT NULL.
Constraints: Constraints are defined on two possible levels.

o
Constraint-name:
o o o
FOREIGN KEY constraint

o o
UNIQUE constraint:
o o o
PRIMARY KEY constraint:

o o
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 TAB1_COL1 TAB1_COL2 Data Type Integer Integer 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 Current date should be inserted by default 20 Unique Should accept the values which are less than 100. Null value is allowed. Length Constraint Primary Key Not Null Remarks
TAB1_COL3
Varchar
TAB1_COL4 TAB1_COL5
Date Char
TAB1_COL6
Integer
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))
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 TAB1_COL1 TAB1_COL2 Data Type Integer Integer 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 Current date should be inserted by default 20 Unique Should accept the values which are less than 100. Null value is allowed. Length Constraint Primary Key Not Null Remarks
TAB1_COL3
Varchar
TAB1_COL4
Date
TAB1_COL5
Char
TAB1_COL6
Integer
Handout: DB2
Code: CREATE TABLE TB_TAB1 (TAB1_COL1 INTEGER NOT NULL, TAB1_COL2 INTEGER NOT NULL, TAB1_COL3 VARCHAR(5), TAB1_COL4 DATE WITH DEFAULT, TAB1_COL5 CHAR(20) NOT NULL, TAB1_COL6 INTEGER 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>)]
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>]
Handout: DB2
[COPY <YES | NO>] <using-specification> USING VCAT <catalog-name> | STOGROUP <stogroup-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. 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. 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. 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.
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. NO: The data sets are not created until data is inserted into the index. NO: Specifies that no index compression will be used. This is the default. YES: Specifies that index compression will be used. PARTITION integer: A PARTITION clause specifies the highest value of the index key in one partition of a partitioning index. 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.
COMPRESS: Specifies whether compression for index data will be used.

o
PARTITION BY RANGE: Specifies the index is the partitioning index.

o
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 o
YES: Eligible for closing. This is the default NO: Not eligible for closing.
DEFER: Indicates whether the index is built during the execution of the CREATE INDEX statement.
o o
NO: The index is built. This is the default. 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. 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);
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 USING STOGROUP DSN8G910 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.
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> <using-specification> <free-specification>]
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.
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>
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 Table Table Index Index View View Alias Synonym Operation Creation Alteration Creation Alteration Creation Alteration Creation Creation DDL CREATE TABLE ALTER TABLE CREATE INDEX ALTER INDEX CREATE VIEW ALTER VIEW CREATE ALIAS CREATE SYNONYM
In order to delete the objects, you need to issue DROP command.
Handout: DB2

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. List the different ways in which tables can be created. Describe how do you create a table and explain the options. Describe how do you alter a table and explain the options. Describe how do you create an index and explain the options. Describe how do you alter an index and explain the options. Describe how do you create a view and explain the options. What is the need of altering the view? How do you create an alias? How do you create a synonym? 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)
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);
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;
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.
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;
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 = <> != < <= !< > >= !> BETWEEN IS NULL 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; 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 two specified values including the specified start and end value Is a NULL value Description
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.
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%;
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.
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 + * / Example: SELECT order_id, order_quantity, order_item_price, order_quantity*order_item_price AS expanded_price FROM tb_order WHERE order_num = 20008; Description Addition Subtraction Multiplication Division
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.
Handout: DB2
Following is the list of Aggregate Functions: Function AVG() COUNT() MAX() MIN() SUM() Example: SELECT AVG(prod_price) AS avg_price FROM tb_prod; Description Returns a column's average value Returns the number of rows in a column Returns a column's highest value Returns a column's lowest value Returns the sum of a column's values
DML Text Functions

Following is the list of commonly used Text-Manipulation Functions: Function LEFT() LENGTH() LOWER() LTRIM() RIGHT() RTRIM() UPPER() SUBSTR() Description Returns characters from left of string Returns the actual length of a string Converts string to lowercase Trims white space from left of string Returns characters from right of string Trims white space from right of string Converts string to uppercase Returns a substring of a string. 2nd argument starting position 3rd argument length Returns the hexadecimal representation of its argument Example LEFT(cust_firstname, 4) LENGTH(cust_firstname) LOWER(cust_firstname) LTRIM(cust_firstname) RIGHT(cust_firstname) RTRIM(cust_firstname) UPPER(cust_firstname) SUBSTR(cust_firstname,3,4)
HEX()
HEX(cust_firstname)
DML Date and Time Manipulation Functions

Following is the list of commonly used Date and Time Manipulation Functions: Function CHAR DAYS YEAR MONTH DAY HOUR Description Returns a string representation of its first argument. Returns an integer representation of its argument. Returns the year part of its argument Returns the month part of its argument Returns the day part of its argument Returns the hour part of its argument Example CHAR(cust_hiredate,USA) DAYS(2008-01-01) YEAR(cust_hiredate) MONTH(cust_hiredate) DAY(cust_hiredate) HOUR(CURRENT TIME)
Handout: DB2
Function MINUTE SECOND MICROSECOND DATE TIME TIMESTAMP Description Returns the minute part of its argument Returns the seconds part of its argument Returns the microsecond part of its argument Returns the date derived from its argument Returns the time derived from its argument Returns the timestamp derived from its argument Example MINUTE(CURRENT TIME) SECOND(CURRENT TIME) MICROSECOND(CURRENT TIMESTAMP) DATE(2008-01-01) TIME(13:00:00) TIMESTAMP(CURRENT DATE)
DML Numeric Functions

Following is the list of commonly used numeric functions: Function DECIMAL DIGITS FLOAT INTEGER ABS() COS() EXP() PI() SIN() SQRT() TAN() Description Returns a decimal representation of its argument Returns a character string representation of its argument Returns a floating point representation Returns an integer representation Returns a number's absolute value Returns the trigonometric cosine of a specified angle Returns the exponential value of a specific number Returns the value of PI Returns the trigonometric sine of a specified angle Returns the square root of a specified number Returns the trigonometric tangent of a specified angle Example DECIMAL(inv_total, 10,3) DIGITS(inv_total) FLOAT(cust_salary) INTEGER(cust_salary+.5) ABS(inv_total) COS(inv_total) EXP(inv_total) PI(inv_total) SIN(inv_total) SQRT(inv_total) 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 INSERT UPDATE DELETE SELECT FROM WHERE ORDER BY DISTINCT
Description Populate the data into table or view Update the data in the table or view Delete the data from table or view Columns or expressions to be returned Table to retrieve data from Row-level filtering Sort the data retrieved Remove duplicates

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. How do you insert the data into a table or view? How do you update the data in a table or view? How do you delete the data from the table or view? How do you retrieve multiple column values from the table? How do you retrieve all the column values from the table? How do you sort the retrieved data? How do you filter the data retrieved? What are the different WHERE clause operators? Explain about the logical operators in the WHERE clause. How do you match parts of the value? How do you remove duplicates? How do you concatenate fields? What are the mathematical operators? Explain different types of functions.
Exercises
1. Insert the following rows into the table PATIENT. PATIENT_NO A111 A112 A113 A114 A115 A116 A117 A118 A119 A120 LASTNAME HAR MAHESH SWAMI RAM KRISHNA KANNAN VENKAT SWAMI GOPI MS FIRSTNAME BHU LATHA VIGNESH PRABHU DHILIP LEKHA DEEPA AKILA KANNAN GEETHA GENDER F F M M M F F F M F DATE_OF_BIRTH 1975-07-27 1980-08-17 1985-01-07 1981-04-27 1969-04-14 1980-05-18 1977-02-21 1960-08-29 1965-05-17 1975-08-27
Handout: DB2
2. 3. 4. 5.
Get gender and date of birth of patients. Count the number of patients. Get last names and first names of all patients whose last name starts with a letter 'M'. 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 A111 A111 A111 A112 A112 A112 A113 A113 A113 A114 A114 A114 A115 A115 A115 LINE_NO 1 2 3 1 2 3 1 2 3 1 2 3 1 2 3 ADDRESS G3 KONDAPUR HYDERABAD A12G3 KUKATPALLY HYDERABAD G3 NUNGAMBAKKAM CHENNAI A14G3 KK NAGAR CHENNAI G3 KORAMANGALA BANGALORE
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
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
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);
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
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.
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 Left Outer Join Right Outer Join Full Outer Join Keep unmatched rows from The outer table The inner table 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.
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
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] {authorization-id-list/PUBLIC} TO
[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
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 GROUP BY HAVING UNION GRANT REVOKE Description Group specification Group-level filtering Combine the results of the multiple select statements Privileges to a user to access a DB2 object Take away a certain privilege from a user

1. Explain about GROUP BY with HAVING clause. 2. 3. 4. 5. 6. 7. 8. What is a subquery? List the operators used in the subquery. Explain the types of subquery. What is a join? Explain about the different types of joins. What is UNION operator? 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 HAR HAR HAR MAHESH MAHESH MAHESH FIRSTNAME BHU BHU BHU LATHA LATHA LATHA ADDRESS G3 HYDERABAD KONDAPUR KUKATPALLY A12G3 HYDERABAD
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 patients 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 doesnt have the address, the output report should be empty. 10. Get the list of patient number for all the patients who dont 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.
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.
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 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. 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. 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. DELIMIT DBCS: Tells DCLGEN whether to delimit DBCS (Double Byte Character String) table names and column names in the table declaration. 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.
INDICATOR VARS: Tells DCLGEN whether to generate an array of indicator variables for the host variable structure. RIGHT MARGIN: Specifies the break point for statement tokens that must be wrapped to one or more subsequent records.
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
Handout: DB2
In DCLGEN menu, enter appropriate values to create the DCLGEN.
Table Name
Dataset in which DCLGEN is created
Handout: DB2
Once appropriate values are entered here press enter, well get the following message for the successful creation of DCLGEN.
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).
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 weve seen before, this weve 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 o o
As input data areas for the SET clause of the UPDATE statement As input data areas for the VALUES clause of the INSERT statement As search fields in the WHERE clause for SELECT, INSERT, UPDATE, and DELETE statements 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
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). 10 SQLWARN1 PIC X(1). 10 SQLWARN2 PIC X(1). 10 SQLWARN3 PIC X(1). 10 SQLWARN4 PIC X(1). 10 SQLWARN5 PIC X(1). 10 SQLWARN6 PIC X(1). 10 SQLWARN7 PIC X(1). 05 SQLEXT. 10 SQLWARN8 PIC X(1). 10 SQLWARN9 PIC X(1). 10 SQLWARNA PIC X(1). 10 SQLSTATE PIC X(5).
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 Zero Positive +100 Negative Statement successful Statement successful, but with some exceptional condition Row not found or end of data Statement failed and serious error detected Meaning
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 FILLER PIC X(3) VALUE SPACES. 10 WS-PARA PIC X(20) VALUE SPACES. ****************************************************************** * INCLUDE DCLGEN ****************************************************************** EXEC SQL INCLUDE DRATE END-EXEC. ****************************************************************** * INCLUDE SQLCA ****************************************************************** EXEC SQL INCLUDE SQLCA
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.
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. 2. 3. 4. 5. What is ESQL (Embedded SQL)? What is a DCLGEN? What is a host variable? What is SQLCA? What is SQLCODE?
Exercises
Develop a COBOL-DB2 application program which accepts Patient Number and displays Patient Information as follows: Patient Number: Patient Name: Gender: Date of Birth: xxxx <First name> <Last name> <x> <DD/MM/YYYY>
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 o o o
Precompilation Bind Compilation 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).
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=*
Handout: DB2
//SYSUDUMP DD //SYSUT1 DD //SYSUT2 DD //SYSIN DD SYSOUT=* SPACE=(800,(500,500),,,ROUND),UNIT=SYSDA SPACE=(800,(500,500),,,ROUND),UNIT=SYSDA 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.
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. 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. 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.
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 executedthey 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). 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 bagnot 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.
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) //STEPLIB DD DISP=SHR,DSN=DSN810.SDSNLOAD //DBRMLIB DD DISP=OLD,DSN=&DBRMLIB(&LOADMEM) //SYSPRINT DD SYSOUT=* //SYSTSPRT DD SYSOUT=* //SYSUDUMP 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 /*
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 o o o o
DSN S or DSN SYSTEM: DB2 subsystem PLAN: Name of the plan to be bound MEMBER: DBRM Member name QUALIFIER: USERID 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: //********************************************************************** //* 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(PROGRAM1 PROGRAM2 PROGRAM3) QUALIFIER(USERID) ACTION(REP) RETAIN ISOLATION(UR) 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 '()' * //* SPECIFY YOUR PROGRAM NAME WITHIN MEMBER PARANTHESIS * //* SPECIFY YOUR USERID WITHIN QUALIFIER PARANTHESIS * //********************************************************************** //SYSTSIN DD * DSN S(DSN1) BIND PACKAGE (PACKAGE NAME) MEMBER(PROGRAM) QUALIFIER(USERID) -
Handout: DB2
ACTION(REP) RETAIN ISOLATION(UR) 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 '()' * //* SPECIFY YOUR PROGRAM NAME WITHIN MEMBER PARANTHESIS * //* SPECIFY YOUR USERID WITHIN QUALIFIER PARANTHESIS * //********************************************************************** //SYSTSIN DD * DSN S(DSN1) BIND PLAN (PLAN NAME) PKLIST(PACKAGE1, PACKAGE2) QUALIFIER(USERID) ACTION(REP) RETAIN ISOLATION(UR) 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) -
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)
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)) //SYSPRINT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SYSUT1 DD SPACE=(800,(500,500),,,ROUND),UNIT=SYSDA //SYSUT2 DD SPACE=(800,(500,500),,,ROUND),UNIT=SYSDA //SYSUT3 DD SPACE=(800,(500,500),,,ROUND),UNIT=SYSDA //SYSUT4 DD SPACE=(800,(500,500),,,ROUND),UNIT=SYSDA //SYSUT5 DD SPACE=(800,(500,500),,,ROUND),UNIT=SYSDA
Handout: DB2
//SYSUT6 DD SPACE=(800,(500,500),,,ROUND),UNIT=SYSDA //SYSUT7 DD SPACE=(800,(500,500),,,ROUND),UNIT=SYSDA 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) //SYSPRINT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SYSUT1 DD SPACE=(1024,(50,50)),UNIT=SYSDA
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 // DD DSN=CEE.SCEERUN,DISP=SHR // DD DSN=DSN810.SDSNLOAD,DISP=SHR //DBRMLIB DD DSN=THYD018.DB2.DBRMLIB,DISP=SHR //SYSTSPRT DD SYSOUT=* //SYSPRINT DD SYSOUT=* //SYSTSIN DD * DSN SYSTEM(DSN1) name RUN PROGRAM(FIRSTCD)name PLAN(THYPL018) END /* Load Library name
DBRM Name
Subsystem Load module Plan name
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 //**********************************************************************
Handout: DB2
//* 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=* //SYSUDUMP DD SYSOUT=* //SYSUT1 DD SPACE=(800,(500,500),,,ROUND),UNIT=SYSDA //SYSUT2 DD SPACE=(800,(500,500),,,ROUND),UNIT=SYSDA //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)) //SYSPRINT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SYSUT1 DD SPACE=(800,(500,500),,,ROUND),UNIT=SYSDA //SYSUT2 DD SPACE=(800,(500,500),,,ROUND),UNIT=SYSDA //SYSUT3 DD SPACE=(800,(500,500),,,ROUND),UNIT=SYSDA //SYSUT4 DD SPACE=(800,(500,500),,,ROUND),UNIT=SYSDA //SYSUT5 DD SPACE=(800,(500,500),,,ROUND),UNIT=SYSDA //SYSUT6 DD SPACE=(800,(500,500),,,ROUND),UNIT=SYSDA //SYSUT7 DD SPACE=(800,(500,500),,,ROUND),UNIT=SYSDA //********************************************************************** //* 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)
Handout: DB2
//SYSLMOD DD DISP=SHR,DSN=&LOADLIB(&LOADMEM) //SYSPRINT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SYSUT1 DD SPACE=(1024,(50,50)),UNIT=SYSDA //********************************************************************** //* BIND THE PROGRAM * //********************************************************************** //BIND EXEC PGM=IKJEFT01,COND=(4,LT,LINKEDIT) //STEPLIB DD DISP=SHR,DSN=DSN810.SDSNLOAD //DBRMLIB DD DISP=OLD,DSN=&DBRMLIB(&LOADMEM) //SYSPRINT DD SYSOUT=* //SYSTSPRT DD SYSOUT=* //SYSUDUMP 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(THYPL018) MEMBER(FIRSTCD) QUALIFIER(THYD018) ACTION(REP) RETAIN ISOLATION(UR) 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 //SYSTSPRT DD SYSOUT=* //SYSPRINT DD SYSOUT=* //SYSTSIN DD * DSN SYSTEM(DSN1) RUN PROGRAM(FIRSTCD)PLAN(THYPL018) PARM('A') END /*
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.
Handout: DB2 Test Your Understanding

1. 2. 3. 4. 5. 6. 7. 8. 9. What is the need for Precompilation? Explain the tasks involved in Precompilation. Explain the tasks involved in Bind. What is a plan? What is a package? What is a version? What is a collection? What are the advantages of package over the plan? 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: Patient Name: Gender: Date of Birth: xxxx <First name> <Last name> <x> <DD/MM/YYYY>
Handout: DB2
Session 31: Error Handling

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 05 SQLCABC 05 SQLCODE 05 SQLERRM. 49 SQLERRML 49 SQLERRMC 05 SQLERRP 05 SQLERRD 05 SQLWARN. 10 SQLWARN0 10 SQLWARN1 10 SQLWARN2 10 SQLWARN3 10 SQLWARN4 10 SQLWARN5 10 SQLWARN6 10 05 10 10 SQLWARN7 SQLEXT. SQLWARN8 SQLWARN9 PIC X(8). PIC S9(9) PIC S9(9)
COMP-4. COMP-4.
PIC S9(4) COMP-4. PIC X(70). PIC X(8). OCCURS 6 TIMES PIC S9(9) COMP-4. PIC PIC PIC PIC X. X. X. X.
PIC X. PIC X. PIC X. PIC X. PIC X. PIC X. PIC X.
10 SQLWARNA
Handout: DB2
10 SQLSTATE PIC X(5).
The following table gives the description about the useful fields which are highlighted: Field SQLCODE SQLERRD(3) SQLWARN0 SQLWARN1 SQLWARN2 SQLWARN3 SQLWARN6 Description SQL Return Code indicating the status of the most recent SQL statement. This field is unique to DB2 for MVS. Number of rows affected by an INSERT, UPDATE or DELETE statement Contains W if any other SQLWARN field contains W Contains W if a string was truncated when stored in a host variable Contains W if null values were excluded during the processing of a column function Contains W if the number of columns and host variables do not match 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. 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)
SQLSTATE
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
Handout: DB2
Logic behind the numbers: Length of each line as set by the third parameter Number of lines for the message 10 800 So the total length of the data component 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 0 4 8 12 16 20 24 Successful execution More data was available than could fit into the provided message area The logical record length was not between 72 and 240 inclusive The message area was not large enough, or the message length was 240 or greater Error in TSO message routine Module DSNTIA1 could not be loaded SQLCA data error Meaning 80
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.
Handout: DB2
The following table gives the meaning of the keywords used in WHENEVER: Keyword SQLERROR SQLWARNING NOT FOUND The SQLCODE is negative The SQLCODE is positive but not +100 or SQLWARN0 equal to W The SQLCODE is equal to +100 Meaning
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 D Code: IDENTIFICATION DIVISION. PROGRAM-ID. ERRORHAN. ENVIRONMENT DIVISION. DATA DIVISION. WORKING-STORAGE SECTION. ****************************************************************** * VARIABLES FOR ERROR ROUTINE. ****************************************************************** 01 WS-ERROR-MESSAGE. RATE_PER_HOUR 50
Handout: DB2
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 FILLER PIC X(3) VALUE SPACES. 10 WS-PARA PIC X(20) VALUE SPACES. ****************************************************************** * PARAMETERS FOR DSNTIAR ****************************************************************** 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. ****************************************************************** * 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)
Handout: DB2
END-EXEC. EVALUATE SQLCODE WHEN 0 DISPLAY 'INSERT SUCCESSFUL FOR RATE CAT :' RATE-CAT WHEN OTHER MOVE SQLCODE TO WS-SQLCODE MOVE 'TB_RATE' TO WS-TABLE MOVE '1000-INSERT-PARA' TO WS-PARA PERFORM 9999-DB2-ERROR-ROUTINE THRU 9999-EXIT END-EVALUATE. 1000-EXIT. EXIT. 9999-DB2-ERROR-ROUTINE. DISPLAY '-----------------------------------------------'. DISPLAY 'ERROR DETECTED'. DISPLAY WS-ERROR-MESSAGE. DISPLAY '-----------------------------------------------'. CALL 'DSNTIAR' USING SQLCA WS-DB2-ERR-MESSAGE WS-DB2-ERRMESG-LINE-LEN. 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
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.
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.
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 F Code: IDENTIFICATION DIVISION. PROGRAM-ID. COMTRLBK. 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 FILLER PIC X(3) VALUE SPACES. 10 WS-PARA PIC X(20) VALUE SPACES. ****************************************************************** * PARAMETERS FOR DSNTIAR ****************************************************************** RATE_PER_HOUR 20
Handout: DB2
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. ****************************************************************** * 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. PERFORM 1000-INSERT-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 MOVE SQLCODE TO WS-SQLCODE MOVE 'TB_RATE' TO WS-TABLE MOVE '1000-INSERT-PARA' TO WS-PARA PERFORM 9999-DB2-ERROR-ROUTINE THRU 9999-EXIT END-EVALUATE.
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 SQLCODE TO WS-SQLCODE MOVE 'TB_RATE' TO WS-TABLE MOVE '1100-COMMIT-PARA' TO WS-PARA PERFORM 9999-DB2-ERROR-ROUTINE THRU 9999-EXIT END-EVALUATE. 1100-EXIT. EXIT. 9999-DB2-ERROR-ROUTINE. DISPLAY '-----------------------------------------------'. DISPLAY 'ERROR DETECTED'. DISPLAY WS-ERROR-MESSAGE. DISPLAY '-----------------------------------------------'. CALL 'DSNTIAR' USING SQLCA WS-DB2-ERR-MESSAGE WS-DB2-ERRMESG-LINE-LEN. 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: CommitRollback_Program_COMTRLBK_Session#33_Slide#7 to obtain soft copy of the program code.

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.
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 DECLARE CURSOR Description COBOL equivalent for File Processing
Defines a result table and names a cursor for None it. OPEN <file-name> READ <file-name> CLOSE <file-name>
Open <cursor-name> Creates the result table and positions the cursor before the first row in the table FETCH <cursor-name> Fetches the next row from the result table CLOSE <cursor-name> Close the result table
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.
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 cursorcontrolled 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.
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. 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 FILLER PIC X(3) VALUE SPACES. 10 WS-PARA PIC X(20) VALUE SPACES. ****************************************************************** * PARAMETERS FOR DSNTIAR ****************************************************************** 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. ****************************************************************** * 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 ******************************************************************
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 SQLCODE TO WS-SQLCODE MOVE 'TB_RATE' TO WS-TABLE MOVE '1000-OPEN-PARA' TO WS-PARA PERFORM 9999-DB2-ERROR-ROUTINE THRU 9999-EXIT END-EVALUATE. 1000-EXIT. EXIT. 2000-PROCESS-PARA. PERFORM 2100-FETCH-PARA THRU 2100-EXIT UNTIL WS-AT-END. 2000-EXIT.
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 SQLCODE TO WS-SQLCODE MOVE 'TB_RATE' TO WS-TABLE MOVE '2100-FETCH-PARA' TO WS-PARA PERFORM 9999-DB2-ERROR-ROUTINE 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 SQLCODE TO WS-SQLCODE MOVE 'TB_RATE' TO WS-TABLE MOVE '3000-CLOSE-PARA' TO WS-PARA PERFORM 9999-DB2-ERROR-ROUTINE THRU 9999-EXIT END-EVALUATE. 3000-EXIT. EXIT. 9999-DB2-ERROR-ROUTINE. DISPLAY '-----------------------------------------------'. DISPLAY 'ERROR DETECTED'. DISPLAY WS-ERROR-MESSAGE. DISPLAY '-----------------------------------------------'. CALL 'DSNTIAR' USING SQLCA
Handout: DB2
WS-DB2-ERR-MESSAGE WS-DB2-ERRMESG-LINE-LEN. 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: 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 DECLARE CURSOR Open <cursor-name> Description Defines a result table and names a cursor for it Creates the result table and positions the cursor before the first row in the table Fetches the next row from the result table Close the result table COBOL equivalent for File Processing None OPEN <file-name>
FETCH <cursor-name> CLOSE <cursor-name>
READ <file-name> 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.
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 columns value: Value of the Indicator Variable -1 0 -2 Positive value Null Not Null Null because of conversion error 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 Value of the corresponding column
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.
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 files 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 EMPLOYEE LAST ID NAME E031 E032 E033 Narayanasamy EMPLOYEE FIRST NAME Divya Gangaraj Vanitha EMPLOYEE GENDER F M F EMPLOYEE DOB 1978-09-16 1979-09-17 1980-09-18 EMPLOYEE RATE CAT C C D
Handout: DB2
Code: IDENTIFICATION DIVISION. PROGRAM-ID. NULLPRGM. ENVIRONMENT DIVISION. 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). 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 FILLER PIC X(3) VALUE SPACES. 10 WS-PARA PIC X(20) VALUE SPACES. ****************************************************************** * PARAMETERS FOR DSNTIAR ****************************************************************** 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. *
Handout: DB2
01 WS-DB2-ERRMESG-LINE-LEN PIC S9(09) COMP VALUE +80. ****************************************************************** * 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. PERFORM 2000-PROCESS-PARA THRU 2000-EXIT.
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. PERFORM 2200-COMMIT-PARA THRU 2200-EXIT. PERFORM 2300-RETRIEVE-PARA THRU 2300-EXIT. 2000-EXIT. EXIT. 2100-POPULATE-PARA. PERFORM 2110-READ-PARA THRU 2110-EXIT. PERFORM 2120-INSERT-PARA 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,
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 SQLCODE TO WS-SQLCODE MOVE 'TB_EMPLOYE' TO WS-TABLE MOVE '2120-INSERT-PARA' TO WS-PARA PERFORM 9999-DB2-ERROR-ROUTINE THRU 9999-EXIT END-EVALUATE. PERFORM 2110-READ-PARA 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 MOVE IN-EMP-LAST-NAME TO EMPLOYE-LAST-NAME-TEXT END-IF. 2122-EXIT. EXIT. 2200-COMMIT-PARA. EXEC SQL COMMIT END-EXEC. EVALUATE SQLCODE
Handout: DB2
WHEN 0 DISPLAY 'SUCCESSFULLY COMMITTED' WHEN OTHER MOVE SQLCODE TO WS-SQLCODE MOVE 'TB_EMPLOYE' TO WS-TABLE MOVE '2200-COMMIT-PARA' TO WS-PARA PERFORM 9999-DB2-ERROR-ROUTINE THRU 9999-EXIT END-EVALUATE. 2200-EXIT. EXIT. 2300-RETRIEVE-PARA. PERFORM 2310-OPEN-CURSOR-PARA THRU 2310-EXIT. PERFORM 2320-FETCH-PARA 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 SQLCODE TO WS-SQLCODE MOVE 'TB_EMPLOYE' TO WS-TABLE MOVE '2310-OPEN-CURSOR-PARA' TO WS-PARA PERFORM 9999-DB2-ERROR-ROUTINE THRU 9999-EXIT END-EVALUATE. 2310-EXIT. EXIT. 2320-FETCH-PARA. EXEC SQL FETCH CS-EMPLOYE INTO :EMPLOYE-ID, :EMPLOYE-LAST-NAME:IND-EMPLOYE-LAST-NAME, :EMPLOYE-FIRST-NAME, :EMPLOYE-GENDER,
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 MOVE SQLCODE TO WS-SQLCODE MOVE 'TB_EMPLOYE' TO WS-TABLE MOVE '2320-FETCH-PARA' TO WS-PARA PERFORM 9999-DB2-ERROR-ROUTINE 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.
Handout: DB2
EXEC SQL CLOSE CS-EMPLOYE END-EXEC. IF SQLCODE NOT= 0 MOVE SQLCODE TO WS-SQLCODE MOVE 'TB_EMPLOYE' TO WS-TABLE MOVE '2330-CLOSE-CURSOR-PARA' TO WS-PARA PERFORM 9999-DB2-ERROR-ROUTINE THRU 9999-EXIT END-IF. 2330-EXIT. EXIT. 3000-FINALIZE-PARA. CLOSE IN-FILE OUT-FILE. 3000-EXIT. EXIT. 9999-DB2-ERROR-ROUTINE. DISPLAY '-----------------------------------------------'. DISPLAY 'ERROR DETECTED'. DISPLAY WS-ERROR-MESSAGE. DISPLAY '-----------------------------------------------'. CALL 'DSNTIAR' USING SQLCA WS-DB2-ERR-MESSAGE WS-DB2-ERRMESG-LINE-LEN. 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: Null_Program_NULLPRGM_Session#43_Slide#7 to obtain soft copy of the program code

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: PATIENT_NO A121 A122 LASTNAME NULL NULL FIRSTNAME KISHOREKUMARREDDY SRIVIDHYA GENDER M F DATE_OF_BIRTH 8/27/1980 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.
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 EMPLOYE_LAS EMPLOYE_FIRS EMPLOYE_GE EMPLOYE_ EMPLOYE_RATE_ E_ID T_NAME T_NAME NDER DOB CAT E001 E002 E003 E004 AWALGAONKAR BORRA CHINTALAPHAN I DABBIRU MADHURI VAMSHI VARUN ANIL F M M M 1980-08-17 1975-06-30 1970-07-19 1985-04-28 C A B 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- OUT-EMP-LAST- OUT-EMPID NAME FIRST-NAME E001 E002 E003 E004 AWALGAONKAR BORRAAONKAR CHINTALAPHANI DABBIRUAPHANI MADHURI VAMSHII VARUNII ANILNII OUT-EMPGENDER F M M M OUT-EMPDOB 1980-08-17 1975-06-30 1970-07-19 1985-04-28 OUT-EMP-RATECAT C A B E
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 records last name field which is AWALGAONKAR If you examine the host variable content, then it is as follows: EMPLOYE-ID E001 E002 EMPLOYE-LAST-NAME-LEN 11 5 EMPLOYE-LAST-NAME-TEXT AWALGAONKAR 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 files 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 EMPLOYEE LAST EMPLOYEE ID NAME FIRST NAME E031 E032 E033 Code: IDENTIFICATION DIVISION. PROGRAM-ID. VARCNULL. ENVIRONMENT DIVISION. INPUT-OUTPUT SECTION. FILE-CONTROL. SELECT IN-FILE ASSIGN TO INFILE. SELECT OUT-FILE ASSIGN TO OUTFILE. DATA DIVISION. Narayanasamy Divya Gangaraj Vanitha EMPLOYEE GENDER F M F EMPLOYEE DOB 1978-09-16 1979-09-17 1980-09-18 EMPLOYEE RATE CAT C C D
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). 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 FILLER PIC X(3) VALUE SPACES. 10 WS-PARA PIC X(20) VALUE SPACES. ****************************************************************** * PARAMETERS FOR DSNTIAR ****************************************************************** 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. ****************************************************************** * 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).
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. PERFORM 2000-PROCESS-PARA 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.
Handout: DB2
2000-PROCESS-PARA. PERFORM 2100-POPULATE-PARA THRU 2100-EXIT. PERFORM 2200-COMMIT-PARA THRU 2200-EXIT. PERFORM 2300-RETRIEVE-PARA THRU 2300-EXIT. 2000-EXIT. EXIT. 2100-POPULATE-PARA. PERFORM 2110-READ-PARA THRU 2110-EXIT. PERFORM 2120-INSERT-PARA 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-LAST-NAME:IND-EMPLOYE-LAST-NAME, :EMPLOYE-FIRST-NAME, :EMPLOYE-GENDER, :EMPLOYE-DOB, :EMPLOYE-RATE-CAT) END-EXEC. EVALUATE SQLCODE
Handout: DB2
WHEN 0 DISPLAY 'INSERT SUCCESSFUL' DISPLAY 'EMPLOYE_ID : ' EMPLOYE-ID DISPLAY '**********************************************' WHEN OTHER MOVE SQLCODE TO WS-SQLCODE MOVE 'TB_EMPLOYE' TO WS-TABLE MOVE '2120-INSERT-PARA' TO WS-PARA PERFORM 9999-DB2-ERROR-ROUTINE THRU 9999-EXIT END-EVALUATE. PERFORM 2110-READ-PARA 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 MOVE IN-EMP-LAST-NAME TO EMPLOYE-LAST-NAME-TEXT 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
Handout: DB2
WHEN 0 DISPLAY 'SUCCESSFULLY COMMITTED' WHEN OTHER MOVE SQLCODE TO WS-SQLCODE MOVE 'TB_EMPLOYE' TO WS-TABLE MOVE '2200-COMMIT-PARA' TO WS-PARA PERFORM 9999-DB2-ERROR-ROUTINE THRU 9999-EXIT END-EVALUATE. 2200-EXIT. EXIT. 2300-RETRIEVE-PARA. PERFORM 2310-OPEN-CURSOR-PARA THRU 2310-EXIT. PERFORM 2320-FETCH-PARA 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 SQLCODE TO WS-SQLCODE MOVE 'TB_EMPLOYE' TO WS-TABLE MOVE '2310-OPEN-CURSOR-PARA' TO WS-PARA PERFORM 9999-DB2-ERROR-ROUTINE 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, :EMPLOYE-LAST-NAME:IND-EMPLOYE-LAST-NAME,
Handout: DB2
:EMPLOYE-FIRST-NAME, :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 MOVE SQLCODE TO WS-SQLCODE MOVE 'TB_EMPLOYE' TO WS-TABLE MOVE '2320-FETCH-PARA' TO WS-PARA PERFORM 9999-DB2-ERROR-ROUTINE 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.
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 SQLCODE TO WS-SQLCODE MOVE 'TB_EMPLOYE' TO WS-TABLE MOVE '2330-CLOSE-CURSOR-PARA' TO WS-PARA PERFORM 9999-DB2-ERROR-ROUTINE THRU 9999-EXIT END-IF. 2330-EXIT. EXIT. 3000-FINALIZE-PARA. CLOSE IN-FILE OUT-FILE. 3000-EXIT. EXIT. 9999-DB2-ERROR-ROUTINE. DISPLAY '-----------------------------------------------'. DISPLAY 'ERROR DETECTED'. DISPLAY WS-ERROR-MESSAGE. DISPLAY '-----------------------------------------------'. CALL 'DSNTIAR' USING SQLCA WS-DB2-ERR-MESSAGE WS-DB2-ERRMESG-LINE-LEN. 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
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 o
Length Component 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 sessions program. Last sessions 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: PATIENT_NO A121 A122 LASTNAME NULL NULL FIRSTNAME KISHOREKUMARREDDY SRIVIDHYA GENDER M F DATE_OF_BIRTH 8/27/1980 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 doesnt 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.
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 DB2s 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.
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.
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. This is used for batch processing. Locks will be acquired only as they are required, SQL statement by SQL statement. This is used for online processing.
ACQUIRE(USE):
o
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.
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 Simple Segmented Partitioned
Space Division No hierarchy; Only pages Segments Partitions
Contains A page can contain rows from different tables One Segment One Table Entire Partition table space One table
Bind parameters affecting table and tablespace locks: Lock Duration ACQUIRE(ALLOCATE) ACQUIRE(USE) RELEASE(DEALLOCATE) RELEASE(COMMIT) Locks are acquired or released Recommendation
When plan is allocated Use for batch processing As they are needed When plan is terminated Use for online processing Use for batch processing
When a commit occurs Use for online processing
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. 2. 3. 4. 5. Explain about the three types of tablespaces. Explain about the options available in the lock size. What is lock escalation? What is lock duration and how is it being achieved? Explain about the different isolation levels.
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 S U X IS IX SIX Meaning SHARE UPDATE EXCLUSIVE INTENT SHARE INTENT EXCLUSIVE SHARE/INTENT EXCLUSIVE Access Acquired Read only Read with intent to update Update Read only Update Read or update Access Allowed to Others Read only Read only No access Update Update Read only
The following list tells you how tablespace locks are acquired: Type of Processing MODIFY MODIFY MODIFY MODIFY MODIFY MODIFY SELECT SELECT SELECT SELECT SELECT SELECT LOCKSIZE ANY PAGE/ROW TABLESPACE ANY PAGE/ROW TABLESPACE ANY PAGE/ROW TABLESPACE ANY PAGE/ROW TABLESPACE Isolation CS CS CS RR RR RR CS CS CS RR RR RR Initial Lock Acquired IX IX X X X X IS IS S S S S
Handout: DB2
The following list tells us how Table Locks are acquired Type of Processing MODIFY MODIFY MODIFY MODIFY MODIFY MODIFY SELECT SELECT SELECT SELECT SELECT SELECT LOCKSIZE ANY PAGE TABLE ANY PAGE TABLE ANY PAGE TABLE ANY PAGE TABLE Isolation CS CS CS RR RR RR CS CS CS RR RR RR Table space Lock Acquired IS IS IS IS IS IS IS IS IS IS IS IS Table Lock Acquired IX IX X X X X IS IS S S S S
Following is the modes of page and row locks. Lock S U X Meaning SHARE UPDATE EXCLUSIVE Access Acquired Read only Read with intent to update Update Access Allowed to Others Read only Read only No access
The following list tells us how page Locks are acquired. Type of Processing SELECT/FETCH OPEN CURSOR for SELECT/FETCH FOR UPDATE OF UPDATE INSERT DELETE Page Lock Acquired S S U X X X Pages Affected Page by page as they are fetched All pages affected SELECT Page by page as they are fetched Page by page Page by page Page by page
The following list tells us how row Locks are acquired Type of Processing SELECT/FETCH OPEN CURSOR for SELECT SELECT/FETCH FOR UPDATE OF Row Lock Acquired S S U Rows Affected Row by row as they are fetched All rows affected Row by row as they are fetched
Handout: DB2
Type of Processing UPDATE INSERT DELETE Row Lock Acquired X X X Rows Affected Row by row Row by row 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 Update Table A/Page 1 Lock established Intermediate processing . . . Timeout Update Table A/Page 1 Lock (wait) Lock suspension -911 received Program 2
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 Update Table B/Page 1 Lock established Intermediate processing Update Table A/Page 1 Lock (wait) Deadlock Program 2 Update Table A/Page 1 Lock established Intermediate processing Update Table B/Page 1 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.
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 o o o o o
S U X IS IX 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 o
WITH HOLD clause LOCK TABLE statement

1. 2. 3. 4. 5. Explain about the lock modes of tablespace, table, page, and row locks. What is suspension? What is timeout and how can you resolve the problem? What is deadlock and how is it resolved by DB2? Explain about the different COBOL constructs that affect locking.
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 o o
ADD indicates that the plan is new. REPLACE indicates that an old plan by the same name will be replaced. Specifying ACTION (REPLACE) for a new plan does not cause the bind to failit 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.
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. 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
o o
When you specify USE, tablespace locks are taken when the tablespace is accessed. With ALLOCATE, table space locks are taken when the plan is first allocated. The preferred options for online application is USE and for batch is ALLOCATE. When you specify the COMMIT option, locks are released at commit time. When you specify DEALLOCATE, all locks are held until the plan finishes and is deallocated. The preferred option for online application is COMMIT and for batch is DEALLOCATE.
RELEASE: The options for RELEASE are COMMIT and DEALLOCATE.

o o
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 o o o
Repeatable read (RR) Read stability (RS) Cursor stability (CS) 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 -104 -118 Description Illegal symbol encountered in SQL statement. Table or view is illegally named in both data modification clause (UPDATE or DELETE) and the FROM clause. Not a valid DATE, TIME, or TIMESTAMP value. Undefined object name. Null indicator variable is missing.
-181 -204 -305
Handout: DB2
SQLCODE -408 -532 -545 -803 -811 -818 -904 -905 -911 -913 Description Value cannot be inserted or updated because it is incompatible with the column's data type. Deletion violates the named referential constraint. INSERT or UPDATE caused a check constraint violation. Cannot insert row because it would violate the constraints of a unique index. Must use a cursor when more than one row is returned as the result of an embedded select statement. Plan <> load module timestamp mismatch. The DBRM in the executing plan was not created from the same precompilation as the load module. The specified resource is unavailable Resource limit has been exceeded. The current unit of work has been rolled back. 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. 2. 3. 4. Explain about the different bind parameters. Explain the common SQL error codes. Explain the guidelines for application programming. Describe about EXPLAIN.
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 IPNAMES LOCATIONS LULIST LUMODES LUNAMES MODESELECT SYSAUXRELS SYSCHECKDEP SYSCHECKS SYSCOLAUTH SYSCOLDIST Contents To set up distributed TCP/IP connections Contains distributed location information for every accessible remote server Contains the list of LUNAMEs for a given distributed location (when multiple LUNAMEs are associated with a single location) Information on distributed conversation limits Contains information for every SNA client or server that communicates with the DB2 subsystem Information assigning mode names to conversations supporting outgoing SQL requests Information on the auxiliary tables required for LOB columns Column references for CHECK constraints CHECK constraint specifications The UPDATE privileges held by DB2 users on table or view columns 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
Handout: DB2
Table SYSCOLSTATS SYSCOLUMNS SYSCONSTDEP SYSCOPY SYSDATABASE SYSDATATYPES SYSDBAUTH SYSDBRM SYSDUMMY1 SYSFIELDS SYSFOREIGNKEYS SYSINDEXES SYSINDEXPART SYSINDEXSTATS SYSKEYS SYSLINKS SYSLOBSTATS SYSPACKAGE SYSPACKAUTH SYSPACKDEP SYSPACKLIST SYSPACKSTMT SYSPARMS SYSPKSYSTEM SYSPLAN SYSPLANAUTH SYSPLANDEP SYSPLSYSTEM Contents The partition statistics for selected columns Information about every column of every DB2 table and view Information regarding columns that are dependent on check constraints and user-defined defaults Information on the execution of DB2 utilities required by DB2 recovery Information about every DB2 database Information about the user-defined distinct types defined to the DB2 subsystem Database privileges held by DB2 users DBRM information only for DBRMs bound into DB2 plans Contains no information; this table is for use in SQL statements requiring a table reference without regard to data content Information on field procedures implemented for DB2 tables Information about all columns participating in foreign keys Information about every DB2 index Information about the physical structure and storage of every DB2 index Partitioned index statistics by partition Information about every column of every DB2 index Information about the links between DB2 Catalog tables Statistical information for LOB tablespaces Information about every package known to DB2 Package privileges held by DB2 users A cross-reference of DB2 objects required for DB2 packages The package list for plans bound specifying packages All SQL statements contained in each DB2 package Parameters for defined routines The systems (such as CICS, IMS or batch) enabled for DB2 packages Information about every plan known to DB2 Plan privileges held by DB2 users A cross-reference of DB2 objects required by DB2 plans The systems (such as CICS, IMS, or batch) enabled for DB2 plans
Handout: DB2
Table SYSPROCEDURES SYSRELS SYSRESAUTH SYSROUTINEAUTH SYSROUTINES SYSSCHEMAAUTH SYSSTMT SYSSTOGROUP SYSSTRINGS SYSSYNONYMS SYSTABAUTH SYSTABLEPART SYSTABLES SYSTABLESPACE SYSTABSTATS SYSTRIGGERS SYSUSERAUTH SYSVIEWDEP SYSVIEWS SYSVLTREE SYSVOLUMES SYSVTREE USERNAMES Contents The stored procedures available to the DB2 subsystem The referential integrity information for every relationship defined to DB2 Resource privileges held by DB2 users Privileges held by DB2 users on routines Information about every routine (that is, user-defined functions and stored procedures) defined to the DB2 subsystem Schema privileges granted to users All SQL statements contained in each DB2 plan bound from a DBRM Information about every DB2 storage group Character conversion information Information about every DB2 synonym Table privileges held by DB2 users Information about the physical structure and storage of every DB2 tablespace Information about every DB2 table Information about every DB2 tablespace Partitioned tablespace statistics by partition Information about every trigger defined to the DB2 subsystem System privileges held by DB2 users A cross-reference of DB2 objects required by DB2 views The SQL CREATE VIEW statement for every DB2 view A portion of the internal representation of complex or long views A cross-reference of DASD volumes assigned to DB2 storage groups The first 4000 bytes of the internal representation of the view; the remaining portion of longer or complex views is stored in SYSVLTREE 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:
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?
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.
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, // UNIT=SYSDA,SPACE=(CYL,(1,1)) //DSNUPROC.SYSUT1 DD DSN=&&SYSUT1, // UNIT=SYSDA,SPACE=(CYL,(5,1)) //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
Handout: DB2
o
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.
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='' //* //* UTILITY INPUT CONTROL STATEMENTS //* 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. //* //DSNUPROC.SYSIN DD * 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.
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='' //* //* UTILITY INPUT CONTROL STATEMENTS //* 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.
Handout: DB2
//* //DSNUPROC.SYSIN DD * REPAIR SET TABLESPACE REPAIR SET TABLESPACE SET TABLESPACE REPAIR SET TABLESPACE REPAIR SET INDEX /*
DSN8D61A.DSN8S61E DSN8D61A.DSN8S61E DSN8D61A.DSN8S61C DSN8D61A.DSN8S61R DSN8610.XPROJAC1
NOCOPYPEND NOCHECKPEND NOCHECKPEND NORCVRPEND 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='' //* //* UTILITY INPUT CONTROL STATEMENTS //* The REPORT statement generates a report of all objects //* referentially tied to the named table space //* //DSNUPROC.SYSIN DD * 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.
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 //* //DSNUPROC.SYSIN DD * 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=''
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 //DSNUPROC.SYSIN DD * 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='' //* //* UTILITY WORK DATASETS //* //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 //* //* UTILITY INPUT CONTROL STATEMENTS //* The first MERGECOPY statement creates a new full //* image copy for the DSN8D61A.
Handout: DB2
//* The second statement creates a new incremental copy //* for the named tablespace. //* //DSNUPROC.SYSIN DD * 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 //SYSPRINT DD SYSOUT=* //SYSTSPRT DD SYSOUT=* //SYSOUT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SYSTSIN DD * DSN SYSTEM (DSN) -START DATABASE (DSN8D61A) ACCESS (UT) END /*
Handout: DB2
//QUIESCE EXEC DSNUPROC,SYSTEM=DSN,UID='QUIESCTS',UTPROC='', // COND=(0,NE,STARTUT) //DSNUPROC.SYSIN DD * 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 //* //SYSPRINT DD SYSOUT=* //SYSTSPRT DD SYSOUT=* //SYSOUT DD SYSOUT=* //SYSUDUMP 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='' //* //* UTILITY INPUT CONTROL STATEMENTS //* 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.
Handout: DB2
//* //DSNUPROC.SYSIN DD * 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='' //* //* UTILITY WORK DATASETS //* //DSNUPROC.SORTWK01 DDUNIT=SYSDA,SPACE=(CYL,(2,1)) //DSNUPROC.SORTWK02 DDUNIT=SYSDA,SPACE=(CYL,(2,1)) //DSNUPROC.SYSUT1 DD DSN=&&SYSUT1, // UNIT=SYSDA,SPACE=(CYL,(2,1)),DCB=BUFNO=20 //DSNUPROC.UTPRINT DD SYSOUT=X //* //* UTILITY INPUT CONTROL STATEMENTS //* 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. //* //DSNUPROC.SYSIN DD * REBUILD INDEX (DSN8610.XPROJ2) REBUILD INDEX (DSN8610.XEMP1) DSNUM 3 REBUILD INDEX (ALL) TABLESPACE DSN8D61A.DSN8S61C /*
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='' //DSNUPROC.SYSIN DD * 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.
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.SORTWK01 DDUNIT=SYSDA,SPACE=(CYL,(2,1)) //DSNUPROC.SORTWK02 DDUNIT=SYSDA,SPACE=(CYL,(2,1)) //DSNUPROC.SORTOUT DD DSN=CAT.SORTOUT,DISP=(MOD,CATLG,CATLG), // UNIT=SYSDA,SPACE=(CYL,(2,1)) //DSNUPROC.SYSMAP DD DSN=CAT.SYSUT1,DISP=(MOD,DELETE,CATLG), // UNIT=SYSDA,SPACE=(CYL,(2,1)),DCB=BUFNO=20 //DSNUPROC.SYSUT1 DD DSN=CAT.SYSUT1,DISP=(MOD,DELETE,CATLG), // UNIT=SYSDA,SPACE=(CYL,(2,1)),DCB=BUFNO=20 //DSNUPROC.SYSDISC DD DSN=CAT.SYSDISC,DISP=(MOD,DELETE,CATLG), // UNIT=SYSDA,SPACE=(CYL,(1,1)) //DSNUPROC.SYSERR DD DSN=CAT.SYSERR,DISP=(MOD,DELETE,CATLG), // UNIT=SYSDA,SPACE=(CYL,(1,1))
Handout: DB2
//DSNUPROC.SYSREC00 DD DSN=CAT.LOAD.INPUT.DATASETA,DISP=SHR,DCB=BUFNO=20 //DSNUPROC.UTPRINT DD SYSOUT=X //* //* UTILITY INPUT CONTROL STATEMENTS //* The LOAD statement reloads the DSN8610.ACT table //* //DSNUPROC.SYSIN DD * 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='' //* //* UTILITY WORK DATASETS //* //DSNUPROC.SORTWK01 DDUNIT=SYSDA,SPACE=(CYL,(2,1)) //DSNUPROC.SORTWK02 DDUNIT=SYSDA,SPACE=(CYL,(2,1)) //DSNUPROC.SORTOUT DD DSN=CAT.SORTOUT,DISP=(MOD,DELETE,CATLG), // UNIT=SYSDA,SPACE=(CYL,(2,1)) //DSNUPROC.SYSUT1 DD DSN=CAT.SYSUT1,DISP=(MOD,DELETE,CATLG), // UNIT=SYSDA,SPACE=(CYL,(2,1)),DCB=BUFNO=20 //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=* //*
Handout: DB2
//* UTILITY INPUT CONTROL STATEMENTS //* The REORG statement reorganizes the second partition //* of DSN8D61A.DSN8S61E. //* //DSNUPROC.SYSIN DD * 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.
Handout: DB2
Sample RUNSTATS TABLESPACE JCL: //**************************************************************** //* //* DB2 RUNSTATS TABLESPACE UTILITY //* //**************************************************************** //* //UTIL EXEC DSNUPROC,SYSTEM=DSN,UID='STATSTS',UTPROC='' //* //* UTILITY INPUT CONTROL STATEMENTS //* 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. //* //DSNUPROC.SYSIN DD * 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='' //DSNUPROC.SYSIN DD * STOSPACE STOGROUP (*) /*
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 Developers 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
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 //SYSTSPRT DD SYSOUT=* //SYSPRINT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SYSTSIN DD * DSN SYSTEM(DSN) - DISPLAY DATABASE (DSNDB06) END /*
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 -DISPLAY ARCHIVE -DISPLAY BUFFERPOOL -DISPLAY DATABASE Description Displays input archive log information. Displays the current status of active and/or inactive bufferpools. Displays the status and pending information for DB2 databases, tablespaces, and indexes. 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 DATABASE LOCKS
-DISPLAY FUNCTION SPECIFIC Displays statistics about external DB2 user-defined functions. -DISPLAY GROUP -DISPLAY GROUPBUFFERPOOL -DISPLAY LOCATION -DISPLAY LOG -DISPLAY PROCEDURE -DISPLAY RLIMIT Displays information about the data sharing group. Displays information about the status of DB2 group bufferpools. Displays information for distributed threads. Displays information about the DB2 logs and the status of the log offload task. Displays information about stored procedures. Displays the status of the Resource Limit Facility, including the ID of the active RLST (Resource Limit Specification Table). Displays active and in-doubt connections to DB2 for a specified connection or all connections. 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. Displays the status of all active, stopped, or terminating utilities.
-DISPLAY THREAD -DISPLAY TRACE
-DISPLAY UTILITY
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.
Handout: DB2
There are nine DSN commands as follows: Command DSN Description 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. Used to request and obtain a dump when problems are suspected with another DSN subcommand. Builds an application plan or package from one or more database request modules. Produces the SQL DECLARE TABLE specification and a working storage data declaration section for COBOL Terminates the DSN session and returns the user to TSO. Deletes application plans and packages. 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. Executes an application program. The program can contain SQL statements, but this is not required. Executes the SPUFI program. This subcommand can be issued only when processing under ISPF; it cannot be submitted in a batch job.
ABEND BIND DCLGEN
END FREE REBIND RUN SPUFI
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.
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.
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. . . WORKING-STORAGE SECTION. . . 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
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. . WORKING-STORAGE SECTION. . . 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 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
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. . WORKING-STORAGE SECTION. . 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 = ? 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
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.
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 o
A stored procedure can return multiple row result sets back to the calling program. 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. To enable the stored procedure to return result sets, we must set the RESULTS SET parameter to a value greater than 0. We need to specify the WITH RETURN clause on each OPEN cursor statement for which result sets are to be returned. The cursors must not be closed by the stored procedure.
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
o o
The calling program issues the ASSOCIATE LOCATOR statement to assign a value to the result set locator that was previously defined. The calling program then issues the ALLOCATE CURSOR statement to associate the query with the result set. Finally, the program can execute a loop to FETCH the rows of the result set. Special SQL statementsDESCRIBE 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. The program code must be precompiled, compiled, and then link-edited into an executable form. The DBRM must be bound into a package; no plan is required for the stored procedure. When the program is link-edited, the LE/370 program library must be included. No impact to the program preparation process is required for the calling program A plan is still required for the calling program. Only the stored procedure (the called program) does not require a plan.
Preparing Stored Procedure Programs o o o o o
Creating Stored Procedures

Stored procedures are registered and managed within DB2 like other DB2 objects, using standard DDL statementsALTER, 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
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).
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.
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 its 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.
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.
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.
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 DB2s 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 nonclustered indexes are in RID format (Row ID), that is, direct pointers to the physical location the row is stored in.
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 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 o
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 nonkey 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.
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. 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.
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 its 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.
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.
Handout: DB2
References
Websites
http://publib.boulder.ibm.com
Books
DB2 Developers 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
Handout: DB2
STUDENT NOTES:

DB2 Handout v1.0

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

DB2 Handout v1.0

Загружено:

Авторское право:

Доступные форматы

Handout: DB2

Version: DB2/Handout/0308/1.0 Date: 20-03-08

Session 02: Introduction to DB2 Objects

Handout: DB2 RDBMS

Handout: DB2 Index Space

Physical Storage of Data

Hierarchy of DB2 Objects

Handout: DB2 Buffer Pool

Test Your Understanding

Session 03: Database Design

Why Should You Be Concerned with Database Design?

Activities involved in Database Design

Logical Database Design

MAT0027 EGL0010 4019 Patterson, Jane K PHI Philosophy PHI0010 CS00100

4/30/2002 12/30/2001 2002-04-30 200204-30

Neeld, Norris B Morrison, Xavier Q Brown, Richard E Juarez, Samantha

English Literature Music

SOC0102 MUS0002 SOC0102

8/1/2002 2002-04-30 200208-01

ENROLLMENT Entity in 2NF StudentID

2907 4019 4019 5145 6132 6132 8966 8966

EGL0010 PHI0010 CS00100 SOC0102 MUS0002 SOC0102 EGL0010 EGL0101

2001-12-30 2002-04-30 2002-04-30 2002-08-01 2002-04-30 2002-08-01 2001-12-30 2002-08-01

Physical database design

Handout: DB2 Implementing and Altering Database Design

Advantage of DB2 over VSAM

Test Your Understanding

Session 07: Data Integrity

Introduction to Data Integrity

Rules ensuring RI:

Data Type and Length

Handout: DB2 NULL Values:

Entity Integrity Referential Integrity Domain Integrity

Test Your Understanding

Session 08: Interaction with DB2

Interaction with DB2: Overview

Handout: DB2 DB2I

How to access DB2I:

DB2I Primary Option Menu

Following Options are available with DB2I:

Input Data Set

Output Data Set

Information about the Query Result

Options of CURRENT SPUFI DEFAULTS:

Query Result as Report

Online mode Batch mode DB2I QMF

The most common online mode includes:

Test Your Understanding

Session 09: SQL

DDL Create Storage Group

DDL Alter Storage Group

DDL Create Database

DDL Alter Database

DDL Create Tablespace

YES: Tracked. This is the default. NO: Not tracked.

DDL Alter Tablespace

DDL can do the following operations:

Test Your Understanding

Session 10: SQL

DDL Create Table

Constraints: Constraints are defined on two possible levels.

FOREIGN KEY constraint

PRIMARY KEY constraint:

DDL Alter Table