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) plus SQL statement processing and bind steps.

Applications in interpreted languages, such as REXX and APL2®

REXX procedures use dynamic SQL. You do any program preparation for Db2 REXX procedures before you run them.

Applications that contain ODBC calls

These applications pass dynamic SQL statements as arguments. You do not process 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 SQL processing 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 host programming languages:

1. Process SQL statements in the program. This step is required to prevent compiler errors because most compilers do not recognize SQL statements. You can use the host language Db2 coprocessor for C, C++, COBOL, and PL/I to process SQL statements as you compile your program. The Db2 coprocessor perform scans the program and returns modified source code at compile time. For more information, see Processing SQL statements by using the Db2 coprocessor.

   Another option is to use the Db2 precompiler before you compile or assemble C, COBOL, Fortran, PL/I, and Assembler language programs. The Db2 precompiler scans the program and returns modified source code, which you can then compile and link-edit. For more information see Processing SQL statements by using the Db2 precompiler.

   Tip: The Db2 coprocessor is the recommended method for processing SQL statements in application programs. Compared to the Db2 precompiler, the Db2 coprocessor has fewer restrictions on SQL programs, and more fully supports the latest SQL and programming language enhancements. See Processing SQL statements by using the Db2 coprocessor.

   The main output from the Db2 coprocessor or Db2 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. For more information, see Output from the Db2 coprocessor.

2. Bind the application program. Before your Db2 application can run, you must bind the DBRM to a package. You might decide to put certain SQL statements together in the same program 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 collection is a group of associated packages. By binding packages into package collections you can 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.

   For more information about the bind process, see Binding application packages and plans.

3. Compile and link-edit the program. 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.
4. Run the program: After you complete the preceding steps, you can run your Db2 application. You can use the following methods to prepare an application to run:
   • 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.

Db2 Bind Manager tool

The Db2 Bind Manager tool helps application programmers:

• Predict whether a bind of a DBRM results 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

Db2 Path Checker tool

The Db2 Path 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.