1. Pre-compilation

DB2 programs must be parsed and modified before normal compilation. DB2 pre-compiler performs this task.

Searches for and expands DB2-related Include members Searches for SQL statements, extracts those and places them in a DBRM. Creates a modified version of source program in which Each SQL statement

in the program is commented out and a call to DB2 runtime interface module along with applicable parameters, replaces each original SQL statements.

Places a Timestamp token in the modified source and the DBRM to ensure that these two items are tied.

Note: DB2 does not need to be operational to pre-compile a DB2 program, The available procedures Ex., DSNHICOB for COBOL/370,DSNHCOB2 for VS COBOL II are present in SYS1.PROCLIB.

1.a Pre-compiling options

APOST/QUOTE – String delimiter within host language statements.

APOSTSQL/QUOTESQL – String delimiter & escape character within SQL statements.

ATTACH(TSO/CAF) - Attachment facility that the application uses to access DB2. TSO/CAF.

COMMA/PERIOD- Represents the decimal point indicator in decimal and floating point literal.

FLAG(I/W/E/S) – Suppress diagnostic messages below these specified severity level.

HOST(COBOL|COB2) – COB2 for VS COBOL II , COBOL for OS/VS, COBOL,IBMCOB for COBOL 370 only.

CONNECT(2|1)- Whether to apply connect 2 or 1 rules.

DEC(15|35) – Specifies maximum precision for decimal artihmetic operations.

LINECOUNT,MARGINS (m,n) -- default values depend on MAR

NOFOR –Eliminates the need for the FOR UPDATE and FOR UPDATE OF clause.

NOOPTN,NOS,NOX – Suppresses the corresponding listings.

SQL(DB2/ALL) – All DRDA rules.

STDSQL(YES/NO)- YES indicates the precompiled SQL statements in the source program to conform to certain rules of SQL ( NO indicates rules of DB2), declaring SQLSTATE/SQLCODE as host variables if STDSQL(YES) If you do not specify the FOR UPDATE clause in a DECLARE CURSOR

statement, and you do not specify the STDSQL(YES) option or the NOFORpre compiler options, you receive an error if you execute a positioned UPDATE statement.

ONEPASS|TWOPASS – Processes in two passes, so that declarations need not precede references.

VERSION(AAAA/AUTO) – Version identifier of a package, program and the resulting DBRM.

AUTO – makes the Consistency token as the version identifier. Timestamp in the ISO character format If you do not specify a version at pre compile time, then an empty string is the default version identifier. If you specify AUTO, the SQL statement processor uses the consistency token to generate the version identifier. If the consistency token is a timestamp, the timestamp is converted into ISO character format and used as the version identifier. The timestamp used is based on the System/370 Store Clock value.

LEVEL- Level is specified as character string to be used by DB2 for consistency Change the Source code (but not the SQL statements) in the DB2 pre

compiler output of a bound program. Compile and link-edit the changed program. Run the application without rebinding a plan or package.

1.b LINK-EDIT the program

The purpose of the link edit step is to produce an executable load module. To enable your application to interface with the DB2 subsystem, you must use a link-edit procedure that builds a load module that satisfies these requirements.

TSO and batch Include DB2 TSO attachment facility language interface module (DSNELI) or DB2 call attachment facility language interface module (DSNALI).

Note: DB2 does not need to be operational when the program is being link-edited.

2. DBRM (Database Request Module)

That data set contains the SQL statements and host variable information extracted from the source program, along with information that identifies the program and ties the DBRM to the translated source statements. It becomes the input to the bind process.

Stored as a member of a Partitioned Data set. SYSIBM.SYSDBRM does not contain DBRM created by the pre compiler.

This catalog table will be updated when the DBRM is bound and it consists of information about DBRMs that have been bound into application plans and packages.

All SQL statements in DBRM are placed into the SYSIBM.SYSSTMT DB2 catalog table when it is bound to PLAN

SYSIBM.SYSPACKSTMT will contain the SQL statements when DBRMs are bound to PACKAGE.

3. PLAN

It is an executable module containing access path logic produced by the DB2 optimizer.

Composed of one or more DBRMs and packages. All DB2 programs require an application plan to allocate DB2 resources and

support SQL requests made at run time.

4. BIND process

The BIND process is a type of compiling of SQL statements. There are two types of BINDS: BIND PLAN and BIND PACKAGE. Reads the SQL statements in the DBRM and checks the syntax of those

statements. Checks that the DB2 tables and columns being accessed conform to the

corresponding DB2 catalog information. Performs optional authorization validation and optimizes the SQL statements

into efficient access paths. Output of the Bind process is a control structure that DB2 will use to execute

the SQL statements when the application program is run. The control structure will either be part of a plan or contained within a

package that will be executed via a plan. Note: DB2 subsystem must be operational when the program is being bound .

5. BIND PLAN

Accepts as input one or more DBRMs produced from DB2 program pre compilations, one or more packages produced from previous BIND PACKAGE commands

Information about the plan is then stored in the following DB2 catalog tablesSYSDBRM,SYSPACKAUTH,SYSPACKLIST,SYSPLAN,SYSPLANAUTH,SYSPLANDEP, SYSSTMT,SYSTABAUTH.

DB2 catalog stores only information about the plans. The executable form of the plan called a Skeleton cursor table (SKCT) is stored in the DB2 directory.

5.1 Authorization

Bind option Authorization required to run BIND PLAN

ADD using Primary authorization ID

BINDADD PrivilegeSYSADM or SYSCTRL Authority

ADD specifying an OWNER other than the primary authorization id

If the binder does not have SYSADM or SYSCTRL authority. Authorization id of the owner is evaluated for the privilege or authority

BINDADD PrivilegeSYSADM or SYSCTRL Authority

REPLACE, using the Default owner or Primary authorization ID

Ownership of the planBIND privilege on the plan SYSADM or SYSCTRL Authority

REPLACE, specifying an OWNER other than the primary authorization id

If the binder does not have SYSADM or SYSCTRL authority. Authorization id of the owner is evaluated for the privilege or authority

Ownership of the planBIND privilege on the plan SYSADM or SYSCTRL Authority

6. 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 package or program level. To execute a package, include it in the package list of plan. They are indirectly executed when the plan in which they are contained

executes.

6.1 Authorization

The package owner must have authorization to execute all statements embedded in the package for BIND PACKAGE to build a package without producing error messages. (The SYSADM authority includes this authorization.) For VALIDATE (BIND), DB2 verifies the authorization at bind time. For VALIDATE (RUN), DB2 verifies the authorization initially at bind time, but if the authorization check fails, DB2 rechecks it at run time.

The authorization required to add a new package or a new version of an existing package depends on the value of field BIND NEW PACKAGE on installation panel DSNTIPP. The default value is BINDADD.

Privileges needed for Bind package options

Bind option Bind New package Authorization required to run BIND PACKAGE

ADD using Primary authorization ID

BINDADD BINDADD and (CREATE IN or PACKADM authority)

BIND BINDADD and (CREATE IN or PACKADM authority).

BIND package privilege (can only add a new version of an existing package).

ADD specifying an OWNER other than the primary authorization id

If the binder does not have SYSADM or SYSCTRL authority. Authorization id of the owner is evaluated for

BINDADD BINDADD and (CREATE IN or PACKADM authority)

the privilege or authorityBIND BINDADD and (CREATE

IN or PACKADM authority).

BIND package privilege (can only add a new version of an existing package).

REPLACE, using the Default owner or Primary authorization ID

BIND or BINDADD Ownership of the packageBIND privilege or PACKADM authority

REPLACE, specifying an OWNER other than the primary authorization id

If the binder does not have SYSADM or SYSCTRL authority. Authorization id of the owner is evaluated for the privilege or authority

BIND or BINDADD Ownership of the packageBIND privilege or PACKADM authority

6.2 Identifying packages at run time

