DB2

Session Plan Precompilation DBRM Binding Application Plan and Package Program preparation summary Demonstration of batch application in different modes Working with CICS

Steps Involved in Program Preparation Pre-compilation Binding Compilation Linking Execution

Precompilation Involves the following sequence of events. Syntax checking of SQL statements embedded in the host language. Checking for datatype matches. Commenting out the SQL statements and replacing it with equivalent COBOL CALL statements. Creation of DBRM (Data base Request Module). Db2 programs must be parsed and modified before normal compilation. The Db2 precompiler performs this task. It performs the following sequence of events Searches for and expands Db2 related INCLUDE members. Db2 need not be connected while precompilation is done because it only expands the include members. Searches for all SQL statements which are embedded in the application program with in the block EXEC SQL and END EXEC Extracts all the SQL statements from the program and places them in a database request module (DBRM) Checks the syntax of the SQL statements. It checks the data type compatibility of the columns and the host variables It checks the syntax of the SQL statement It does not check the existence of the table It does not check the existence of the columns in the specific tables. Comments out the SQL statements in the program and replaces them with equivalent CALL statements of COBOL. This modified program is the input to the compiler for example a sample snap shot of the program A002-SELECT-PARA. ***** EXEC SQL ***** SELECT STNO,STNAME INTO :WS-STNO, ***** :WS-STNAME FROM STUD27 WHERE ***** STNO = :WS-STNO ***** END-EXEC PERFORM SQL-INITIAL UNTIL SQL-INIT-DONE CALL 'DSNHLI' USING SQL-PLIST2

DBRM (Data base Request Module) A DBRM is a module containing SQL statements. A DBRM is stored as a member of a PDS. The DBRM is stored in a member called “OPERN.CICS3.DBRMLIB”

Binding Converts all the SQL statements to executables Bind reads SQL statements from DBRM’s and produces a strategy to access data directed by the SQL statements. Does the following Checks the syntax SQL statements Verification of authority on DB2 objects Optimization of SQL statements to create the application plan Bind does the following tasks Validates the SQL statements using the DB2 catalog. During the bind process, DB2 checks your SQL statements for valid table, view, and column names. Because the bind process occurs as a separate step before program execution, errors are detected and can be corrected before the program is executed. 2) Verifies that the process binding the program is authorized to perform the data accessing operations requested by your program's SQL statements. When you issue BIND, you can specify an authorization ID as the owner of the plan or package. The owner can be any one of the authorization IDs of the process that is performing the bind. The bind process determines whether the owner of the plan or package is authorized to access the data the program requests. 3) Selects the access paths that are needed to access the DB2 data your program needs to process. There can be multiple access paths. Best access path is selected with less cost. Static SQL SQL statements to be executed are predefined. The columns to be retrieved are fixed and the predicates don’t change. 2) Path of the data is prefixed in the form of SQL statements. Dynamic SQL 1) SQL statements are supplied at run time. 2) Depending on user’s need the SQL statement can change. A program that provides dynamic SQL accepts SQL as input, or generates an SQL statement in the form of character string. In most general cases where the SQL statement is not known the program takes the following steps Translates the input data, including any parameter markers, into SQL statement. Prepares the SQL statement to execute and acquires a description of the result table. Obtains, for select statement, enough main storage to contain the retrieved data. Executes the statement or fetches the rows of data. Processes the information returned. Handles SQL return codes. When static SQL statements are used the access path is determined when the plan or package is created during Bind step itself. For dynamic SQL statements, DB2 determines the access path at run time, when the statement is prepared. This can make the performance worse than that of static SQL statements. However, when the same SQL statement is executed often, then it is possible to use the dynamic statement cache to decrease the number of times that those dynamic statements must be prepared.

Application Plan Is the executable form of one or more of one or more DBRMs and application package Should be generated every time a DBRM is modified. Application plans are kept in the buffer pool during program execution 1) A plan is an executable module containing the access path logic produced by the Db2 optimizer. 2) It can be composed of one or more DBRMs and packages. 3) The plans are available in the Catalog table SYSIBM.SYSPLAN

