UNIT 1: DB2 PROGRAM PREPARATION

DB2 PROGRAM PREPARATION SQL STATEMENT FORMATS (DELIMITERS) DB2 DATA TYPES - CHARACTER DATA TYPE GRAPHIC DATA TYPE NUMERIC DATA TYPE DATE / TIME DATA TYPES NULL ATTRIBUTE NULL ATTRIBUTE (Cont.) (NOT NULL) WITH DEFAULT USER DEFINED DEFAULT VALUES HOST VARIABLES HOST VARIABLES (Cont.) DB2 DATA TYPES VS HOST VARIABLES HOST STRUCTURES SELECTION OF A SINGLE ROW COMPILERS DONT UNDERSTAND SQL DB2 PROGRAM PREPARATION STEPS PRECOMPILATION DCLGEN COMMAND ..1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 1.10 1.11 1.12 1.13 1.14 1.15 1.16 1.17 1.18 1.19

DCLGEN COMMAND (Cont.) SQL INCLUDE STATEMENT SQLCA DBRM DBRM (Cont.) COMPILATION AND LINK-EDIT BIND PACKAGE BIND PACKAGE (Cont.) PACKAGE PACKAGE (Cont.) COLLECTIONS APPLICATION PLAN CONSISTENCY TOKEN PROGRAM PREPARATION LOCATING PACKAGES AT EXECUTION TIME THE MISSING LINK PLAN AND PACKAGES BIND PLAN PACKAGE LIST BIND PLAN DBRMS

1.20 1.21 1.22 1.23 1.24 1.25 1.26 1.27 1.28 1.29 1.30 1.31 1.32 1.33 1.34 1.35 1.36

UNIT 2: DB2 INTERNALS

OVERVIEW DATA STORAGE DATA STORAGE (Cont.) DATA STORAGE (Cont.) DATA STORAGE (Cont.) NORMALIZATION 1-NF NORMALIZATION 1-NF (Cont.) NORMALIZATION 2-NF NORMALIZATION 2-NF (Cont.) NORMALIZATION 3-NF NORMALIZATION 4-NF NORMALIZATION 5-NF NORMALIZATION RECOMMENDATION OPTIMIZER OPTIMISER (Cont.) DB2 CATALOG AND DIRECTORY CATALOG STRUCTURE CATALOG STRUCTURE (Cont.) CATALOG STRUCTURE (Cont.) DB2 DIRECTORY DATA LOCKING LOCKING MECHANISM LOCKS VS LATCHES DEADLOCKS AND TIMEOUTS 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 2.13 2.14 2.15 2.16 2.17 2.18 2.19 2.20 2.21 2.22 2.23 2.24

UNIT 3

: CURSOR HANDLING
3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8

OVERVIEW DEFINING CURSORS DEFINING CURSORS (Cont.) SAMPLE PROGRAM FOR CURSORS CURSOR DECLARATION UPDATING /DELETING WITH THE CURSORS READ-ONLY CURSORS READ-ONLY CURSORS (Cont.)

UNIT 4: DYNAMIC AND STATIC SQL

DYNAMIC SQL AND STATIC SQL STATIC SQL DYNAMIC SQL DYNAMIC SQL (Cont) EXECUTE IMMEDIATE EXECUTE IMMEDIATE (Cont) NON-SELECT DYANMIC SQL FIXED-LIST SELECT FIXED-LIST SELECT (Cont) VARYING-LIST SELECT SELECT STATEMENT WITH VARYING LIST SELECT STATEMENT WITH VARYING LIST (Cont..) SQL DESCRIPTOR AREA (SQLCA) FUNCTION SQLDA FORMAT SQLDA COLUMN DESCRIPTION SQLDA Technique 1 SQLDA Technique 1(Cont) SQLDA Technique 2 SQLDA USAGE SUMMARY COMMIT AND ROLLBACK COMMIT AND ROLLBACK (Cont..) 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 4.15 4.16 4.17 4.18 4.19 4.20 4.21

UNIT 5: HANDLING NULLS AND ERRORS

HANDLING NULLS AND ERRORS SQLCA LAYOUT SQLSTATE SQLCA CODES SQLCA CODES USAGE ERROR HANDING ERROR HANDING (Cont) SCOPE OF WHENEVER ERROR MESSAGE FORMATTING ROUTINE ERROR HANDLING GENERAL RETRIEVING NULL VALUES INSERTING NULL VALUES SELECTING NULL VALUES HOST STRUCTURE INDICATOR VARIABLE HOST STRUCTURE INDICATOR VARIABLE (Cont..) HANDLING ARITHMETIC ERRORS HANDLING CONVERSION ERROR ARITHMETIC AND CONVERSION ERROR EXAMPLES EXAMPLE OF ARITHMETIC ERROR INDICATOR VARIABLE VALUES OTHER ERROR CONDITIONS 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12 5.13 5.14 5.15 5.16 5.17 5.18 5.19 5.20 5.21

UNIT 6: STORED PROCEDURES

STORED PROCEDURES OVERVIEW 6.1 STORED PROCEDURES: FLOW 6.2 STORED PROCEDURES: CONSIDERATIONS 6.3 STORED PROCEDURES: CONSIDERATIONS (Cont..) 6.4 STORED PROCEDURES: CALL SYNTAX 6.5 STORED PROCEDURES : LINKAGE CONVENTIONS 6.6 STORED PROCEDURES : LINKAGE CONVENTIONS (Cont..) 6.7 STORED PROCEDURES : DB2 SETUP 6.8 STORED PROCDEURES: DB2 SETUP (Cont.) 6.9

UNIT 7: DB2 UTILITIES

OVERVIEW CATEGORIES OF DB2 UTILITIES DATA CONSISTENCY UTILITIES DATA CONSISTENCY UTILITIES (Cont.) BACKUP AND RECOVERY UTILITIES DATA ORGANISATION UTILITIES CATALOG MANIPULATION UTILITIES DATA UTILITIES LOAD LOADING DATA IN ONE TALBE 7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8 7.9

DB2 PROGRAM PREPARATION

SQL STATEMENT FORMATS (DELIMITERS) HOST VARIABLES DB2 DATATYPES Vs HOST VARIABLES COMPLIER DOESNT UNDERSTAND SQL DB2 PROGRAM PREPARATION DCLGEN COMMAND DBRM COMPILATION AND LINK-EDIT BIND PACKAGE COLLECTION APPLICATION PLAN ISOLATION EXPLAIN

SQL STATEMENT FORMATS (DELIMITERS)

EXEC SQL UPDATE WHERE END-EXEC.

COBOL

PL/1

EXEC SQL UPDATE WHERE ;

Notes: Whatever the language used, SQL statement will always have to be enclosed between delimiters so that they can be easily spotted and replaced by something the compilers will be able to understand. Different delimiters are used for different languages. These are the standard delimiters used in COBOL and PL/1.

DB2 DATA TYPES - CHARACTER DATA TYPE

CHAR(n) / CHARACTER(n) Fixed length string between 1 and 254 bytes VARCHAR(n) Variable length string

LONG VARCHAR Variable length string

GRAPHIC DATA TYPE

GRAPHIC (n) Fixed length graphic string (from 1 to 127) VARGRAPHIC(n) Variable length graphic string LONG VARGRAPHIC Variable length graphic string

Notes : DB2 also supports DBCS (Double Byte Character Set) data like GRAPHIC

NUMERIC DATA TYPE

SMALLINT Half word (2 Bytes) Whole number between + and 32K

INTEGER / INT Full word (4 bytes) Whole number between + and 2 GB

NUMERIC(N) Max 31 digits DECIMAL(P,S) / DEC(P,S) Max 31 digits FLOAT(X) / REAL / DOUBLE PRECISION / FLOAT Full word or double word (4 bytes) Floating point number between 5.4E-79 and 7.25+75

Notes: When calculations have to be performed Numeric Data Type have to be used.

DATE / TIME DATA TYPES

DATE TIME TIMESTAMP

4 Bytes (YYYYMMDD) 3 Bytes (HHMMSS) 10 Bytes (YYYYMMDDHHMMSSNNNNNN)

Notes: DB2 does the necessary verifications on the data that is entered in these types. They can be manipulated using SQL scalar functions like DAYS, MONTH, YEAR .

NULL ATTRIBUTE
NULL is a special value indicating the absence of a value. Not consider for the column function evaluations (AVG) except COUNT. Two nulls are not considered as equal, except for GROUP BY ORDER BY

Uniqueness of a column unless you use UNIQUE WHERE NOT NULL

Notes: DB2 considers two null values as equal when it enforces the uniqueness of columns. You can change this by using the UNIQUE WHERE NOT NULL parameter.

NULL ATTRIBUTE (Cont.)

CHOICE TO BE MADE WHILE DEFINING COLUMNS:

(Default: NULLS allowed) NOT NULL WITH DEFAULT

Notes: The NULL attribute of a column is an important choice that will have to be made in cooperation with DBA.

(NOT NULL) WITH DEFAULT

Same as NOT NULL System default values ZERO for BLANKS for Blanks for Zero length string for Current date for Current time for Current timestamp for

NUMERIC columns fixed length CHARACTER columns fixed length GRAPHIC columns variable length CHARACTER and GRAPHIC columns. DATE data type. TIME data type. TIMESTAMP data type.

USER DEFINED DEFAULT VALUES

DEFAULT CAN BE EITHER Constant USER (Special Register)

CURRENT SQLID (Special Register)

NULL

Notes: It is possible to provide your own default value. It will be used by DB2 if you fail to supply a value in the INSERT statement.

HOST VARIABLES
Host language variables that can be referenced in a SQL statement to supply values to DB2 or to receive values from DB2. They must be preceded by : when referenced in a SQL statement. Example EXEC SQL SELECT PHONENO INTO :PHONENO FROM EMP WHERE EMPNO = :EMPNO END-EXEC.
Notes: Host variables will be used by DB2 to: Retrieve data and put it in to host variable for use by application program INSERT data in to a table or to update it from the data in the host variable. Evaluate a WHERE or HAVING clause using the data in the host variable. However, host variable cannot be used to represent a table, view or a column. The colon( : ) is necessary to distinguish a host variable from a column name.

HOST VARIABLES (Cont.)

Example-COBOL DATA DIVISION. WORKING-STORAGE SECTION. 01 IOAREA. 02 INPEMPNO PIC 9 (6). 02 INPNAME PIC X (15). PROCEDURE DIVISION. MOVE HIGGINS TO INPNAME. MOVE 00260 TO INPEMPNO. EXEC SQL UPDATE EMP SET LASTNAME =:INPNAME WHERE EMPNO =:INPEMPNO END-EXEC.

DB2 DATA TYPES VS HOST VARIABLES

DB2 SMALLINT INTEGER

COBOL PIC S9 (4) COMP PIC S9 (9) COMP

PL/1 BIN FIXED (15) BIN FIXED (31)

Notes: This table shows how to define a host variable in a program to match a given DB2 data type. It is important to use the correct data type in our program. Although DB2 will, in many cases, convert the data type to make the data type match, this could lead to bad performance and should be avoided.

HOST STRUCTURES
COBOL
01 PHONEEMP. 05 EMPNO PIC X (06). 05 FIRSTNAME. 49 49 05 MIDINIT PIC X (01). 05 LASTNAME. 49 49 05 WORKDEPT 05 PHONENO

FIRSTNAME-LEN FIRST NAME-TEXT

PIC S9 (4) COMP. PIC X (12).

LASTNAME-LEN LASTNAME-TEXT PIC X (03). PIC X (04).

PIC S9 (4) COMP. PIC X (15).

PL/1
DCL 1 5 5 5 5 5 5 PHONEEMP EMPNO FIRSTNAME MIDINIT LASTNAME WORKDEPT PHONENO CHAR (06), CAHR (12) VARYING, CAHR (01), CAHR (15) VARYING, CHAR (03), CHAR (04);

Notes: A host structure is a group of host variables referred to by a single name in an SQL statement. They are defined by statements of the host language.

