What are the steps to be followed in Binding

samy · New User Joined: 11 Jun 2005 Posts: 2

Hi,

While doing a Bind in COBOL-DB2 program, what are the steps to be followed / parameters to be checked for 1.Bind Package 2.Bind Plan?

Is there anything like DBRM size, if so, please explain me about it!

Why do we go for a Bind plan directly bypassing the bind package at times?

priya · Posted: Sun Jun 12, 2005 12:56 pm

sangiah · New User Joined: 10 Jun 2005 Posts: 62

Both Application Plans and Packages perform the same function with respect to db2 programs. They provide the connectivity between your program and the db2 database. The difference is that an Application Plan provides the connectivity for a complete program (including all of the called sub-programs) while a package can provide the connectivity for a single sub-program. Each program must have an application plan but packages are an optional component that makes maintaining the application plans much easier.

In order for your program to be able to be executed without giving a -818 SQLCODE you need to bind an application plan for your entire program. If you are just using application plans then you will need to rebind the entire application plan for your program whenever the program or any of its sub-programs is changed. This can be time consuming and does not provide a backup if the bind fails. If instead you build a package for each program and sub-program and just provide pointers to these packages in the final application plan for each program then recompiling a sub-program requires only that its corresponding package be rebound and not the application plans for all of the programs that reference that sub-program. This not only saves considerable execution time while the bind is running but also your online programs will be offline for a shorter time while a package is being rebound than they would be if you rebind the application plan. Also you only need to rebind the package corresponding to the one sub-program so only the sub-program corresponding to that package would be affected and not the entire transaction.

iknow · Posted: Mon Dec 12, 2005 8:17 pm

Hi samy,

To your notice,

After bind you can run a cobol-db2 program by using the utility IKJEFT01 in the JCL.

Correct me if I am wrong.

Jag · New User Joined: 07 Dec 2005 Posts: 30 Location: India

hi Friend,

I will help you in understanding the Plan and Pacake as well.

When a cobol-db2 program is compiled the precomiliation will be done right? where the all sql will be commented and replaced by the Cobol Call statements.The sql in the programs is extracted and put in one place DBRM'S which is similar as pacake. So,The package is nothing but the extarct of the SQl statemnts in the program.But the PLAN is compiled form of the Packages..in other words executable form of the Packages which contains all the accesspaths for executing SQL's which has to be used for the packages under that Plan...So there is no ? of binding the PLAN bithout binding the Package..If you binf the package the Plan will automatically get updated..

For information you can see the following system tables

SYSIBM.SYSPLAN
SYSIBM.SYSPACKAGE
SYSIBM.PLAN_TABLE

Candy · New User Joined: 09 Dec 2005 Posts: 16

Hi friends,

Anyone pl explain me about rebind. When we go for rebind.

ALso, If timestamp mismatch occurs, what do we nee to do? Help me out this.

I am not very much familiar with db2.

regards,
Candy

iknow · Posted: Tue Dec 13, 2005 12:10 pm

Hi Candy,

Timestamp mismatch problem.

SQLCODE = -818.

Reason

THE PRECOMPILER GENERATED TIMESTAMP x IN THE LOAD MODULE IS DIFFERENT FROM THE BIND TIMESTAMP y BUILT FROM THE DBRM z.

Description

The SQL precompiler places timestamp 'y' in the DBRM, and time stamp 'x' in the parameter list in the application program for each SQL statement. At BIND time, DB2 stores the DBRM timestamp for run time use. At run time, timestamp 'x', for the SQL statement being processed,is compared with timestamp 'y' derived from the DBRM 'z' at BIND time. If the two timestamps do not match, the DBRM and the application program were not the result of the same precompile. This problem can occur if you: * Precompile, compile, and link, without doing a BIND of the application, * Precompile and BIND, without doing the compile and link for the application program, or * BIND the application using a DBRM that resulted from a different precompile of the application program than that which produced the object module that is linked into the application module. The timestamps 'x' and 'y' are DB2 internal timestamps. They do not have an external interpretation.

System Action

The statement cannot be executed.

User response

BIND the application again, using the DBRM for the application program that matches the object module.

Hope this helps.

Candy · New User Joined: 09 Dec 2005 Posts: 16

I got yr info. Thanks a lot.

Jag · New User Joined: 07 Dec 2005 Posts: 30 Location: India

Hi candy,

For youq ? when we have to rebing..Let us suppose when you change the sql's in a program and compile the program and run the program..Than it will take the previous plan only (which contaings the access paths and stuff of the previous SQL's)..and its will through an error...So in this kind of situations you have to Bind the packages..OK..