Application Package Is the executable form of a single DBRM. Is bound to an application plan with related packages. If any DBRM is altered, then only the corresponding package needs re-binding. A package is an executable form of a single DBRM. Advantages of using Package Consider the following scenario. An application has 5 programs in it (for example a banking application which has five programs like open, close, deposit, withdraw and enquiry). Plan has to be created to execute the application. All the 5 DBRM’s are bound together to obtain the plan. Now if there is a change in a single SQL statement in a program. Following steps have to be done Change the SQL statement and compile the program once again. Since the SQL statements are changed the DBRM is changed now. Perform the Bind step once again and create the plan. The Plan creation should have all the 5 DBRM’s. The process of creating Plan is a resource consuming work. Even if there is a change in a single DBRM, the entire application Plan has to be created once again. This will consume resources unnecessarily. Using Packages is an alternate solution for this problem. Have an executable form of individual DBRM’s which are nothing but packages. While the plan is created all the packages are bound together. Now if there is a change in a single DBRM then the corresponding package alone will be rebound not the entire plan.

Relationship between DBRM, Package and Plan In this example if DBRM4 is changed then the entire plan has to be rebound. If DBRM1 or DBRM2 or DBRM3 are changed then only the package has to be created not the entire plan. DBRM1 DBRM2 DBRM3

Program Preparation Summary Source Program Hostvariables copybook DCLGEN Precompile DBRM Catalog Tables Modified Source program Plans & packages Info DB Objects Info BIND Packages Plans Bufferpool Load Module Compile & Link Execution

Program Preparation and Execution Demonstration Program Preparation and Execution

Type the program in a member of a PDS.

Save and use the clist TRNGDB2 to compile the program

Precompilation stage return code = 4 is never accepted here.

DBRM that is created can be seen.

Enter the DBRM name and the library where it is available(OPERN. CICS3 Enter the DBRM name and the library where it is available(OPERN.CICS3.DBRMLIB). Enter the plan name. For a batch application the plan name can be anything. But for a CICS- DB2 application plan names would be communicated in excel sheet.

Execution in Foreground Mode

To execute a Db2 application Plan name is needed program name is needed Choose the option to run the application

Fore Ground mode will accept the details from the user and execute the application.

Execution in EDITJCL Mode

Enter the SYSIN parameter and submit the JCL. This JCL executes a program called IKJEFT01. About IKJEFT01 When a program is run under TSO it ties up with terminal when it is executing in fore ground mode. A batch job runs in its own address space using general system resources, but keeps the terminal free to do other work. Under certain circumstances to get the best of both worlds by running TSO as a batch job using a process called TSO-in Batch. TSO-in- Batch is very suitable for running long executing TSO commands that do not require user interaction. TSO – In Batch program is run by setting up a pseudo- TSO environment in a batch region using a JCL. The EXEC card executes the program called “IKJEFT01” which is the TSO control program. Additionally TSO commands to be run can be specified in the PARM field of the EXEC card along with the PGM = IEJEFT01. In short IKEFT01 is a TSO Terminal Monitor Program, used to execute TSO command in a batch job. IKJEFT01 is used to connect Db2 and TSO. To execute the COBOL – DB2 batch applications this PGM is used in the JCL.

The output can be seen the sysout.

Execution in BACKGROUND Mode

In Back ground mode a JCL is submitted which cannot be edited In Back ground mode a JCL is submitted which cannot be edited. So the program cannot accept data. Program should have hard coded the values.

Working with CICS In CICS, every DBRM associated with a transaction must be put under one Plan. The RCT (Resource Control Table) in CICS maintains TRANSID to PLAN NAME relationship. The Plan name for the transaction BXXY is PLNBLXXY. For executing a CICS application a transaction identifier is given. For executing a DB2 application we have to supply the program name and plan name. For executing an application which involves both CICS and DB2 we need to have a link between transaction and plan as there is already a link between program and transaction. To create a link between transaction and plan we create RCT entry.

What to do when a new Program in added? Create PCT, PPT and RCT entries (For CICS applications) Pre-compile Translate Compile Bind Install new copies of all the programs

Summary Precompilation DBRM Binding Application Plan and Package Program preparation summary Demonstration of batch application in different modes Working with CICS

Thank You!