You are here: Home > Knowledge Refreshers

KR editions 75 to 77

KR-75: DB2 precompiler

We've seen the following so far: compiler, linker, loader, source code, object code. Time to get into plans and DBRMs.

This is the normal flow of events but if our COBOL code has DB2 SQLs then there are a few extra steps that have to be performed. Let's say we've written a COBOL code which has some SQLs in it.

1.) The COBOL compiler cannot understand the SQL statements. And if it were to encounter SQLs then it would flag compile time errors. So there needs to be someone who will be able to comment out these SQLs before the compiler runs. This someone is the DB2 precompiler. 

2.) The DB2 precompiler takes the source code (COBOL+DB2 commands), comments out the SQLs and inserts some CALL statements (these statements are DB2 interface functions); the CALL statements are allowed in COBOL. Code would be something like this:
CALL 'DSNHLI' USING SQL-PLIST7 

3.) The precompiler filters out the SQLs from the source code and creates a DBRM (Database Request Module).

4.) Thus the output of the DB2 precompiler will be: 
      a.) a modified source code (with SQLs commented out and some extra CALL statements)
      b.) a DBRM (containing the SQLs)

KR-76: DBRM cont.

Continuing with the previous edition.....

  • The modified source code (i.e. output of the DB2 precompiler) will be compiled as usual by the COBOL compiler and the object code will be created. 

  • We had mentioned that the modified source code will contain some CALL statements instead of the SQLs; like: CALL 'DSNHLI' USING SQL-PLIST7  

  • DSNHLI is another program. While compiling the original source code, the compiler won't know what DSNHLI is. It leaves this task to the linker. In the linking step, we'll need to specify where the object code of DSNHLI is, so that the linker can resolve this call statement. The link step will have a statement in the sysin card as:

INCLUDE SYSLIB(DSNELI) 
where DSNELI is an alias for DSNHLI.

  • The output of the linker will be the final load module. 

  • But there is a problem; this load module doesn't have any info about the SQLs. The SQLs were filtered out and stored in the DBRM. Thus the load module cannot be executed on its own. 

  • If our code didn't have any SQLs then the load module alone would have been sufficient for execution.

KR-77: PLANS

This is the final edition on our series about DBRMs, plans etc. 

  • Output of the DB2 precompiler is: DBRM + modified source code. 

  • The DBRM contains the SQL statements alone. 

  • The DBRM doesn't have any information about how to access the data requested from the tables (like what is the best method to access the database, optimizing the query, identifying whether the resources - tables- are accessible; i.e. whether we have the authority etc). Binding acheives all of the above. 

  • We bind the DBRM into an application plan (or execution plan) and this plan contains the information about the DB2 resources required and access paths. 

  • When we need to execute the COBOL code, we specify the code name (i.e. the name of the load module) and we also specify the PLAN name. 

  • Where does the plan lie? DB2 has a catalog (DB2 catalog) and a directory (DB2 directory) - these are like DB2's system directories. The information about the application plan lies in the DB2 catalog while the plan itself lies in the DB2 directory. 

  • Exploring in BMC you can also find a lot of interesting things about the plans used in programs (like finding out what are the tables a particular plan uses - just give the plan name and you'll get the list of tables).

  • Now you should be clear with load modules, object code, linker, compiler, binding, plans, DBRM and precompiler.

Go back to the main contents page