Preparing an application program to run

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. Figure 6.1 gives you an overview of those preparation steps.

  Figure 6.1. Overview of program preparation process for applications that contain embedded SQL

  

• Applications in interpreted languages, such as REXX

  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 compile the program by using the javac command. JDBC applications do not require precompile or bind steps.

  Preparing an SQLJ program requires a bind step.

This section provides an overview of the program preparation steps that traditional programming languages require.

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 SQL coprocessor for C, COBOL, and PL/I as you compile your program. The SQL 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 ensure 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 having 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.

DB2 Bind Manager The DB2 Bind Manager tool helps application programmers: Predict whether a bind of a DBRM will result in a changed access path Run access path checks on a batch of DBRMs Eliminate unnecessary bind steps between application programs and the database Compare DBRMs to subsystems and load modules

In Version 8, 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:

• Use DB2 Interactive (DB2I) panels, which lead you step by step through the preparation process.

• 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 precompile and prepare an application program by using a DB2-supplied procedure. DB2 has a unique procedure for each supported language.