SELECTION OF A SINGLE ROW

Using individual host variables:
EXEC SQL SELECT EMPNO, FIRSTNAME, MIDINIT, LASTNAME, WORKDEPT, PHONENO INTO :EMPNO, : FIRSTNAME, :MIDINIT, :LASTNAME, : WORKDEPT, : PHONENO FROM EMP WHERE EMPNO= :INPEMPNO END-EXEC.

Using the host structure:

EXEC SQL SELECT * INTO :DCLEMP FROM EMP WHERE EMPNO =:INPEMPNO END-EXEC. SELECT .INTOFROM. is valid only for Selects that return one row Notes: The examples shows how a SELECT statement can be written (to retrieve a single row), both by referring to individual host variables or by referring to a structure.

COMPILERS DONT UNDERSTAND SQL

Who will get rid of the EXEC SQL so that your program can be compiled? Answer: A PRECOMPILER will replace the EXEC SQL statements by CALLS It will also verify whether Your SQL statements are correct Your host variables match the DB2 data types But it doesnt access DB2 You must include EXEC SQL DECLARE TABLE Example: EXEC SQL DECLARE EMP TABLE (EMPNO CHAR (6) NOT NULL, LASTNAME CHAR(10)) END-EXEC.
Notes: Besides allowing the precompiled to verify the compatibility of host variables versus DB2 column data types (the precompiled doesnt access DB2, so YOU have to provide the DB2 data type info), it is good practice to use DECLARE TABLE, because it makes your programs more readable and more easily maintainable.

DB2 PROGRAM PREPARATION STEPS

The DB2 PreCompiler produces a DBRM and a modified source program with commented SQL statements

Source Program

PRECOMPILER

DCLGEN
DB2 Bind converts the DBRM in to an executable format. The DB2 Catalog stores the information about the plan and the package. Bind Package Modified Source

DBRM
Bind Plan

Package

Compiler

Plan

Compiled Source

The DB2 Directory stored the actual plan and the package.

Linkage-Editor

DB2
Catalog

DB2 Directory Load Module

PRECOMPILATION
The DB2 application program contains COBOL code with SQL statements embedded in it. The COBOL compiler will not be able to recognize the SQL statements and will give compilation errors. So before running the COBOL compiler, the SQL statements must be removed from the source code. Recompilation does the following: Searches for and expands DB2 related INCLUDE members. Searches for SQL statements in the body of the programs source code. Creates a modified version of the source program in which every SQL statement in the program is commented and replaces with a CALL to the DB2 runtime interface module, along with applicable parameters. Extracts all the SQL statements and places them in a Database Request Module (DBRM). Places A Timestamp token in the modified source and the DBRM to ensure that these two items are inextricably tied. Reports on the success of failure of the precompiled process.

DCLGEN COMMAND
DCLGEN (Declaration Generator) Option 2 in DB2 Produces SQL DECLARE TABLE statement Host language variable declaration for a table or view Table (DECLARE table SQL) EXEC SQL DECLARE EMPTABLE (EMPNO CHAR (6) NOTNULL, Lang LASTNAME CHAR(15)) END-EXEC. (Data declaration source code) 01 DCLEMP. 05 EMPNO PIC X (6), 05 LASTNAME PICX(15).

Include member

DCLGEN

DB2 Catalog

Notes: The DCLGEN tool provided with DB2I produces a COBOL copybook, which contains SQL DECLARE TABLE along with the WORKING-STORAGE host variable definitions for each column of the table. Input will be the language (COBOL, PL/1) and the table name.

DCLGEN COMMAND (Cont.)

This is the interactive DB2 environment to prepare the program for execution.
DB2 PRIMARY OPTION MENU 1SPUFI 2DCLGEN 3PROGRAM PREPARATION 4PRECOMPILE 5BIND/REBIND/FREE 6RUN 7DB2 COMMANDS 8UTILITIES D DB2I DEFAULTS X EXIT

Notes: When DCLGEN command is issued, DB2 read the catalog to fetch the column definition for the table, and will generate an include member with the DECLARE TABLE and the host structure. DCLGEN command can be eliminated by hard coding in the application program. But it is a good practice to run the DCLGEN command for every table that will be embedded in a COBOL program. Then every program that accesses that table can INCLUDE that generated copybook. This reduces a lot of unnecessary coding. DCLGEN will generate the host variables with the same name as the column name and if the program uses two tables which have common column names, then edit the copybook and change the names.

SQL INCLUDE STATEMENT SQLCA

SQL Stmt SQLCA

EXEC SQL statement and Update the Communication Area.

EXEC SQL INCLUDE SQLCA END-EXEC. Program after compilation

DCL 1 SQLCA. 2SQLCAID CHAR (8). 2SQLCABC. 2SQLCODE. 2. 2. 2. 2 SQLSTATE CHAR (5).

Notes: SQLCA fields are updated by DB2; the application program must check value. SQCA SQLCODE and SQLSTATE fields used to check result other field used for more detailed on condition. In order to know what happened in the other side in DB2 we must provide DB2 with program storage where it can set a return code and other information DB2 wants to communicate

DBRM

Data Base Request Module contains the programs source SQL statements.

A DBRM
Contains the extracted, parsed SQL source. Is stored as a member in a partitioned dataset. One member created per precompile. Will become Input to BIND.

DBRM (Cont.)
One DBRM corresponds to exactly one source module. The SQL statements in the source program will be replaced by CALL to module DSNHLI statement with the following parameters. DBRM name (SQLPROGN) Timestamp (SQLTIME) Statement number (SQLSTNUM) Other parameters are Address of host variables. Address of SQLCA.

At this stage, the two components, (DBRM and modified source), will part and wont see each other again until program execution. Therefore the CALL must include necessary information for DB2 to be able to locate the access path needed to execute the SQL statement associated with the CALL.
The information about the DBRM that have been bound in to the application plans and packages is stored in the SYSIBM.SYSDBRM in the DB2 catalog table. If a DBRM is created and is not bound cannot be referenced from this table. When DBRM is bound to a plan, all the SQL statements are placed in to thSYSIBM.SYSTMTDB2 catalog table. When a DBRM is bound in to a package all the SQL statements are placed in to the SYSIBM.SYSPACKSTMT table.

COMPILATION AND LINK-EDIT

After pre-compilation the program has to be COMPILED and LINK-EDITED. This can be

done using: DB2I panels. JCL. PL/1 PRECOMPILER can precede the DB2 PRECOMPILER. CICS COMMAND TRANSTLATOR may have to be invoked.

COMPILE

Object Module

DSNELI DSNELI

LINK-EDIT

DSNHLI

Load Module

Notes: The modified program is now ready to be compiled and link-edited. The link-edit will have to include the necessary modules for the call to work properly. The appropriate LANGUAGE INTERFACE must be included. The program that has been prepared here will run in one of the many execution environments like TSO, CICS, IMS. Depending on the environment, a different interface module will have to be included in the link-edit stop. The name of the module will vary, but they will all have an entry point DSNHLI.

BIND PACKAGE
DB2 Catalog DBRM BIND PACKAGE
Validates SQL

CREATE TABLE GRANT TO RUNSTATS UTILITY

OBJECT DEFINITION S SECURITY DEFINITION STATISTICS

SQL STATEMENTS

Resolves Table Names

Checks Privileges

Chooses an access path based on catalog statistics Stores source SQL in catalog Stores executable access path (PACKAGE) in Directory

DB2 Directory Collection

PACKAGE

BIND PACKAGE (Cont.)

Validating: Checking whether the table exist. Resolving user names: Completing table names with their owners incase they were omitted. Authority checking is performed to make sure that the BIND has the authority to create a program to access the data as required.

Access path selection consists of evaluating a number of different access paths and calculating their costs. The cheapest one will be retained. Those cost estimates are based on statistics, which are stored in the catalog. The RUNSTATS utility must be run to keep those statistics up-to-date.
The executable access code is stored in the directory, and the source SQL statements are stored in the DB2 catalog. They may be needed if the access path were to be evaluated at some later time.

PACKAGE
DBRM

BIND PACKAGE (collx) MEMBER (dbrma)

BIND PACKAGE (colly) MEMBER (dbrma)

dbrma

dbrma

Package Name = Collection_id.Package_id

PACKAGE (Cont.) A package is a single bound DBRM with optimized access path. By using packages the table access logic is packaged at a lower level for granularity at the package or program level. To execute a package it must be first be included in the package list of a plan. Package can never be directly executed; they are only executed when the plan in which they are contained is executed. A plan can consist of one or more DBRMs, one or more packages, or a combination of packages and DBRMs.

Package information is stored in its own DB2 catalog tables. When a package is bound, DB2 reads the following catalog tables:
SYSIBM.SYSCOLDIST, SYSIBM.SYSCOLUMNS, SYSIBM.SYSFIELDS, SYSIBM.SYSINDEXES,SYSIBM.SYSPACKAGES,SYSIBM.SYSTABLES SYSIBM.SYSPACKAUTH,SYSIBM.SYSTABLESPACE and SYSIBM.SYSUSERAUTH Of the above tables SYSIBM.SYSUSERAUTH table is read only for BIND ADD. The DB2 catalog stores information only about the packages. The executable form of the package is stored as a skeleton package table in the DB2 directory in the SYSIBM.SPTOI1 table. A package also contains a location identifier, a collection identifier and a package identifier. These are identifiers used to uniquely identify the packages.

COLLECTIONS

A collection is a set of Packages.

Test
pkg1 pkg1 pkg2

Prod

pkg2

A collection is IMPLICITLY created a first BIND PACKAGE referring to that collection.

BIND PACKAGE (test) MEMBER (pkg1) BIND PACKAGE (test) MEMBER (pkg2)

Notes: A collection is a user-defined name (1 to 18 characters) that the programmer must specify for every package. A collection is not an actual, physical database object. A collection is a grouping of DB2 packages. By specifying different collection identifier, for a package, the same DBRM can be bound to different packages. This capability permits the programmer to use the same DBRM for different packages, enabling easy access to tables that have the same structure, but different owners.

APPLICATION PLAN

A plan is an executable module containing the access path, logic provided by the DB2 optimiser. It can be composed of one or more DBRMs and packages. Plans are created by the BIND command. When a plan is bound, DB2 reads the following catalog tables:

SYSIBM.SYSCOLDIST,SYSIBM.SYSCOLUMNS,SYSIBM.SYSFIELDS, SYSIBM.SYSINDEXES,SYSIBM.SYSPLANS,SYSIBM.SYSPLANAUTH, SYSIBM.SYSTABLES, SYSIBM.SYSTABLESPACE and SYSIBM.SYSUSERAUTH

The SYSIBM.SYSUSERAUTH table is read only for BIND ADD.

CONSISTENCY TOKEN PROGRAM PREPARATION

Pgm3

Pgm1

Pgm2

PRECOMPILE

Mprog2

Mprog3

Mprog1

Dbrm1

Dbrm3

Dbrm2

Compile / Link

BIND PACKAGE DB2 Directory

Load module

Notes: The precompilation TIMESTAMP is included in each generated CALL in the modified source. The other twin brother (the DBRM) also contains this timestamp. It will be used by DB2 at program execution time to locate the correct package for the correct load module.

LOCATING PACKAGES AT EXECUTION TIME

CALL DNHLI (dbrm1, , 1) . . CALL DSNHLI (dbrm1, , 2) . . . . CALL DSNHLI (dbrm2, . .

,1)

DB2 Directory

collx

colly

call

Dbrm1

Dbrm3

Dbrm1

call call

Dbrm2

collz

THE MISSING LINK

