MVSFORUMS.com

[Martin]

Hi Martin,

I'm new to DB2. DB2 Techies need to help me with this.

Here's the question/ problem.

I had a DB2 problem which I had compiled and bound to one of test region(T1). Another person(B) compiled the same program and bound it another test region (T2) using a different DBRM library(D2). Now when i tried to run the program its is giving me -805 ( Bind problem).

Can you folks out there let me know how to overcome this problem... Also I have few more questions on BIND.

1) What actaully does one mean by Binding a program to one region?
2) What is the deal with the timestamp? ( why does it have to the same)
3) Why can't I bind the same program to different region using the same DBRM library?
4) what does one mean when they say REPLACE A BIND & ADD A BIND?

- Martin

[CZerfas]

Well, the DB2 manuals are actually quite readable; you should not hesitate havening a look e.g. into the "application programming and SQL usage guide". For your questions:

1) In a program with static SQL, you define, WHAT you want to see (columns and the WHERE clause for their restrictions), but you don't code the navigation on the data. Someone has to generate the coding and decide
- to do a tablespace scan or to use one or more indices
- what table in a join is the "outer table"
- locking strategies
- ...

This is the work of the optimizer, who takes the SQL statements of your program (the DBRM) and the data characteristics (values counted via RUNSTATS), chooses the access strategies and generates coding to to that. This coding is than saved in the DB2 directory (skeleton package table).

Since the data characteristics of different "regions" (I assume you mean different qualifiers for the same named tables) could be completely different, DB2 wants to generate a "customized module", i.e. a package, for every region seperately.

2)In the program preparation process you split the elements of a DB2 programm by producing a load module and a package (via the DBRM). During run-time, these two elements have to be used in conjunction. With the help of the timestamp (that is the consistency token generated in the DB2 precompile phase and added to the load module) DB2 garantees, that only matching parts are used together.

3) Yes, indeed you should bind one DBRM into multiple regions, if the same load module is used in different program executions using different regions.

4) Using a REBIND, you take an existing package and say to the optimizer: Go and recalculate the access path to the data. With the same SQL statements and probably different data characteristics a new package (access module" is generated and placed into the skeleton package table: You replace an existing package.
If you do a new compile of a module, a new timestamp is generated by the precompiler and therefor a completely new package has to added via a BIND processing. This new package is then placed NEXT to an existing package of the same named program (the primary key columns for a package in the DB2 catalog are <collection> (should be your different regions), <module> AND <consistency token (i.e timestamp of your precompile).
During run-time, the timestamp in the load module is the "search criteria" in the skeleton package table for DB2 to retrieve the fitting package and use it.

good luck
Christian

[coolman]

[CZerfas]

Sorry, coolman, but you will confuse Martin with your explanations regarding BIND and REBIND:

REBIND simply re-optimizes an existing package in DB2.

If you want to use a fresh compiled module in more than one collection, you have to issue a BIND command with the new DBRM as input.

regards
Christian

[coolman]

I just re-read my notes- What I mean it not use the REBIND command but do a BIND again.

Sorry If my explanation had caused confusion.
________
ULTIMATE FIGHTERS