Posted: Thu Jul 27, 2006 10:51 pm Post subject: Bind Problem
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?
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.
Joined: 03 Jan 2003 Posts: 283 Topics: 27 Location: US
Posted: Fri Jul 28, 2006 10:10 am Post subject:
Quote:
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).
I didn't quite understand when you said this - How could B use a different DBRM library when he compiled the same program. So, If I understand it correctly from your problem, both of you share a common loadlib and a common DBRM library in your db2 compile jcl
What B should have done is NOT recompile the program again but just REBIND the DBRM pakcage to his different collection - He's recompiled the program and hence the load's timestamp got changed and now it's not matching up with your timestamp for T1
Do these tests to enhance your understanding - Please involve B also in these tests so that he understands and doesn't recompile something while you are doing these tests - Don't change any other loadlibs for these test
1. First, you recompile your module again and rerun the binds - Your -805 should go aways - Now, ask B to just run his module he would now get a -805
2. Now, ask B to do only REBINDS of your package to his collection - Now, if both of you run your programs on different regions, there shouldn't be any -805's
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum