Preparation process for an application program

How you prepare an application program to run depends on the type of application. The program preparation steps for applications vary based on the type of programming language that is used. DB2 applications require different methods of program preparation, depending on the type of the application. Applications that contain embedded static or dynamic SQL statements DB2 applications embed SQL statements in traditional language programs. To use these programs, you must follow the typical preparation steps (compile, link edit, and run) as well as the DB2 precompile and bind steps. Applications in interpreted languages, such as REXX and APL2 REXX procedures use dynamic SQL. You do not precompile, compile, link-edit, or bind DB2 REXX procedures before you run them. Applications that contain ODBC calls These applications pass dynamic SQL statements as arguments. You do not precompile or bind ODBC applications. ODBC applications use a standard set of functions to execute SQL statements and related services at run time. Java applications, which can contain JDBC calls or embedded SQL statements Preparing a Java program that contains only JDBC methods is the same as preparing any other Java program. You can prepare the program using the javac command. JDBC applications do not require the precompile or bind steps. You can use IBM pureQuery can create and prepare Java applications. IBM pureQuery enables SQL access to databases or Java objects that are in memory and facilitates SQL best practices. Preparing an SQLJ program requires a precompile step and a bind step. The following program preparations steps are required by traditional programming languages. Precompile Before you compile or assemble a traditional language program, you must prepare the SQL statements that are embedded in the program. The DB2 precompiler prepares SQL statements for C, COBOL, Fortran, PL/I, and Assembler applications. Because most compilers do not recognize SQL statements, you must use the DB2 precompiler before you compile the program to prevent compiler errors. The precompiler scans the program and returns modified source code, which you can then compile and link edit. As an alternative, you can use a host language DB2 coprocessor for C, C++, COBOL, and PL/I as you compile your program. The DB2 coprocessor performs DB2 precompiler functions at compile time.

The main output from the precompiler is a database request module (DBRM). A DBRM is a data set that contains SQL statements and host variable information that is extracted from the source program during program preparation. The purpose of a DBRM is to communicate your SQL requests to DB2 during the bind process. Bind Before your DB2 application can run, you must use the BIND command to bind the DBRM to a plan or package. For example, you might decide to put certain SQL statements together in the same program in order to precompile them into the same DBRM and then bind them into a single package. When the program runs, DB2 uses a timestamp to verify that the program matches the correct plan or package. A plan can contain DBRMs, a package list that specifies packages or collections of packages, or a combination of DBRMs and a package list. The plan must contain at least one package or at least one directly bound DBRM. Each package that you bind can contain only one DBRM. A collection is a group of associated packages. Binding packages into package collections allows you to add packages to an existing application plan without needing to bind the entire plan again. If you include a collection name in the package list when you bind a plan, any package that is in the collection becomes available to the plan. The collection can even be empty when you first bind the plan. Later, you can add packages to the collection and drop or replace existing packages without binding the plan again. The CURRENT PACKAGE PATH special register specifies a value that identifies a list of collections that DB2 uses when resolving references to packages that you use to run SQL statements. Compile, link edit To enable your application to interface with the DB2 subsystem, you must use a link-edit procedure to build an executable load module that satisfies the requirements of your environment (such as CICS, IMS, TSO, or batch). The load module is a program unit that is loaded into main storage for execution. Run After you complete the preceding steps, you can run your DB2 application. A number of methods are available for preparing an application to run. You can:
y y y y y

Use DB2 Interactive (DB2I) panels, which lead you step by step from preparing the program to running the program. Submit an application in the TSO foreground or in batch in the TSO background. Start the program preparation command list (CLIST) in TSO foreground or batch. Use the DSN command processor. Use JCL procedures that you include in your data sets (such as SYS1.PROCLIB) at DB2 installation time.

You can also precompile and prepare an application program by using a DB2-supplied procedure. DB2 has a unique procedure for each supported language. Figure 1. Overview of the program preparation process for applications that contain embedded SQL when you use the DB2 precompiler

Or or

or

or

or or or or or

DRONA SERIES

DB2
DB2 Precompile-Compilation-Bind Process

INTRODUCTION

Static SQL - COBOL PRE-compile process

For COBOL-Static SQL program, program needs to be precompiled before doing actual compilation of that program.

Following are the 4 steps to compile a COBOL-DB

STEP 1 -

DB2 PRECOMPILE Process

The DB2 Precompile performs three functions. First, it checks the SQL in the program for errors. Second, it adds working storage areas and source code compatible statements that are used to invoke DB2. One of the working storage areas contains a literal "timestamp" called a consistency token. Finally, all of the SQL statements are extracted from the program source and placed into a member called the DataBase

Request Module, or DBRM, which also contains the consistency token.

STEP 2 -

COMPILE

The modified source from the precompile is then compiled. The code is checked for errors, and a compiled version of the code is created.

STEP 3 -

LINK-EDIT

The compiled code is link-edited along with statically called source language and DB2 run-time modules to create a Load Module. Imbedded in this module is the same consistency token that was generated in the precompile. If multiple DB2 programs are statically linked together, the resulting load module contains a consistency token for each one.

STEP 4 -

DB2 BIND

The bind process reads the DBRM that was created in the precompile and prepares an access path to the data. This access path, along with the consistency token, is stored in the DB2 catalog as a Package. Every Package is bound into a Package List, or Collection. The name of the Collection is specified by the PACKAGE parameter. A Collection is a group of Packages that are included in one or more Plans. The QUALIFIER parameter of the bind is used to direct the SQL to the specific set of DB2 objects (tables, views, aliases or synonyms) qualified by this name.

EXECUTING COBOL-DB2 PROGRAM When COBOL-DB2 Program executes, the plan name

must be specified. For online CICS programs, the plan name is specified by Tran ID in the Resource Control Table (RCT). For a batch program, the plan name is specified in the SYSTSIN input DD. The packages for all DB2 programs executed under a Tran ID or batch job step must be included in collection bound into this plan. When the first SQL statement of each program is executed, DB2 searches the collections within the plan using the package name and consistency token from the load module. If an exact match is not found, a -805 SQLCODE is returned.

Also visit..... COBOL DB2 PROGRAMMING - Primary SAMPLE COBOL DB2 COMPILE JCL SAMPLE COBOL DB2 RUN JCL

BETWEEN PLAN AND DIFFERENCE PACKAGE

package cantains one r more DBRMs.packages are obtained by passing DBRMs through bindpackage.package ia not executable because it does not contain any acess path. plan is obtained by binding DBRMs r packages.plan is executable as it contains the acess path. it is advantageous to use packages because it reduces the cost of bind it reduces rebound time if there r modifications in the sub program its just enough to crete a package 4 that sub pgm. lock options and various bind options can b controlled even in the subpgm level itself.