The DB2 pre compiler or SQL statement coprocessor identifies each call to DB2 with a consistency token. The same token identifies the DBRM that the SQL statement processor produces and the plan or package to which you bound the DBRM. When you run the program, DB2 uses the consistency token in matching the call to DB2 to the correct DBRM.

But you need other identifiers also. The consistency token alone uniquely identifies a DBRM bound directly to a plan, but it does not necessarily identify a unique package. When you bind DBRMs directly to a particular plan, you bind each one only once. But you can bind the same DBRM to many packages, at different locations and in different collections, and then you can include all those packages in the package list of the same plan. All those packages will have the same consistency token. As you might expect, there are ways to specify a particular location or a particular collection at run time.

6.3 BIND(PLAN/PACKAGE) OPTIONS

ISOLATION(CS/RS/RR/UR)-

RR/RS – Application cannot read a row that the other application has changed until it releases.RR – This will retain page locks for the records that are read.CS – This will release read locks when a row on another page is read.

RS – This will allow other process to insert a row, change a row that did not originally satisfy the search condition of other application.

CS – Unlike RR,CS does not prevent other application from changing rows that your application reads.

UR – Only with read only operation (SELECT,SELECT INTO,FETCH)

CURRENT DATA(Y/N)-

EXPLAIN(YES/NO) – Inserts information in the tables populated by EXPLAIN.If Owner.PLAN_TABLE does not exist. The value of the option for VALIDATE determines the result.

ACTION(REPLACE/ADD) – when a plan is replaced all execute privileges are revoked unless RETAIN is coded.

VALIDATE(RUN/BIND) – (RUN) Checking is done at the time plan is executed.(BIND) Checking is done at the Bind time.

ACQUIRE (USE/ALLOCATE) – (USE) Provide greater concurrency and hold on to resources for a short period of time, acquiring each resource when it is first referenced This is the default for all dynamic SQL and BIND packages (ALLOCATE) Get all the resources at the beginning of the thread.

RELEASE – (COMMIT/DEALLOCATE) – (COMMIT) Greateer concurrency all resources are released at a commit point.(DEALLOCATE) Hold on to resources until the end of the thread

Thread reuse for a CICS transaction. Repeated releasing and acquiring of resources may be expensive.

SQLERROR(NOPACKAGE/CONTINUE) –(NOPACKAGE) Creates no package if an error occurs. (CONTINUE)Creates a package , even if error occur when binding SQL statements. The Statements in error cannot execute.

KEEP DYNAMIC(YES/NO) – If you specify KEEPDYNAMIC(YES), the application does not need to prepare an SQL statement after every commit point. DB2 keeps the dynamic SQL statement until one of the following occurs:

The application process ends

A rollback operation occurs

BIND vs REBIND

Change made Minimum action necessary:

Revoke an authorization to use an object

None required; automatic rebind is attempted at the next run. Automatic rebind fails if authorization is still not available; then you must issue REBIND for thepackage or plan.

Run RUNSTATS to update catalog statistics

Issue REBIND for the package or plan to possibly change the access path chosen.

Add an index to a table Issue REBIND for the package or plan to use theindex.

Change statements in host language and SQL statements

Precompile, compile, and link the application program. Issue BIND with ACTION(REPLACE) for the package or plan.

7. COLLECTION

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. Specifying a different collection identifier for a package, the Same DBRM can

be bound into different packages.

Using unqualified SQL and bind the package different collection identifier and qualifier and using

SET CURRENT PACKAGESET = :HOST VAR

7.A PACKAGE ADMINISTRATION ISSUES.

Systematic Rebinding: Rebinding a plan in a single job step in BIND PLAN environment. Access path is different at package level hence each package need to be rebound. This results in creation of job steps.

Package version maintenance:SELECT ‘FREE PACKAGE(‘ || COLLID || ‘ . ‘ || NAME || ‘.(‘ || VERSION || ‘))’ FROM SYSIBM.SYSPACKAGE AWHERE TIMESTAMP < (SELECT MAX(TIMESTAMP) FROM SYSIBM.SYSPACKAGE B WHERE A.COLLID = B.COLLID AND A.NAME = B.NAME)

