Differences in different modules obtained after compilations

Bharti P Manglani · New User Joined: 13 Mar 2007 Posts: 16 Location: Pune

Hi all,

First i just want to say this is an excellent forum. it is really great!!!!!

I was going through the topics and i found the terms object module, load module, linkedit and executable very confusing in cobol mainframes.

can you please tell me the difference between an object module and a load module?

and i guess later on we linkedit it with related progs and it we get an exe file. please let me know whether i am correct in my understanding.

thanks in advance..

guptae · Posted: Thu Mar 15, 2007 12:52 pm

Hi there,

STEP 1 - DB2 PRECOMPILE

The DB2 Precompile performs three functions. First, it checks the SQL in
the program for errors. Second, it adds working storage areas and source
code compatible statements that are used to invoke DB2. One of the working
storage areas contains a literal "timestamp" called a consistency token.
Finally, all of the SQL statements are extracted from the program source
and placed into a member called the DataBase Request Module, or DBRM, which
also contains the consistency token.

STEP 2 - COMPILE

The modified source from the precompile is then compiled. The code is
checked for errors, and a compiled version of the code is created.

STEP 3 - LINK-EDIT

The compiled code is link-edited along with statically called source language
and DB2 run-time modules to create a Load Module. Imbedded in this
module is the same consistency token that was generated in the precompile.
If multiple DB2 programs are statically linked together, the resulting load
module contains a consistency token for each one.

STEP 4 - DB2 BIND

The bind process reads the DBRM that was created in the precompile and
prepares an access path to the data. This access path, along with the
consistency token, is stored in the DB2 catalog as a Package. Every Package
is bound into a Package List, or Collection. The name of the Collection is
specified by the PACKAGE parameter. A Collection is a group of Packages
that are included in one or more Plans. The QUALIFIER parameter of the
bind is used to direct the SQL to the specific set of DB2 objects (tables,
views, aliases or synonyms) qualified by this name.

EXECUTING COBOL-DB2 PROGRAM

When COBOL-DB2 Program executes, the plan name must be specified.
For online CICS programs, the plan name is specified by Tran ID in
the Resource Control Table (RCT). For a batch program, the plan name is
specified in the SYSTSIN input DD. The packages for all DB2 programs
executed under a Tran ID or batch job step must be included in collection
bound into this plan. When the first SQL statement of each program is
executed, DB2 searches the collections within the plan using the package name
and consistency token from the load module. If an exact match is not
found, a -805 SQLCODE is returned.

Shobana Bhaskar · Posted: Thu Mar 15, 2007 1:38 pm

Wow simply great explanation!!

Can u clarify the difference between Plan and package??

Also am not clear about the term "consistency token".
You have mentioned as Statically... Then what happens for Dynamically called modules?

Bharti P Manglani · New User Joined: 13 Mar 2007 Posts: 16 Location: Pune

Hi Ekta,

thanks for such a wonderful explanation!!

i actually work in COBOL-VSAM, not DB2. Will this be applicable to VSAM also? and does this load module, object module concept apply to everywhere or it is DB2 only?

guptae · Posted: Thu Mar 15, 2007 1:50 pm

Hi Shobana,

Difference between Plan & package:
Both contain optimized code for SQL statements - a package for a single
program, module or subroutine contained in the date base request module
(DBRM) library. A plan may contain multiple packages and pointers to
packages.
A plan is an executable module containing the access path logic produced by
the DB2 optimizer. It can be composed of one or more DBRMs and packages.
Before a DB2 for z/OS program (with static SQL) can be run, it must have a
plan associated with it.
Plans are created by the BIND command. The plan is stored in the DB2
directory and accessed when its program is run. Information about the plan is
stored in the DB2 catalog.
A package is a single, bound DBRM with optimized access paths. By using
packages, the table access logic is "packaged" at a lower level of granularity
than a plan -- at the package (or program) level.
To execute a package, you first must include it in the package list of a plan.
Packages are not directly executed, they are only indirectly executed when
the plan in which they are contained executes -- as discussed previously,
UDFs and triggers are exceptions to this rule. A plan can consist of one or
more DBRMs, one or more packages or, a combination of packages and
DBRMs.

dick scherrer · Posted: Thu Mar 15, 2007 8:26 pm

Hello,

These: