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. Some languages can be precompiled and compiled in a single step by a coprocessor.
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 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 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.

Begin figure description. This figure shows that you precompile the SQL statements, and then you bind the DBRM to a plan or package before running the DB2 application. Alternately, the DB2 coprocessor combines the precompile and compile steps, and does not create modified source for your application program. End figure description. — Figure 1. Overview of the program preparation process for applications that contain embedded SQL. The DB2 coprocessor can combine the precompile and compile steps for certain languages.

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.