1. DB2

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

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

4. 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

5. 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”

6. 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.

7. 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

8. 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.

9. 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

10. 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

11. Program Preparation and Execution
Demonstration
Program Preparation and Execution

12. Type the program in a member of a PDS.

15. Save and use the clist TRNGDB2 to compile the program

17. Precompilation stage return code = 4 is never accepted here.

19. DBRM that is created can be seen.

27. 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.

32. Execution in
Foreground Mode

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

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

36. Execution in
EDITJCL Mode

38. 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.

44. The output can be seen the sysout.

45. Execution in
BACKGROUND Mode

46. 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.

64. 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.

65. 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

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

67. Thank You!