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:

• 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

Figure 2. Overview of the program preparation process when you use the DB2 coprocessor

DB2 Path Checker

Checker helps you increase the stability of your DB2 environments and avoid painful and costly disruptions. The DB2 Path Checker can help you discover and correct unwanted and unexpected access path changes before you are notified about them.