. CALL DSNHLI (dbrm1, ,1) CALL DSNHLI (dbrm2,

Notes: In between the load module and the packages there is a need for an additional structure that will guide DB2 in its searches for the appropriate package. This structure is called a plan and it will contain a package list, a list of logical pointers to packages. DB2 will look for the right (same timestamp) package by using each entry in the package list in turn until it has a hit. The mechanism is very similar to the search mechanism by the operating system to locate a member of a PDS on a concatenation of PDSs. Running a DB2 program is done by associating the plan with the load module. This is done outside the program.

PLAN AND PACKAGES

A PACKAGE can be located and executed only via a PLAN A PLAN contains a PACKAGE list a list of pointers to packages. The DBRM name and the TIMESTAMP provided with the CALL are used to locate the correct package via the package list.

Notes: The package list determines which package will be used.

BIND PLAN PACKAGE LIST

CALL DSNHLI (dbrm1, CALL DSNHLI (dbrm1,

,1) ,2)

CALL DSNHLI (dbrm1,

,2)

RUN PROGRAM (Imoda) PLAN (plana) Dbrm1

collx Dbrm3

colly

Dbrm1 Collx.dbrm1, collz. * Dbrm2

Dbrm4

BIND PLAN (plana) PKLIST (collx.dbrm1, collz. *)

collz

Notes: A PACKAGE LIST is a list of references to individual packages (E.G. COLLX.DBRM1) or to sets of packages (e.g. COLLY. *). A package list makes specific parts of the directory eligible for the package search.

BIND PLAN DBRMs

plana

Collx.dbrm1, collz. *

BIND PLAN (plana) PLSIST (collx.dbrm1, collz. *)

plana

Collx.dbrm1, collz. *
Dbrma Dbrm1

BIND PLAN (plana) PKLIST (collx.dbrm1, collz. *) MEMBER (dbrma, dbrm1)

plana

Dbrm1

Dbrm2

BIND PLAN (plana) MEMBER (dbrm1, dbrm2)

Notes: Packages were introduced with DB2 V2.3, but plans already existed. Previously, the DBRMs were bound directly into the plan structure itself. For compatibility reasons, DB2 also supports this today.

UNIT 2: DB2 INTERNALS : OVERVIEW

OVERVIEW DATA STORAGE THE OPTIMIZER

DB2 CATALOG & DIRECTORY

DATA LOCKING

DATA STORAGE

There are two types of DATA STORAGE.

Logical storage
Physical storage

Notes: Logical storage is how the user sees the data. Physical storage is how data is actually stored. The total collection of stored data is divided into a number of user databases and system databases. Each database is divided into number of table spaces and index spaces. A space is a dynamically extendible collection of pages, where a page is a block of physical storage. The pages in a given space are all of the same size 4KB for index spaces and either 4KB or 32KB for table spaces. Each table space contains one or more tables. A stored table is a physical representation of a base table; it consists of a set of stored records, one for each row of the base table. A given stored table must be wholly contained with in a single table space. Each index space contains exactly one index. A given index must be wholly contained in an index space. A given stored table and all its associated indexes must be wholly contained with in a single database.

DATA STORAGE (Cont.)

View
T A B LE SP A C E

View

View

Stored Table

Stored Table

Stored Table

Stored Table

Catalog Table

Catalog Table

Stored Table

Stored Table

Catalog Table

Stored Table
IN D E X SP A C E

Index Index Index

User Database

User Database

Catalog Database

Storage Group 1

Storage Group 1

DATA STORAGE (Cont.)

DATABASES: A database is a collection of logically related objects. That is a collection of stored tables that are related together in some way, together with their associated indexes and the various spaces that contain those tables and indexes. It thus consists of a set of table spaces and index spaces. TABLESPACES: A table space can be considered a logical address space on secondary storage that is used to hold one or more stored tables. As the amount of data in those tables grows, storage will be acquired from the appropriate storage group and added to the table space. One table space can be up to approximately 64 billion bytes in size. The table space is the storage unit for recovery and reorganization purposes, i.e., it is the unit that can be recovered via RECOVER utility or reorganized using the REORG utility. If the table space is very large, then recovery and reorganization can take a very long time. Table spaces can be of three types 1. Simple 2. Partitioned 3. Segmented

A simple table space can contain more than one stored table, though one is the best option. One reason for having more than one table is that related data can be kept together, making the access faster. Partitioned table spaces are intended for tables that are sufficiently large i.e. operationally difficult to deal with the entire table as a single unit. A partitioned table space thus contains exactly one table, partitioned in accordance with the value ranges of a partitioning column or column combination. In the segmented table spaces, the space with in the table space is divided in to segments, where each segment contains logically contiguous n pages where n must be a multiple of 4 and must range between 4 and 64 and should be the same in all segments. No segment will have records of more than one stored table and if the table grows in size to fill a segment a new segment will be obtained

DATA STORAGE (Cont.)

INDEXSPACES: An index space is to an index like a table space is to a table. The correspondence between indexes and index spaces are always one-to-one, there are no data definition statements to index spaces. Thus there is no CREATE INDEX SPACE but only CREATE INDEX, which will automatically create the index space. Index spaces are always 4 KB in size. INDEXES: Indexes in DB2 are based on a structure known as B-Tree. B-Tree is a multilevel, tree structure index with a property that tree is always balanced, which means that all the leaf entries in the structure are equidistant from the root of the tree and this property is maintained as new entries are inserted into or existing entries are deleted from the tree. STORAGE GROUPS: Storage groups are named collections of direct access volumes, all of the same device type. Each table space each index space normally has an associated storage group. When storage is needed for the space or partition, it is taken from the specified storage group. Within each storage group, spaces and partitions are stored using VSAM linear datasets. DB2 uses VSAM for such things as direct access space management, dataset cataloging, and physical transfer of pages into and out of memory.

NORMALIZATION 1-NF
Normalization is the process of steps that will identify for elimination of redundancies in a database design. FIRST NORMAL FORM: Eliminating repeating groups

Unnormalized EMPL EMPNO LASTNME WORKDEPT DEPTNAME SKILL1 SKILL2 SKILLN

000030 000250 000270 000300

KWAN SMITH PEREZ SMITH

GRE BLU RED BLU

OPERATIONS PLANNING MARKETING PLANNING

141 002 415 011

011 447 032

067

Notes: Eliminating Repeating Groups: One of the first rules of relational tables is that all the rows must have the same number of columns and each column must mean the same thing in the same sequence in each row. In the example of EMP table, if it were required to represent the multiple skills of employees, this would be represented in an additional table where each skill for a given employee is represented in a row. If new skill is created and an employee already has the maximum number of skills allocated in the data structure, then the entire file structure and all the programs have to be changed, in an unnormalized file structure. If this table is normalized, then the new skill simply becomes a new row.

NORMALIZATION 1-NF (Cont.)

NORMALIZED TO 1NF-EMPL
EMPNO 000030 000250 000270 000300 LASTNAME KWAN SMITH PEREZ SMITH WORKDEPT GRE BLU RED BLU DEPTNAME OPERATIONS PLANNING MARKETING PLANNING

EMPL_SKILL TABLE
EMPNO SKILLSKILLDESC 000030141RESEARCH 000250002BID PREP 000250011NEGOTIATION 000250067PROD SPEC 000270415BENEFITS ANL 000270447TESTING 000300011NEGOTIATION 000300032INV CONTROL

NORMALIZATION 2-NF
Second normal form Eliminate the columns that depend only on part of the key

EMPNO
000030 000250 000250 000250 000270 000270 000300 000300

SKILL
141 002 011 067 415 447 001 032

SKILLDESC
RESEARCH BID PREP NEGOTIATION PROD SPEC BRNRFITS ANL TESTING NEGOTIATION INV CONTROL

Notes: Second normal form requires a close look at proposed tables that have multi-column primary keys. The objective is to eliminate all columns from a table design that are dependent on only part of the primary key

NORMALIZATION 2-NF (Cont

Normalized - 2NF EMPNO 000030 000250 000250 000250 000270 000270 000300 000300 SKILL 141 002 011 067 415 447 011 032 DATE CERT SKILLSKILLDESC 002BID PREP 011NEGOTIATION 032INV CONTROL 067PROD SPEC 141RESEACH 415BENEFITS ANL 447TESTING

Notes: In the example of EMP table in the 1NF the skills of the employees was matched with the employees in a separate table and the skill description. But skill description depends only upon the skill number. The problems that arise due to this are: 1. The skill description will be repeated every time the skill is repeated. 2. If this description for the skill changes, then multiple rows will need to be changed, risking some update anomalies (data inconsistency due to not changing all rows). 3. If an employee is the sole source for a given skill and that person leaves the company, that particular skill and skill description is lost forever. (Delete anomaly).

NORMALIZATION 3-NF
Third normalization: Eliminate columns that dont depend on the key at all. Unnormalized EMPL EMPNO LAST NAME WORK DEPT DEPTNAME 000030 KWAN GRE OPERATIONS 000250 SMITH BLU PLANNING 000270 PEREZ RED MARKETING 000300 SMITH BLU PLANNING

MGRNO 000080 000010 000020 000010

Normalized to 3NF EMPNO LASTNAME 000030 KWAN 000250 SMITH 000270 PEREZ 000300 SMITH WORKDEPT GRE BLU RED BLU

DEPTNO BLU GRE RED

DEPTNAME PLANNING OPERATIONS MARKETING

MGRNO 000010 000080 000020

Notes: Third normal form tables ensure that each columns value depends on the primary key or some other column with the table. In the example of the EMP table the Department number in the EMP table, that is necessary to reflect the relationship between the employee and the department tables many employees work for one department and the department name column is a fact about the department number column. The same three problems exist here as the 2NF and can be solved in the same way i.e. an additional table where the department number is the primary key and department name is dependent upon it.

NORMALIZATION 4-NF

Fourth normalization: Isolate independent multiple relationships, i.e. no table may contain more than 1:n or n:m relationships that arent directly related.

Notes: Suppose in the skills table of the 1NF the language that each employee knows is also included along with skills of each employee. So, now there is one-to-many relationship between employee and language in the same table, since an employee can know more than one language, which is a violation of fourth normalization. A separate table has to be created isolating language from skills UNLESS THERE IS A DIRECT RELATIONSHIP BETWEEN LANGUAGE AND SKILL, i.e. an employee requires certain language for certain skill, they should remain together.

NORMALIZATION 5-NF

Fifth normalization: Isolate related multiple relationships

Notes: Suppose in the above example the skills and languages are related to each other, there may be some other reason why they should be separated in to yet another table to resolve many-to-many relationship between them. So we should have three tables 1. 2. 3. Employee-Skill Employee-Language Skill-Language

NORMALIZATION RECOMMENDATION

Notes:

Always Normalize to Third Normal Form.

Analyze the tables Views To Evaluate The Benefits of the denormalizing.

Normalization solves many problems like it eliminates redundancies that saves disk space and reduces update and delete anomalies. It helps in keeping data model flexible, which is a key factor in todays world of rapidly changing business requirements, but it may impact performance depending on user requirements if the datas are separated into many tables, but it is often retrieved, many I/O operations are required than if it is not normalized. These decisions and trade offs between normalizing and denormalizing has to be decided.

OPTIMIZER

SQL

DB2 Optimizer Optimized Access Path

DB2 Catalog

Query Cost Formulas

Notes: The Optimizer is the most important part of DB2. It is the brain of DB2. It analyzes the SQL statements and determines the most efficient access path available for satisfying the statement. In the SQL statements, we only say what we want, the optimizer decides how to get the things that we have asked for. It accomplishes this by parsing the SQL statements to determine which table must be accessed. It then queries statistics stored in DB2 catalog to determine the best method of accomplishing the tasks necessary to satisfy the SQL statements.

OPTIMIZER (Cont.)
Physical Data Independence:
The concept of optimizing data access in the DBMS is one of the most power full capabilities of DB2. Access to DB2 data is achieved by telling DB2 what you want and not how to get it. DB2 s optimizer accomplishes this task thus giving physical data independence. Regardless of how data is physically stored and manipulated, DB2 and SQL can still access data. This separation of access criteria from physical storage characteristics is called physical data independence. If indexes are removed DB2 can still access data (the performance is reduced). If a column is added to the table being accessed, the data can still be manipulated by DB2 with out changing the program code. This is all possible because the physical access path to DB2 data are not coded by programmers but generated by DB2.

Working of the optimizer:

The optimizer performs complex calculations based on a host of information. Four steps of optimizers are

1. Receive and verify the SQL statement. 2. Analyze the environment and optimize the method of satisfying the SQL statement. 3. Create machine-readable instructions to execute the optimized SQL. 4. Execute the instructions or store them for future execution. The optimizer has many types of strategies for optimizing the SQL. The strategy is a cost based one. This means that the optimizer will always attempt to find an access path that will reduce the overall cost. To accomplish this the DB2 optimizer evaluates four factors for each potential access path. Those factors are 1.CPU cost 2.I/O cost 3.DB2 catalog statistics 4.SQL statements.

DB2 CATALOG AND DIRECTORY

DB2 has a set of tables that function as a repository for all DB2 objects, the DB2 Catalog and DB2 Directory. The entire DBMS relies on the DB2 Catalog. The DB2 Catalog is composed of eleven table spaces and 43 tables all in a single database DSNDB06. Each DB2 Catalog table maintains data about an aspect of DB2 environment. In the respect, DB2 catalog functions as a data dictionary for DB2, supporting and maintaining data about the DB2 environment. The DB2 catalog records all information required by DB2 about STOGROUPS, data spaces, table spaces, partitions, tables, columns, views, synonyms, aliases, indexes, index keys, foreign keys, relationships, plans, packages, DBRM s, database privileges, plan privileges, system privileges, table privileges, view privileges, use privileges, image copy datasets, REORG executions. The DB2 catalog is built, maintained and used as a result of the creation of objects defined to the catalog. In other words as the user creates or modifies the DB2 objects, metadata (data about data) is being accumulated in the catalog. The DB2 catalog can be updated using the RUNSTATS utility.

CATALOG STRUCTURE
The DB2 catalog is structured as DB2 tables, but they are not standard tables. Many of the DB2 catalog tables are stored together hierarchically using a special relationship called link. The DB2 catalog table SYSIBM.SYSLINKS store the information defining the relationships between other catalog tables.
SYS TABLESPACE SYSTABLEPART

SYSTABLES SYSCOLUMNS SYSRELS SYSINDEXES

SYSSYNONYMS

SYSTABAUTH

SYSFIELDS SYSCOLDIST SYSCOLDISTSTATS SYSTABSTATS

SYSLINKS SYS FOREIGNKEYS

SYSINDEXPART

SYSCOLAUTH

SYSKEYS

DB2 Catalog: Table spaces, Tables and Indexes SYSINDEXSTATS

CATALOG STRUCTURE (Cont.)

SYSPACKAGE

SYSAUTH

SYSPKSYSTEM

SYSPACKLIST

SYSPACKDEP

SYSPACKLIST SYSPLAN SYSPLSYSTEM SYSDBRM SYSPLANAUTH SYSPLANDEP

SYSSTMT

DB2 Catalog: Plans & Packages

CATALOG STRUCTURE (Cont.)

SYSVTREE

SYSVLTREE

SYSVIEWS

SYSVIEWDEP

SYSSTOGROUP

SYSDATABASE

SYSVOLUMES

SYSDBAUTH

SYSCOPY

SYSSTRINGS

SYSUSERAUTH

SYSRESAUTH

DB2 Catalog: Views, Stogroups and Database

DB2 DIRECTORY
DB2 uses a second data directory, other than the catalog, called the DB2 Directory for storing detailed technical information about the aspects of DB2 s operation. The DB2 directory is for DB2 s internal use only. The SQL statements cannot access the data in the DB2 directory.

DB2 Directory Utilities SYSUTIL SYSUTILX DBD01 SYSLGRNG SPT01 SCT02

Active Logs Archive Logs

BIND

DB2 Catalog

Application Database

DATA LOCKING
DB2 guarantees data integrity by using several locking mechanisms.

Why data locking?

When multiple users can access and update the same data at the time, a locking mechanism is required. This mechanism must be capable of differentiating between stable data and uncertain data. Stable data has been successfully committed and is not involved in an update in a current unit of work. Uncertain data is currently involved in an operation and could get modified. If two users try to update the same record at the same time, or if one user deletes a record while some other user is trying to update it, with out proper locking strategy and locking mechanisms, the data integrity can go haywire. To avoid such situations a DBMS uses a locking mechanism.

LOCKING MECHANISM

DB2 supports locking at three levels. Table space level, Table level and Page level. Locks can be taken at any level in the locking hierarchy without taking a lock at the lower level. However, locks cannot be taken at a lower level with out compatible higher-level lock also being taken. For example, we can take a table space lock with out taking any other lock, but for taking a page lock we have to first get a table space lock. Different modes of locking are:

Locks to enable reading of data. Locks to enable updating of data.

Table space/ Table locks Lock S U X IS Meaning SHARE UPDATE EXCLUSIVE INTENT SHARE Access Required Read only Read with intent to update Update Read only Access Allowed To Others Read only Read only No access Update

IX
SIX Page locks S U

INTENT EXCLUSIVE
SHARE/INTENT EXCLUSIVE

Update
Read or Update

Update
Read only

SHARE UPDATE

Read only Read with intend to update

Read only Read only

EXCLUSIVE

Update

No access

LOCKS VS LATCHES
A true lock is handled by DB2 using IRLM (IMS Resource Lock Manager). DB2 will try to lock pages without going to IRLM, whenever it is possible. This type of lock is referred to as a latch. True locks are always set in the IRLM. Latches, by contrast are set internally by DB2 with out going to the IRLM. When a latch is taken instead of lock, it is handled by internal DB2 code. So cross memory service calls to IRLM is eliminated. Also a latch requires about one third of instruction as a lock. Therefore, latches are more efficient than locks because they avoid the overhead associated with calling an external address space. Latches are used when a resource serialization is required for a short time. Prior to DB2 version 3, latches were generally used to lock only DB2 index spaces and internal DB2 resources. When running V3, DB2 uses latching more frequently. This includes data page latches.

DEADLOCKS AND TIMEOUTS

Locks can be used to solved problems of concurrency, and ensure data integrity. But unfortunately, locking introduces a problem called deadlock. Deadlock is a situation in which two or more transactions are in simultaneous wait state, each waiting for one of the others to release a lock before it can proceed. If a deadlock occurs the system will detect and break it. Breaking a deadlock involves choosing one of the deadlock transactions as the victim and depending on the transaction manager concerned, either rolling it back automatically or requesting it to roll back itself. Either way, the transaction will release its locks and thus allow some other transactions to proceed. In general, therefore, any operation that requests a lock may be rejected with a negative SQL code indicating the transaction has been selected as the victim of a deadlock situation and has either been rolled back or request to roll back. A time-out is caused by the unavailability of a given resource. Time outs are caused when a transaction has to wait for a resource, which is held by another transaction. The duration of the waiting time, after which the time-out should occur is determined by the IRLMRWT DSNZPARM parameter

UNIT 3. CURSOR HANDLING

OVERVIEW

DEFINING CURSORS CURSOR DECLARATION

UPDATING/DELETING WITH CURSORS

READ ONLY CURSORS

DEFINING CURSORS
Two types of embedded SQL SELECT STATEMENTS. Singleton SELECT Cursor SELECT SQL statements operate on a set of data and return a set of data. Host language programs, on the other hand, operate on a row at a time. A singleton SELECT is simply on SQL SELECT statement that returns a single row. The singleton SELECT differs from the ordinary SELECT statement in that it contains an INTO clause. The INTO clause is where you code your host variables that accept the data returned by DB2. But if such a SELECT statement returns more than one row, the values of the first row is placed in the host variable and DB2 issues an SQLCODE of 811. So, in your application program, if the SELECT will return more than one row then one must use Cursors. DB2 uses cursors to navigate through a set of rows returned by an embedded SQL SELECT statement. A cursor can be compared to a pointer. The programmer declares a cursor and defines the SQL statement for the cursor. After that you can use the cursor like a sequential file. The cursor is opened, rows are fetched from the cursor, and one row at a time and at the end of processing the cursor is closed.

DEFINING CURSORS (Cont...)

The four operations that must be performed for the successful working of cursors. DECLARE - This statement defines the cursors, gives a name to it and assigns an SQL statement to it. The DECLARE statement does not execute the SQL statement but merely defines it. OPEN This readies the cursor for row retrieval. OPEN is an executable statement. It reads the SQL search fields, executes the SQL statements and sometimes builds the result table. FETCH - This statement returns data from the result table one row at a time to the host variables. If the result table is not built at the OPEN time, it is built during FETCH. CLOSE Releases all resources used by the cursor.

SAMPLE PROGRAM FOR CURSOR

WORKING-STORAGE SECTION. EXEC SQL INCLUDE dclgenmem END-EXEC. EXEC SQL INCLUDE SQLCA END-EXEC. PROCEDURE DIVISION. EXEC SQL DECLARE CUR CURSOR FOR SELECT * FROM S END-EXEC. EXEC SQL OPEN CUR END-EXEC. PERFORM FETCH-PARA UNTIL SQLCODE = 100. FETCH-PARA. EXEC SQL FETCH CUR INTO :DCLS END-EXEC. IF SQLCODE = 100 EXEC SQL CLOSE CUR END-EXEC STOP RUN END-IF. DISPLAY DCLS.

CURSOR DECLARATION
EXEC SQL DECLARE CURSOR-NAME CURSOR (WITH HOLD) FOR select-statement A Cursor : Is required for select of multiple rows Is never used for INSERT May be reused (CLOSE + new OPEN) Will be closed at COMMIT Unless declared with WITH HOLD Multiple Cursors : May be defined in a program May work with the same table May be open simultaneously

Notes: The DECLARE CURSOR statement is used to associate a cursor with the SQL statement. No data access is performed at this stage. The WITH HOLD option is important if you want to issue COMMIT inside the fetch loop. If you omit this keyword, you will have to re-open (and DB2 will have to re-execute the access path) the cursor after each COMMIT, because its position will be lost due to the COMMIT.

UPDATING /DELETING WITH THE CURSORS

Row-at a time UPDATE OR DELETE (Positioned Updates) - Declare FOR UPDATE OF.option EXEC SQL DECLARE CUR1 CURSOR FOR SELECT EMPNO, LASTNAME FROM EMP WHERE WORKDEPT =: DPT FOR UPDATE OF LASTNAME and use WHERE CURRENT OFoption EXEC SQL OPEN CUR1 EXEC SQL FETCH CUR1 INTO: EMPNO, NAME IF EXEC SQL UPDATE EMP SET LASTNAME =: NEWNAME WHERE CURRENT OF CUR1. EXEC SQL FETCH CUR1 INTO: EMPNO, NAME IF THEN EXEC SQL DELETE FROM EMP WHERE CURRENT OF CUR1. Notes: Once the cursor is positioned on a row, you can do a Positioned update or delete. It means that the update/delete doesn't require that DB2 re-access the data and it would have to do if you used delete where key =.

READ-ONLY CURSORS
EXEC SQL DECLARE cursor-name CURSOR FOR select-statement FOR FETCH/READ ONLY The SELECT Statement contains FOR FETCH ONLY/FOR READ ONLY ORDER BY UNION or UNION ALL The first SELECT contains DISTINCT A FUNCTION OR EXPRESSION The outer subselect contains GROUP BY / HAVING

The same table is used in SELECT statement and SUBQUERY

Select from multiple tables (join) A nested table expression is used in the first from Isolation UR is used without FOR UPDATE OF

READ-ONLY CURSORS (Cont...)

A Read-only cursor cannot be the target of a positioned update/delete

However, some cursors are read/only. The reason behind this is that for some SQL statements, it will not be possible for DB2 to position itself before the first result row without accessing the entire result set. Take the example of a SELECT..ORDER BY. DB2 will have to get all qualifying rows and sort them before it can position its cursor. In addition, the cursor will be positioned on an intermediate result table and not on the actual data itself.

UNIT 4. DYNAMIC AND STATIC SQL

OVERVIEW

STATIC SQL

DYNAMIC SQL

STATIC SQL
STATIC SQL Can be used if the statements TYPE TABLES COLUMNS, WHERE- Clause are known when you write your program The complete SQL statement is contained in the program, except for host variable referring to COLUMN VALUES. BIND creates the access path Only the EXECUTE privilege is checked before execution of the access path Program
EMPN Get host variable contents

DYNAMIC SQL
DYNAMIC SQL MUST be used if ANYTHING ELSE THAN COLUMN VALUES are unknown at program preparation The statement is contained in a host variable BIND cannot create an access path but an empty package will be created. Security is checked at execution time when the access path is created
Table ?

Build or Get statements

Column

name ?

SQL statement?

DYNAMIC SQL (Cont)

NON-SELECT DYNAMIC SQL EXECUTE IMMEDIATE PREPARE FOR EXECUTE IMMEDIATE

SELECT DYNAMIC SQL

FIXED-LIST SELECT VARYING-LIST SELECT

EXECUTE IMMEDIATE
EXECUTE IMMEDIATE implicitly prepares and executes complete SQL statements coded in host variables. Only a sub-set of SQL statements is available when you use this command, the prominent being SELECT and so this call of dynamic SQL cannot be used for data retrieval. So if you want any data to be retrieved then the SQL portion of your program consists of two steps. First moving the complete text for the statement to be executed to be executed into the host variable and second issue an EXECUTE IMMEDIATE command giving the host variable as an argument. The statement is prepared and execute automatically.
Ex: WORKING-STORAGE SECTION. : EXEC SQL INCLUDE SQLCA END-EXEC. 01 WS-HOST-VARIBLE. 49 WS-HOST-VARBLE-LEN PIC S9 (4) COMP. 49 WS-HOST-VARBLE-TXT PIC X(80). PROCEDURE DIVISION. MOVE +45 TO WS-HOST-VARBLE-LEN. MOVE DELETE FROM EMPLOYEE WHERE DEPT=CONSUL TO WS-HOST-VARBLE-TXT. EXEC SQL EXECUTE IMMEDIATE :WS-HOST-VARBLE END-EXEC.

EXECUTE IMMEDIATE (Cont)

The Execute Immediate supports following statements ALTER, CREATE, DELETE, DROP, EXPLAIN, COMMIT, GRANT, INSERT, REVOKE and UPDATE. Disadvantages of EXECUTE IMMEDIATE It does not support the SELECT statement. It can result in poor performance, if the same SQL statement is performed, the executable form of the SQL is destroyed and the program has to prepare the executable form when it executed again.

NON-SELECT DYANMIC SQL

This statement is used to prepare and execute the SQL statements in an application program. This class of SQL statements uses PREPARE and EXECUTE to issue the SQL statements. As the name suggests this class also does not support the SELECT statements and cannot be used for querying tables. Non-SELECT SQL statements can use the feature of dynamic SQL known as the parameter marker (?), which is a placeholder for the host variables in the SQL.
WORKING-STORAGE SECTION. 01 TVAL PIC X(10) 01 WS-HOST-VAR. 49 WS-HOST-VAR-LEN PIC S9 (4) COMP. 49 WS-HOST-VAR-TXT PIC X(100). EXEC SQL INCLUDE SQLCA END-EXEC. PROCEDURE DIVISION. MOVE +45 TO WS-HOST-VARBLE-LEN. MOVE DELETE FROM S WHERE S#= ? TO WS-HOST-VAR-TXT. EXEC SQL PREPARE STMT1 FROM :WS-HOST-VARBLE END-EXEC. MOVE CONSUL TO TVAL. EXEC SQL EXECUTE STMT1 USING :TVAL END-EXEC.

FIXED-LIST SELECT
A FIXED-LIST SELECT statement can be used to explicitly prepare and execute SQL SELECT statements when the column to be selected are known and unchanging. This is necessary to create the WORKING-STROAGE declaration for the host variable in the program. Example WORKING-STORAGE SECTION. 01 WS-HOST-VAR. 49 WS-HOST-VAR-LEN PIC S9 (4) COMP. 49 WS-HOST-VAR-TXT PIC X(100). 01 TVAL1. 49 TVAL1-LEN PIC S9 (4) COMP. 49 TVAL1-TXT PIC X(3). 01 TVAL2 PIC X (10 ). PROCEDUER DIVISION. MOVE SELECT S#, SNAME, STATUS, CITY FROM S WHERE S# = ? AND CITY= ? TO FLSQL. Move the SQL to execute to WS-HOST-VARBLE. EXEC SQL DECLARE CRS1 CURSOR FOR FLSQL END-EXEC.

FIXED-LIST SELECT (Cont)

EXEC SQL PREPARE FLSQL FROM :WS-HOST-VAR END-EXEC. Move the required values to the variables TVAL1 and TVAL2. EXEC SQL OPEN CRS1 USING :TVAL1, :TVAL2 END-EXEC. Loop until no more rows to fetch EXEC SQL FETCH CRS1 INTO :S#,:SNAME, :STATUS, :CITY END-EXEC. EXEC SQL CLOSE CRS1 END-EXEC.

VARYING-LIST SELECT

Varying-list SELECT SQL statements are used when you do not know the columns that will be retrieved by an application program. This class of SQLs provide more flexibility than any other dynamic SQLs. You can change tables, columns and predicated during the execution, since every thing about this SQL can change during execution, the number and type of host variables cannot be known beforehand. This is why, this class of SQL is the most complicated among the dynamic SQLs.

SELECT STATEMENT WITH VARYING LIST

STMT
SQL statement

PREPARE PRST FROM : STMT

BIND Syntax Authorization Access strategy

DESCRIBE PRST
INTO : SQLDA

PRST

Description of selected columns

SQLDA

Setup of host variables to receive rows and put addresses into SQLDA

FETCH rows USING : SQLDA

SELECT STATEMENT WITH VARYING LIST (Cont...)

Since we dont know which columns will be accessed, we cannot pre-allocate any storage for host variables until we know that information. This will be the thing to do. If we have an idea how many columns we will have to access, it will already simplify our case. In Order to now the data types and names of the columns, we will have to ask DB2 to DESCRIBE the table we access. DB2 needs storage to be able to do this describe. If you know how many columns you will need, you can at least allocate enough storage for DB2 to be able to do the DESCRIBE. Once this is done, you can allocate storage for the host variables and execute the statements.

SQL DESCRIPTOR AREA (SQLDA) - FUNCTION

DESCRIBE INTO SQLDA Column Name, Data Type And Length For Each Column Selected

SQLDA

FETCH USING SQLDA

Addresses of host variables to receive results

Allocate matching host variables to receive a single row Notes:

Place addresses of host variables into SQLDA

This is the host structure used by DB2 describe an SQL statement (number of columns and data type of each column). This will be the input for the allocation of the host variable storage.

SQLDA - FORMAT

SQLDAID CHAR(8) SQLN SMALLINT SQLTYPE SMALLINT SQLDATA POINTER SQLNAME VARCHAR (30) OTHER SQLVARS

SQLD ABC INTEGER SQLD SMALLINT SQLLEN SMALLINT SQLIND POINTER

One Structure For Each Column Selected (SQLVAR)

Notes:
The SQLDA has a header containing some very useful information ( number of columns, etc), and then for each column a descriptive are called SALVAR.

SQLDA COLUMN DESCRIPTION

SQLTYPE 384 388 392 448 452 480 DATA TYPE DATE, NOT NULL TIME, NOT NULL TIMESTAMP, NOT NULL VARCHAR, NOT NULL CHAR, NOT NULL FLOAT, NOT NULL LENGTH Inst. Dep Inst. Dep 26 Length Length 8

480
484 496 500

REAL, NOT NULL

DECIMAL, NOT NULL INTEGER, NOT NULL SMALLINT, NOT NULL

4
2(prec/scale) 4 2

SQLTYPE + 1 = same as SQLTYPE, WITH nulls allowed

Notes: The SQLDA column description uses SQL TYPES to identify the different DB2 data types for columns. The Null attribute is also implicitly included.

SQLDA Technique 1
Allocate SQLDA1 for pre-defined number of columns (e.g. sqln = 50)

SQLDAID
SQLTYPE : :

SQLDABC
SQLTYPE

SQLN
SQLDATA

SQLD
SQLIND SQLNAME

SQLN

:

DESCRIBE statement INTO SQLDA1 If less than 50 columns returned Allocate host variable and indicator variable storage OPEN CURSOR and FETCH

#50

If more than 50 columns returned Read SQLD (# cols) Reallocate SQLDA2

Describe statement INTO SQLDA2

SQLDA Technique 1(Cont)

The problem is that you dont always know in advance how many columns will be returned, nor do you know how many SQLVARs you should allocate for the DESCRIBE. The first technique guesses that 50 will be about right. If it was optimistic and more than 50 columns are returned, two DESCRIBES will be necessary, a first one to find out how many rows will be returned (SQLD contains this info) and a second one in a freshly allocated, correctly sized SQLDA.

SQLDA Technique 2
Allocate minimal SQLDA1 (SQLN = 0)
SQLDAID SQLDABC SQLN SQLD

DESCRIBE statement INTO SQLDA1 Read SQLD (#of columns returned) Allocate large enough SQLDA2 (SQLN = SQLD) SQLDABC SQLTYPE SQLN SQLDATA SQLD SQLIND SQLNAME SQLN = SQLD

SQLDAID SQLTYPE : : :

 DESCRIBE statement INTO SQLDA2

Allocate host + Indicator variable storage OPEN CURSOR FETCH

Notes: This is the case where you have no idea at all about the number of returned columns or where you want to use the same processing logic whatever that number may be.

SQLDA USAGE SUMMARY

SQLDA

1.# of SQLVARs allocated SQLN

2. Description of each selected column

SQLNAME SQLTYPE SQLLEN

4. Addresses of host +indicator variables for each selected column

SQLDATA SQLIND

3. # of description SQLD If DB2 sets SQLD to zero : Statement is not a SELECT Issue an EXECUTE If DB2 sets SQLN to ZERO SQLDA is too small to use SQLD shows # of SQLVARs needed

COMMIT AND ROLLBACK

COMMIT and ROLL BACK are not really database operations at all, in the sense that SELECT, UPDATE are database operations. The COMMIT and ROLLBACK statements are not instructions to the database management system. Instead, they are instructions to the transaction manager and the transaction manager is certainly not a part of the DBMS On the contrary, the DBMS is subordinate to the transaction manager, in the sense that the DBMS is just one of possibly several resource managers that provide services to the actions running under that transaction manager. A transaction running under CICS can also use the services of three resources managersIMS/DB, CICS and DB2. Here CICS acts as the transaction manager. In the TSO and pure batch environments, where DB2 itself serves as the transaction manager, they are requested via the explicit SQL operators COMMIT and ROLLBACK Before getting details of COMMIT and ROLLBACK statements as such, we first need to know SYNCHRONIZATION POINT abbreviated as SYNCPOINT. A SYNCPOINT represents a boundary point between two consecutive transactions, loosely speaking, it corresponds to the end of a logical unit of work and thus to a point at which the database is in a state of consistency. Program initiation, COMMIT and ROLLBACK each establish a synchpoint and no other operation does.

COMMIT AND ROLLBACK (Cont...)

COMMIT : The SQL COMMIT statement takes the form COMMIT (WORK) A successful end-of-transaction is signaled and a synchpoint is established. All updates made by the program since the previous synchpoint are committed. All open cursors are closed, except for cursors whose declaration includes the optional specification WITH HOLD , all rowlocks are released, except for locks needed to hold position for cursors not closed. ROLLBACK The SQL ROLLBACK statement takes the form ROLLBACK [WORK] An unsuccessful end-of-transaction is signed and a synchpoint is established. All updates made by the program since the previous synchpoint are undone. All open cursors are closed.

UNIT 5: HANDLING NULLS & ERRORS

SQLCA LAYOUT
SQL CA layout SQLERRMLBINFIX(15) SQLERRMC CHAR (70) SQLERRP CHAR(8) SQLERRD(6) BIN FIX(31) REMARKS Length of error description Short error description Diagnostic info (Module name) Diagnostic into (Array) SQLERRD(3) : number of rows that were inserted, updated or deleted. If -> no warnings If w -> warnings are present Truncation of a string NULL values eliminated from argument of a function. Number of cloumns is larger than number of host variables. Delete or update stmt does not include a WHERE clause SQLCA EYE CATCHER Length of SQLCA (136) Return code

SQLWARNO CHAR(1) SQLWARN1 CHAR(1) SQLWARN2 CHAR(1)

SQLWARN3 CHAR(1)
SQLWARN4 CHAR(1) SQLAID CHAR(8) SQLCABC BIN FIX(31) SQLCODE BIN FIX(31)

SQLCA LAYOUT

Error handling is based on information, DB2 returns in the SQLCA (SQL Communication Area). The most important fields are the SQLSTATE and SQLCODE.

SQLSTATE
SQLSTATE is an SQL return code contained in a 5 digit character string. First digit : zero (successful) or not Zero First 2 digits : SQLSTATE CLASS

01
02 03

: unqualified successful execution

: warning : warning no data

last 3 digits represent SQLSTATE SUBCODE Example : SQLSTATE 00000 : successful SQLSTATE01501 : string truncation SQLSTATE 02000: no more data
Notes: SQLSTATE is a return code that is common to all DB2 family products. If you base your error handling on SQLSTATE, your interpretation of the error situation will be independent of the platform where the SQL statement was actually executed. It is recommended, therefore to use SQLSTATE instead of SQLCODE.

SQLCA CODES
SQLCODE is the SQL return code for DB2 (on MVS) and contains a signed numeric
value.

Negative values

Positive values

Error Condition

OK

Exception condition

Examples : -084 000 +100

Notes:

Unacceptable SQL statement Successful execution warning messages may have been issued. Row not found for FETCH, UPDATE or DELETE of the result of a query is an empty table.

SQLCODE is a return code that is specific to DB2 for MVS. Other platforms, like DB2/ VM also have SQLCODEs. However, the values dont always match.

SQLCA CODES USAGE

Status information is given by : SQLCODE, SQLSTATE and SQLWARNO SQLWARN1 SQLWARNA

CONDITION

INTEGER SQLCODE

Char(5) SQLSTATE = 00000 = 01ddd = 02000 01dddd 02000

Char(1) SQLWARNO

REQUEST STATUS

Error

<0 >0 & = 100 +100

Failed Satisfied, with special conditions (more) data not found

Warning

Or w

Not found

Success
Notes:

00000

And

Success

The chart gives you a general overview of which return codes will be generated in the indicated warning or error situation.

ERROR HANDLING
Example of testing return codes : EXEC SQL SELECT IF SQLSTATE = 00000 THEN IF SQLSTATE = 02000 THEN DISPLAY RECORD NOT FOUND ELSE IF SUBSTR (SQLSTATE,1, 2) = 01 THEN DISPLAY WARNSQL ELSE DISPLAY ERRORSQL ELSE : :

Example of using WHENEVER EXEC SQL WHENEVER NOT FOUND GOTO NO MORE EXEC SQL WHENEVER SQLERROR GOTO ERRORSQL EXEC SQL WHENEVER SQLWARNING GOTO WARNSQL : : : EXEC SQL SELECT.. :

ERROR HANDLING (Cont)

Various techniques can be used to detect error conditions. One thing is sure : you need error handling. The first technique is to react individually after every SQL statement. A more general error routine should be developed and called after each SQL statement. The second technique, WHENEVER, is not recommended for general use.

SCOPE OF WHENEVER

Pre Processor flow

Execution flow

Soruce code

EXEC SQL WHENEVER SQLERROR GOTO LAB1 : EXEC SQL SELECT IF SQLCODE < 0 THEN GOTO LAB : LAB1 : EXEC SQL WHENEVER SQLERROR GOTO LAB2 :

Notes: As you can see, the WHENEVER statement forces you to use GOTO and it is, therefore, sensitive to where the WHENEVER is placed in the code. Going back to where you came from is difficult. It is also difficult to take specific actions for specific SQL statements (an error for an update might need another reaction than the same error for a select). WHENEVER actually adds the checks to each of your statements at precompile.

ERROR MESSAGE FORMATTING ROUTINE

ERROR Message Formatting Routine : CALL DSNTIAR INTEGER Output Length of message line

And pass it three areas :

SMALLINT
SQLCA Error Information Size of message area

Error message Built by DSNTIAR

- FORTRAN uses routine DSNTIR

Notes: Attention should be paid not to invoke DSNTIAR unless an error condition is detected, because the module is dynamically loaded into storage when invoked. If you do this without care, you will waste a lot of resources.

ERROR HANDLING - GENERAL

WHENEVER will in general not be used

Different treatment needed for NOT FOUND after delete/ update/ insert. Coming back after WHENEVER Might want to intercept other return codes

SYSADM will normally provide a STANDARD error routine for everyone to use Only CALL DSNTIAR in error condition.

Notes: As mentioned previously, the use of WHENEVER is not recommended, and we advise using a general error routine that is called after each SQL statement

RETRIEVING NULL VALUES

:REF1:REF2 Indicator Variable (:REF2) should always be provided if selected column allows NULL 01 P-PHONE 01 P-PHONE-I PIC X(4) PIC S9(4) /*H-VARIABLE */ COMP /*I-VARIABLE*/

EXEC SQL SELECT PHONENO INTO :P-PHONE : P-PHONE-I FROM EMP WHERE EMPNO = :INP-EMP END-EXEC.
After the SELECT If PHONENO contains the NULL value : H-variable P-PHONE -> unchanged I- variable P-PHONE -> negative If PHONENO contains data : H-variable P-PHONE -> updated I- variable P-PHONE -> not negative

Notes : If a column can contain the NULL value, a special host variable called an Indicator Variable should be defined in the program. This variable is used by DB2 to signal the existence of a NULL value for that column.

INSERTING NULL VALUES

Definition of Host Variables :

01 PEMPL.
02 EMPNO PIC X(06). 02 FIRSTNME PIC X(12). 02 MIDINITPIC X(01). 02 LASTNAME PIC X(15). 02 WORKDEPT PIC X(03). 02 PHONENOPIC X(04).

Definition of Indicator Variable :

01 PEMPL. 10 INDSTRUC PIC S9(4) COMP OCCURS 6 TIMES

Set Indicator Variable :

IF no_phone_number_exists, THEN NPHONE = -1.

Imbedded SQL :
EXEC SQL UPDATE PEMPL SET PHONENO = : PHONENO : PHONENO WHERE EMPNO = :EMPNO END-EXEC.

Notes: On the other hand, the indicator variable will allow you to pass a NULL value to DB2.

SELECTING NULL VALUES

IF null_value_wanted, THEN NPHONE = -1. EXEC SQL SELECT LASTNAME, FIRSTNME FROM PEMPL WHERE PHONENO =:NPHONE END-EXEC.

If the indicator variable NPHONE is set to a negative value, the statement is treated as
EXEC SQL SELECT LASTNAME, FIRSTNME FROM PEMPL WHERE PHONENO IS NULL END-EXEC.

and the contents of the host variable PHONENO is ignored.

Notes: A negative value set in the indicator variable indicates a NULL value for the associated host variable.

HOST STRUCTURE INDICATOR VARIABLE

Definition of host variable (Structure) :
01 PEMPL. 02 EMPNO PIC X(06). 02 FIRSTNME PIC X(12). 02 MIDINITPIC X(01). 02 LASTNAME PIC X(15). 02 WORKDEPT PIC X(03). 02 PHONENOPIC X(04).

Definition of Indicator Variable (array) :

01 PEMPL. 10 INDSTRUC PIC S9(4) COMP OCCURS 6 TIMES.

Imbedded SQL :
EXEC SQL SELECT * INTO :PEMPL :INDSTRUC FROM PEMPL WHERE EMPNO = :EMPNO END-EXEC.

Test for NULL Values :

IF INDSTRUC(5) < 0 THEN WORKDEPT = ???? THEN IF INDSTRUC(6) < 0 THEN PHONENO = UNKN

HOST STRUCTURE INDICATOR VARIABLE (Cont...)

The example shows how a simple array can used to detect the NULL values for several columns. Remember that the DCLGEN function can generate the indicator variables for your DB2 table.

HANDLING ARITHMETIC ERRORS

Arithmetic error exceptions will be tolerated, if error occurs in the select list of the Outer SELECT and an indicator variable

Result of expression is NULL

Indicator variable is set to -2 SQLSTATE 01519 returned in the SQLCA ( SQLCODE +802)

Value in host variable left unchanged

Processing continues Expressions and values not in error will be returned. Otherwise statement execution will be halted and SQLSTATE 22013 OR 22003 (SQLCODE 802) WILL BE RETURNED

Notes: Indicator variables are also used by DB2 to signal arithmetic error conditions.

HANDLING CONVERSION ERROR

If a conversion error occurs in an embedded SELECT OR FETCH statement and an indicator variable has been provided for the expression. Result of expression is NULL Indicator variable is set to -2 SQLSTATE 01515 returned in the SQLCA (SQLCODE =-304)

Value in host variable left unchanged

Processing continues Expressions and values not in error will be returned Otherwise statement execution will be halted and SQLSTATE 22003 (SQLCODE 304) will be returned
Notes: Indicator Variable are also used by DB2 to signal conversion errors.

ARITHMETIC AND CONVERSION ERROR EXAMPLES

Example Background :

Declaration In program
01 01 01 MV1 MV2 MV3 PIC PIC PIC S9(4) COMP. S9(4) COMP. S9(4) COMP.

01
01 01 01 01 01

MV11
MV21 MV31 IV1 IV2 IV3

PIC
PIC PIC PIC PIC PIC

S9(4) COMP.
S9(4) COMP. S9(4) COMP. S9(4) COMP. S9(4) COMP. /* Indicator Variable */ /*Indicator Variable */

S9(4) COMP. /* Indicator Variable */

TABLE A values are SM1 1 2 3 4 INT1 123458 345678 123678 211111111 SMI2 1 0 1 4

Notes : Note the contents of the table and program definitions used for the coming examples

EXAMPLE OF ARITHMETIC ERRO

EXEC SQL SELECT SMI1,SMI1*INTI, SMI1/SMI2 INTO :MV1 : IV1, :MV2:IV2, :MV3:IV3 FROM TABLEA END-EXEC. Result for first row : MV1 = 1 MV2 = 123458 MV3 = 1 SQLSTATE = 00000 IV1 = 0 IV2 = 0 IV3 = 0

Result for Sec row :

MV1 = 2 MV2 = 691356 MV3 = 2/0 SQLSTATE = 01519

MV1 = 3 MV2 = 371034 MV3 = 3 SQLSTATE = 00000 MV1 = 4 MV2 = 844444444 MV3 = 1 SQLSTATE = 01519

IV1 = 0 IV2 = 0 IV3 = -2

Result for third row :

IV1 = 0 IV2 = 0 IV3 = 0

Result for forth row :

IV1 = 0 IV2 = -2 IV3 = 0

INDICATOR VARIABLE VALUES

0 +n Zero Denotes That Value In Data Variable Area Is Not NULL any positive number indicates truncation of a string value, where 'n is the length of the original string (string field only) any negative number indicates a NULL value in the data variable. Negative 2 Indicates a NULL value in the data variable because of either a numeric conversion error or an arithmetic expression error

-n -2

Notes: An error handling routine could take specific actions for these error conditions. Error handling will generally be done through a standard routine that will be invoked after each SQL statement. Your DB2 or SYSADM will provide you with the details about the specific implementation chosen for your installation

OTHER ERROR CONDITIONS

TABLE CHECK Constraint 22513 / - 545 statement not executed

VIEW CHECK option 23501 / - 161 statement not executed

DATE Invalid 22007 / -180 0r -181 statement not executed

Notes: A smart program could also handle those error condition. ABENDing the program is not always needed.

UNIT 6: STORED PROCEDURES

OVERVIEW UNDERSTAND THE CONCEPTS AND ADVANTAGES OF STORED PROCEDURES CODE A CLIENT PROGRAM CODE A STORED PROCEDURE SETUP THE SYSIBM.SYSPROCEDURES TABLE

STORED PROCEDURES: FLOW

DB2 PROCX EXEC SQL SELECT.FROM WHERE COL1 = : IN

Client Program EXEC SQL CALL Procx (In, Out);

EXEC SQL DELETE

EXEC SQL UPDATE

EXEC SQL INSERT

OUT = RESULT Proc end

Notes : A Stored procedure is a program that is controlled by DB2 that can be called through an SQL statement. The program can receive parameters and also has the ability to return data to the calling application.

STORED PROCEDURES: CONSIDERATIONS

RUN IN LE/370 ENVIRONMENT CODED IN ANY LANGUAGE(COBOL ,PL1, C) BEST TO CODE REENTRANT CAN NOT ISSUE CAF CALLS CALL OTHER STORED PROCS COMMIT/ROLLBACK

CONNECT

CAN USE NON-DB2 RESOURCE WITHOUT 2-PCS

MUST BE DEFINED IN THE CATALOG CLIENT CAN BE LOCAL OR REMOTE

STORED PROCEDURES: CONSIDERATIONS (Cont...

Both client and server applications can be written in any programming language. To make it a truly open concept, DB2 supports any type of client. The client can, in fact, be any application that can use either directly DB2 for MVS or that can pass calls to a DRDA application requester. The client and server are both shielded from any language differences by means of the LE/370 environment. All SQL executed within the stored procedure will be considered to be within the same logical unit of work as the client application. DB2 will, therefore, coordinate the potential changes with the UOW of the calling application. This feature restricts the use of SQL-statements such as COMMIT and ROLLBACK. Since stored procedures run using the CAF (Call Attachment Facility), you will not be able to issue any CAF calls. In the current implementation of DB2, there is only one address space that will run the procedures. It is, therefore, best to code the procedures as being reentrant, which will enable the parallel execution of the program. If it is not reentrant, only one user can use the procedure at a certain point in time. The stored procedure could also access non-DB2 data such as CICS transactions. That environment, however, is not going to be included in the same logical unit of work. There is no two-phase commit support with the other environments. Interfaces the stored procedure can use are: The MQI interface (Message Queuing) for asynchronous execution, or the EXCI (External CICS interface) for synchronous execution of CICS transactions.

STORED PROCEDURES: CALL SYNTAX

CALL ---procedure- name ----------------------------------------------------------------------------Host- variable ----------------------------------------------------------------------Host-variable Constant NULL USING DESCRIPTOR NAME

EXEC SQL CALL A (:EMP, :PRJ, :ACT) EXEC SQL CALL A (:EMP :INDEMP, : PRJ :INDPRJ, :ACT :INDACT) EXEC SQL CALL A (103455, BUIL5, :ACT)

EXEC SQL CALL A USING DESCRIPTOR :SQLDA

EXEC SQL CALL : PROCNAM USING DESCRIPTOR : SQLDA
Notes: A number of different ways exist. Bottom line is that you can use all options as host variables, both the name of the procedure and the parameters that are passed to it.

STORED PROCEDURES : LINKAGE CONVENTIONS

SIMPLE LINKAGE
Parameter 1, Parameter 2 , Parameter 3,

IN

IN OU T

OU T

Parameter 1 Null Indicator 1, Parameter 2 Null Indicator 2 , Parameter 3 Null Indicator 3, ..

SIMPLE WITH NULL LINKAGE Notes: Two linkage conventions can be used: SIMPLE : This type of linkage only allows the use of null for parameters that are defined as output parameters. For the output parameters you can add an indicator Variable. If that variable is set to a negative value, DB2 will not pass the whole variable to the procedure. This technique will help improve the speed of the call, as DB2 has less information to send.

STORED PROCEDURES : LINKAGE CONVENTIONS (Cont..)

SIMPLE WITH NULL : This type of linkage will require a null indicator for all parameters regardless of whether they are IN, OUT or INOUT.

For both types of linkages, you will have to define the nature of the parameter, which can be:

IN

(this parameter contains no value upon return from the procedure)

OUT (the content is not passed along to the procedure) INOUT (data flows in both directions)

STORED PROCEDURES : DB2 SETUP

PROCEDURE AUTHID LUNAME LOADMODULE COLLID LINKAGE LANGUAGE RUNOPTS PARMLIST ASUTIME STAYRESIDENT IBMREQ : : : : : : : : : : : : Name of the procedure Userid Luname this entry is intended for Name of the program used for this procedure Collection in which the package is stored SIMPLE or SIMPLE WITH NULLS Programming language used to code the program Any option you want to pass to the LE/370 environment. Complete description of the parameter list Maximum amount of CPU service units one run can consume Program stays in storage after it has completed Is this an IBM or a User entry.

IN

IN OU T

OU T

Parameter 1 Null Indicator 1, Parameter 2 Null Indicator 2, Parameter 3 Null Indicator,

STORED PROCDEURES: DB2 SETUP (Cont.)

To allow DB2 to know where and how the stored procedure is to be used, you will have to make an entry in a catalog table. This entry will give a description of who can use the procedure and what parameter conventions are used to call the procedure. You can specify different definitions for the same procedure based on the calling LU-name and use rid. The will allow you to test a new procedure while the old one is still used. The parm list has to contain a description of all the parameters that are included in the call and, of course, whether they are IN, OUT or INOUT. The ASUTIME column allows you to put a limit on the amount of resources that can be consumed by one invocation of a stored procedure.

UNIT 7: DB2 UTILITIES

OVERVIEW CATEGORIES OF DB2 UTILITIES LOAD UTILITY

CATEGORIES OF DB2 UTILITIES

DATA CONSISTENCY UTILITIES BACKUP AND RECOVERY UTILITIES. DATA ORGANIZATION UTILITIES. CATALOG MANIPULATION UTILITIES

DATA CONSISTENCY UTILITIES

The Consistency of data in a database is paramount important and so it must be controlled and monitored. The data consistency utilities are used to monitor, control and administer the data consistency errors. Three Data consistency utilities CHECK REPAIR REPORT

CHECK:
The CHECK utility checks the integrity of data structures. It has two purposes. The first is to check the referential integrity between two tables, displaying and potentially resolving referential constraint violation. The second purpose of the CHECK utility is to check DB2 indexes for consistency. This consists of comparing the key values of the indexed columns to their corresponding table values, as well as evaluating the RIDs in the tables and indexes being checked. The CHECK utility has two options CHECK DATA and CHECK INDEX.

DATA CONSISTENCY UTILITIES (Cont.)

REPAIR: The REPAIR utility is designed to modify DB2 data and associated data structures when there is an error or problem.

There are 3 distinct uses

The first is to test the DBD definitions in the DB2 directory and to synchronies the DB2 catalog database information with the DB2 directory and the DBD definition. The second is to physically change specific locations in a data set. The third and final type of REPAIR is to reset pending flags that are erroneously set. REPORT: Two types of reports can be generated with the REPORT UTILITY. The first is a table space set report showing the names of all tables spaces and table spaces and tables tied together by referential integrity. The second type of REPORT utility, the REPORT RECOVERY can be used to generate a report on table space recovery information.

BACKUP AND RECOVERY UTILITIES

The backup and recovery utilities supplied with DB2 are very complex. They remove the burden of database recovery from the DBA and place it with the DBMS. The main backup and recovery utilities are COPY MERGECOPY RECOVER COPY: The COPY utility is used to create an image copy, back up data set for a complex table space or a single partition of an all space. MERGECOPY: The MERGECOPY utility combines multiple incremental image copy data sets into a new full or incremental image copy data set. RECOVER: The RECOVER utility is used to restore DB2 table spaces and indexes to a specific point in time. You can run two forms of RECOVER utility. RECOVER TABLESPACE and RECOVER INDEX. The RECOVER TABLESPACE restores table spaces to a current or previous state, whereas the RECOVER INDEX utility can be used to re-create, indexes from current data.

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. There are 2 data organization utilities LOAD REORG LOAD: 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 the existing rows with new data. REORG: The REORG utility can be used recognizes DB2 table spaces and indexes thereby improving the efficiency of the access to those objects. Reorganization also re-clusters data, resets free space to amount specified in the CREATE DDL and delete and redefines the underlying VSAM data sets for STOGROUP defined object.

CATALOG MANIPULATION UTILITIES

The DB2 catalog and directory are essential for the proper functioning of the DB2 subsystem. It has RUNSTATS utility.

RUNSTATS: The RUNSTATS utility collects statistical information for DB2 tables, table spaces, partitions, indexes and columns. It can place this information into the DB2 Catalog Tables. The DB2 optimiser for determining the optimal access paths for the SQL queries reads the tables. The information can be queried using SQL statements.

DATA UTILITIES LOAD

LOAD Loads the records in INPUT SEQUENCE in one or more tables of the same table spaces.
Sequential Dataset

LOAD

Index

Table space
Notes: Besides the CHECK DATA UTILITY, we also have load utility. It provides a way to LOAD a selfreferencing table. Load will load the input records from the sequential file in input file record sequence.

LOADING DATA IN ONE TABLE

POSITION (36) CHAR (6) 01..234. E21 SOFTWAR SUPPORT031435 E01

TABLE DEPT

DEPTNO E21

DEPTNAME SOFTWARE SUPPORT

MGRNO 031435

ADMRDEPT E01

LOAD DATA INTO TABLE DEPT (DEPTNO (DEPTNAME (MGRNO (ADMRDEPT POSITION (7) POSITION (10) POSITION (36) POSITION (42) CHAR (3), CHAR (26), CHAR (6), CHAR (3))

TARGET COLUMN

INPUT FIELD LOCATION

INPUT FIELD TYPE AND LENGTH

DATA TYPE CONVERSION

Suppose that - MGRNO was defined as INTEGER in the DEPT table, and - The input dataset is identical to the one in the previous example.
Character Format

01..234.

E21 SOFTWAR SUPPORT031435 E01

Defined as INTEGER when CREATE TABLE was performed DEPTNO

TABLE DEPT LOAD DATA INTO TABLE DEPT (DEPTNO (DEPTNAME (MGRNO (ADMRDEPT POSITION (7) POSITION (10) POSITION (36) POSITION (42) CHAR (3), CHAR (26), INTEGER-EXTERNAL(6), CHAR (3))

DEPTNAME SOFTWARE SUPPORT

MGRNO 031435

ADMRDEPT E01

E21

Note: In some cases, the data types of the input record field and the target column dont match. In the example, the INTEGER EXTERNAL keyword tells DB2 that the record field contains numeric data formatted as characters. The LOAD utility will perform the necessary data conversion.

LOADING NULL VALUES

Setting columns to default values
01..234.

E21 SOFTWAR SALES

??????? E01

TABLE DEPT

DEPTNO E21

DEPTNAME SOFTWARE SALES

MGRNO ---------

ADMRDEPT E01

The MGRNO column allows NULL values so NULL values So NULL is its default. LOAD DATA INTO TABLE DEPT (DEPTNO POSITION (7:9) CHAR ,

(DEPTNAME
(MGRNO

POSITION (10:35) CHAR,

POSITION (36:41) CHAR DEFAULT (36:41) = ????????.

(ADMRDEPT POSITION(42:44)CHAR(3)) A recognizable string of question marks is used in this example to trigger the loading of NULL values in the column.

LOADING MULTIPLE TABLES IN A TABLESPACE

Loading different tables by testing an input field : LOAD DATA INTO TABLE DEPT WHEN (51) = D (DEPTNO POSITION(7) CHAR(3), DEPTNAME POSITION . ) INTO TABLE EMP WHEN (51) = E (EMPNO POSITION(1) CHAR(6), . .)
Note: Remember that a DB2 table space can contain several tables.The LOAD utility always works on a table space.You can LOAD several tables from one given input dataset by including a record field that distinguishes the data for the different tables.

THE RESUME AND REPLCE PARAMETERS

Initial load : - Empty table space - This is the default LOAD DATA RESUME NO INTO TABLE EMP Additional load : - Non empty tablespace To load another table in the samplespace - To add rows to a non-empty table. LOAD DATA RESUME YES INTO TABLE EMP Replace old data : - Reset a tablespace and related indexes To empty before loading LOAD DATA REPLACE
INTO TABLE EMP Easy way to refresh data This keyword tells DB2 if the tablespace(not the table) is supposed to be empty or not. If not empty, it tells DB2 what to do with the data contained in the tablespace : Keep it(RESUME YES), or discard ALL data in the tablespace(REPLACE).

UNIT 8: SECURITY AND EXPLAIN

DB2 SECURITY - STATIC SQL DB2 SECURITY - DYNAMIC SQL HOW TO INVOKE EXPLAIN. COMMIT AND ROLLBACK.

GRANT AND REVOKE

SECURITY definitions are made by issuing GRANT statements, such as GRANT SELECT ON TABLE EMP TO userid The opposite, withdrawing a GRANTed privileges, is done with the REVOKE Statement : REVOKE SELECT ON TABLE EMP FROM userid

DB2 SECURITY - STATIC SQL

CICS DB2

TERMINAL

. .
(first) SQL 5
THREAD

May EXECUTE PLAN A ?

. . .

PLAN A

PLAN A

SYSIBM. SYSPLANA

DIRECTORY CATALOG

DB2 SECURITY - STATIC SQL(Contd)

Lets take the example of a CICS transaction program containing SQL calls. At BIND PACKAGE time, security checks were done to make sure that the BINDer could create the package. When the program was put into production, the EXECUTE privilege on the plan was GRANTed to the users that need to execute it. What happens at execution time ? 1. User x enters a transaction code on his terminal(transid) leading to the execution of load module LMODA in CICS 2. The application invokes the first SQL statement. 3. At this first SQL statement, DB2 checks whether x has the EXECUTE privilege on PLANA. 4. If so, it will load the plan into storage and execute it. The plan will invoke the necessary packages. 5. The thread is created. From now on, no more security checks will be made. Subsequent SQL calls will be execute over the thread.

DB2 SECURITY - DYNAMIC SQL

TSO DB2

SELECT FROM EMP

. .
(first) SQL 7
THREAD 4

May EXECUTE SPUFIPLANA? May EXECUTE SQL

5

6,9

.
SQL.

SPUFIPLANA

PLANA

DYNAMIC RULES(RUN)

CATALOG DIRECTORY

DB2 SECURITY - DYNAMIC SQL(Contd..)

Let,s take the example of a SPUFI invocation. When a user invokes SPUFI to issue SQL statement dynamically, he will need the EXECUTE privilege on SPUFIs plan and the data access privileges on the data he wants to access : 1. User x logs on and invokes SPUFI. The SPUFI program is brought into storage and executed by issuing the following TSO command RUN PROGRAM (spufi) PLAN (spufiplan) 2. At first SQL, DB2 checks whether spufiplan may be executed by x by looking in the DB2 catalog. 3. If so, it will load spufiplan into storage and execute it. 4. The thread is created. From now on, dynamic SQL statements will be executed over the thread. The first PREPARE statement can be executed. 5. DB2 checks the data access privileges for x. 6. DB2 chooses the optional access path to the data. 7. At the next SQL statement, data access privileges are again checked. 8. The access path is created for that SQL statement, and so on

EXPLAIN INVOCATION
USER A USER A

EXPLAIN FOR SELECT

BIND EXPLAIN (YES)

Is INDEX IX1 being used

Does DB2 have to sort

Which table is accessed first to do the join

If you want to know what access path DB2 chose during a BIND or PREPARE operation, you must use the EXLPAIN function. You can do an EXPLAIN : - When you BIND a package or Plan(with DBRMs) by specifying EXPLAIN(YES) - Interactively ,by using the EXPLAIN SQL statement followed by the actual SQL statement of which you want the access path. The EXPLAIN output consists of a number of rows in a table called the PLAN_TABLE. Each user who does EXPLAIN needs his own PLAN_TABLE.

EXPLAIN INVOCATION AT BIND TIME

BIND PACKAGE/PLAN MEMBER(DBRM1) EXPLAIN (YES)

- Insert Access path information for application SQL into Userid.PLAN_TABLE - DB2 catalog remembers and will redo EXPLAIN at each new BIND / REBIND until BOUND WITH EXPLAIN(NO)

The owner of the PLAN_TABLE will be the BINDer of the program.

READING THE PLAN_TABLE

For PLANs with DBRMs

SELECT * FROM PLAN_TABLE WHERE APPLNA = PLAN1 AND PROGNAME =DBRM1 ORDER BY QUERYNO, QBLOCKNO,PLANNO, MIXOPSEQ

For PACKAGEs
SELECT * FROM PLAN_TABLE WHERE PROGNAME = PKG1 AND COLLID =COLL1 ORDER BY QUERYNO, QBLOCKNO,PLANNO, MIXOPSEQ

Those SQL statements will come in handy if you want access path information for all the statements of a package or plan. The ORDER BY clauses are essential to understand the access path.

SQL EXPLAIN INVOCATION

EXPLAIN ALL SET QUERYNO = qr FOR SELECT A1,A2 FROM S WHERE A5=345 - QUERYNO is set by the user or assigned by DB2 - The EXPLAIN statement can be : - executed in SPUFI or QMF - Imbedded in an application - The SQL statement cannot contain host variables - Not recommended for Imbedded SQL because Using constants instead of host variables may change the access Path The second way to do an EXPLAIN is interactively, as shown in the example. DB2 will, in this case, simulate a PREPARE to determine the access path. As you can understand from what we have seen for dynamic SQL, host variables will have to be replaced by ?. If you isolated an SQL statement from a program to EXPLAIN its access path interactively, you shouldnt replace a host variable by a constant because this would mean providing more information to DB2 than it would have at BIND time. A different access path could very well be in the result, and you might draw the wrong conclusions.

COMMIT AND ROLLBACK

COMMIT and ROLL BACK are not really database operations at all, in the sense that SELECT, UPDATE are database operations. The COMMIT and ROLLBACK statements are not instructions to the database management system. Instead, they are instructions to the transaction manager and the transaction manager is certainly not a part of the DBMS On the contrary, the DBMS is subordinate to the transaction manager, in the sense that the DBMS is just one of possibly several resource managers that provide services to the actions running under that transaction manager. A transaction running under CICS can also use the services of three resources managersIMS/DB, CICS and DB2. Here CICS acts as the transaction manager. In the TSO and pure batch environments, where DB2 itself serves as the transaction manager, they are requested via the explicit SQL operators COMMIT and ROLLBACK

Before getting details of COMMIT and ROLLBACK statements as such, we first need to know SYNCHRONIZATION POINT abbreviated as SYNCPOINT. A SYNCPOINT represents a boundary point between two consecutive transactions, loosely speaking, it corresponds to the end of a logical unit of work and thus to a point at which the database is in a state of consistency. Program initiation, COMMIT and ROLLBACK each establish a synchpoint and no other operation does.

COMMIT AND ROLLBACK (Cont...)

COMMIT : The SQL COMMIT statement takes the form COMMIT (WORK) A successful end-of-transaction is signaled and a synchpoint is established. All updates made by the program since the previous synchpoint are committed. All open cursors are closed, except for cursors whose declaration includes the optional specification WITH HOLD , all rowlocks are released, except for locks needed to hold position for cursors not closed.

ROLLBACK: The SQL ROLLBACK statement takes the form ROLLBACK [WORK] An unsuccessful end-of-transaction is signed and a synchpoint is established. All updates made by the program since the previous synchpoint are undone. All open cursors are closed.

SAMPLE PROGRAM
IDENTIFICATION DIVISION. PROGRAM-ID. SAMPLE. ENVIRONMENT DIVISION. CONFIGURATION DIVISION. INPUT-OUTPUTSECTION. FILE-CONTROL. SELECT OUT-FILE ASSIGN TO DD1 DATA DIVISION. FILE SECTION. FD OUT-FILE. 01 OUTREC PIC X(80). WORKING-STORAGE SECTION. 01 R0. 03 FILLER PIC X (29) VALUE NAME. 03 FILLER PICX (05) VALUE PHONE 01 R1. 03 R1- FIRSTNME PIC X (12). 03 FILLER PIC X (01) VALUE . 03 R1-LASTNAME PIC X(15). 03 FILLER PIC X(01) VALUE . 03 R1-PHONENO PIC X(04). 01 PROMPT1 PIC X(80).

VALUE ENTER EMPNO OR 999999 TO STOP .. 01 ERR-NF VALUE ***** THIS EMPNO DOES NOT EXIST***** 01 ERR-UN-1 VALUE *****UNEXPECTED ERROORS*********** 01 ERR-UN-2 03 FILLER PIC X(13) VALUE ******SQLSTATE=. 03 EU2-SQLSTATE PIC 99999. 03 FILLER PIC X(08) VALUE **** 01 ERR-UN-3 PIC X(80) VALUE *************PROGRAM ENDS********. * ------------------------------------------------------------------------------------------------*COMPLETE THE DECLARATION FOR : * TABLE EMP * THE SQL COMMUNICATION AREA (SQLCA) *-------------------------------------------------------------------------------------------------EXEC SQL INCLUDE EMP END- EXEC. EXEC SQL INCLUDE SQLCA END-EXEC.

PROCEDURE DIVISION. MAIN-PARA. PERFORM INIT PERFORM DISP-EMP UNTIL EMPNO = 999999 PERFORM END-PARA. INIT-PARA. OPEN OUTPUT OUTFILE PERFORM GET-EMPNO. DISP-EMP SECTION. * ------------------------------------------------------------------------------------------------WRITE YOUR SELECT STATEMENT HERE * ------------------------------------------------------------------------------------------------EXEC SQL SELECT FIRSTNSME, LASTNAME, PHONENO INTO :FIRSTNME, :LASTNAME, :PHONENO FROM EMP WHERE EMPNO = : EMPNO END-EXEC. * ------------------------------------------------------------------------------------------------* THIS STATEMENT IS NEEDED TO INTERCEPT ERROR * CONDITIONS. YOU WILL LEARN ABOUT IT LATER IN THE COURSE * -------------------------------------------------------------------------------------------------

EVALUVATE SQLSTATE WHEN 00000 CONTINUE WHEN 02000 GO TO NOTFOUND-PARA WHEN OTHER GOTO ERROR-PARA END-EVALUVATE. MOVE FIRSTNME-TXT (1: FIRSTNME-LEN) TO R1-FIRSTNME MOVE FIRSTNME-TXT (1: FIRSTNME-LEN) TO R1-LASTTNME MOVE PHONENO TO R1 PHONENO WRITE OUTREC FROM R0 WRITE OUTREC FROM R1 GO TO EXIT.-PARA NOTFOUND-PARA. WRITE OUTREC FROM ERR-NF GO TO EXIT-PARA ERROR-PARA. MOVE SQLSTATE TO EU2-SQLSTATE WRITE OUTREC FROM ERR-UN-1 WRITE OUT-REC FROM ERR-UN-2 WRITE OUT- REC FROM ERR-UN-3 PERFORM END-PARA.

EXIT-PARA. PERFORM GET-EMPNO. GET-EMPNO-PARA. MOVE SPACE TO OUTREC. WRITE OUTREC. WRITE OUTREC FROM PROMPT1 ACCEPT EMPNO. END-PARA. CLOSE OUTFILE GOBACK.