7.B PACKAGE PERFORMANCE.

DB2 can retrieve the package quite easily because indexes exist on the DB2 catalog tables that contain package information.

Make each plan package list as short as possible. Place the most frequently used packages first in the package list. Consider specifying collection.*

8. Versions

Before the availability of packages, to run a older version of program, older version of DBRM need to be rebound to the plan. If the DBRM was unavailable, they had to repeat the entire program preparation process.

Other than the specification of the version at pre compilation time, versioning is automatic and requires no programmer intervention

All versions of the package are bound into the plan when a package is bound into a plan. To use a previous version of the program ,simply restore and run the load module.

9. GRANT command

9.A The GRANT statement grants privileges to authorization ids.

GRANT <Privilege set> TO <AUTHID/PUBLIC> WITH GRANT OPTION

The value of CURRENT RULES determines whether you can use the ID ofthe GRANT statement itself (to grant privileges to yourself). When

CURRENT RULES is:DB2You cannot use the ID of the GRANT statement.STDYou can use the ID of the GRANT statement.

WITH GRANT OPTION – Allows the named users to grant the privileges to others. Grant authority cannot be passed to PUBLIC.

There is a separate form of the statement for each of these classes of privilege:

9.B Collection:

GRANT <CREATE IN/PACKADM ON> COLLECTION<collid> TO <auth id/PUBLIC> WITH GRANT OPTION

9.C Package:

GRANT<BIND/COPY/EXECUTE/ALL> ON PACKAGE(collid.*/collid.packagename) TO<auth id/PUBLIC> WITH GRANT OPTION

BINDGrants the privilege to use the BIND and REBIND subcommands for thedesignated packages. The BIND package privilege is used to add a new version of an existingpackage.

COPYGrants the privilege to use the COPY option of the BIND subcommand for thedesignated packages.

EXECUTEGrants the privilege to run application programs that use the designatedpackages and to specify the packages following PKLIST for the BIND PLANand REBIND PLAN commands. RUN is an alternate name for the sameprivilege.

ALLGrants all package privileges for which you have GRANT authority for thepackages named in the ON clause.

Example 1: Grant the privilege to copy all packages in collection DSN8CC61 toLEWIS.GRANT COPY ON P CK GE DSN8CC6 .* TO LEWIS;

Example 2: You have the BIND privilege with GRANT authority over the packageCLCT1.PKG1. You have the EXECUTE privilege with GRANT authority over thepackage CLCT2.PKG2. You have no other privileges with GRANT authority overany package in the collections CLCT1 AND CLCT2. Hence, the following statement, when executed by you, grants LEWIS the BIND privilege on CLCT1.PKG1 and theEXECUTE privilege on CLCT2.PKG2, and makes no other grant. The privilegesgranted include no GRANT authority.

GRANT ALL ON PACKAGE CLCT .PKG1, CLCT2.PKG2 TO JONES;

9.d Plan:

GRANT <BIND/EXECUTE> ON PLAN<planname> to <authid/PUBLIC> WITH GRANT OPTION

BINDGrants the privilege to use the BIND, REBIND,FREE subcommands for theIdentified plans. (The authority to create new plans using BIND ADD is asystem privilege.)

EXECUTEGrants the privilege to run application programs that use the identified plans.

Example 1: Grant the privilege to bind plan DSN8IP71 to user JONES.GRANT BIND ON PLAN DSN8IP7 TO JONES;

Example 2: Grant privileges to bind and execute plan DSN8CP71 to all users at the current server.GRANT BIND,EXECUTE ON PLAN DSN8CP7 TO PUBLIC;

Example 3: Grant the privilege to execute plan DSN8CP71 to users ADAMSON and BROWN with grant option.GRANT EXECUTE ON PLAN DSN8CP7 TO ADAMSON,BROWN WITH GRANT OPTION;