Advantage of using collection

atanwc · New User Joined: 26 Jul 2006 Posts: 24

My current company is using bind package but does not use collection. So every time after bind package, programmers need to bind plan(two bind steps). Besides, there are different plans for different batch processes. So in each plan, the plan member has a long list of packages. Changed or add one program, programmer may have to change plan list and bind a few plans.

I believe DB2 collection can make things better. But my DB2 knowledge is not very strong, I believe I know half half. So I want to have more expert advice before I change something. Here are my questions.

1) I am thinking if I can replace current setup into one(or two) grant plan and add one collection for each batch process. So I only need to bind once (bind package and not plan) and do not have to maintain the list of package any more, am I correct?

2) Will I have any problem/disadvantage by going this way?

3) What are other advantage(s) by using collections in this case?

4) If some programs are using IMS, will this cause problem by using collection?

Thanks for your comment and thanks for your time!

atanwc · New User Joined: 26 Jul 2006 Posts: 24

I believe I may mix up! It seems it is using collection but it is not using packlist (*) 'ALL' instead it list all package members one by one in packlist( ).

kutty.r · New User Joined: 22 Jun 2006 Posts: 24

the main advantage of using collection is thst

WE can even possible to add na package in to an plan with out doing an package bind

manishram1 · New User Joined: 23 Mar 2006 Posts: 34

Hi,
i think i can explain you with a explain you with a example.
Considering that you have named PLAN_A for a batch job which is using a list of programs like PROGRAM_1,PROGRAM_2,PROGRAM_3,PROGRAM_4,...etc

Instead of binding in two steps as explained by you,you can do one time bind of all the packages for the job with COLLECTION_A by including COLLECTION.* as shown below

Plan Bind::
BIND PLAN (PLAN_A) OWNER(XXX) QUALIFIER(XXXX)+
NODEFER(PREPARE) VALIDATE(BIND) FLAG(I)+
ISOLATION(CS) CACHESIZE(256) CURRENTDATA(NO)+
DEGREE(ANY) SQLRULES(DB2) ACQUIRE(USE)+
RELEASE(COMMIT) EXPLAIN(NO) DYNAMICRULES(RUN)+
REOPT(NONE) KEEPDYNAMIC(NO) IMMEDWRITE(NO)+
DBPROTOCOL(DRDA) ENCODING(37)+
DISCONNECT(EXPLICIT)+
PKLIST(COLLECTION_A.* )

Package binds will be done as following
Package Bind::
BIND PACKAGE(COLLECTION_A) MEMBER(PROGRAM_1)
LIBRARY('XXXX.XXX.XXX')+
OWNER(XXX) QUALIFIER(XXXX)
SQLERROR(NOPACKAGE)+
VALIDATE(BIND)
FLAG(I)
ISOLATION(CS)+
CURRENTDATA(NO)

So there is no need of binding the plan again and again since COLLECTION_A.* will take of the packages under that collection id.

if this process is followed only one time package bind will be needed whenever new program or old program changes are done in the batch job,there is no need of plan bind again and again.

Regards,
Mani

atanwc · New User Joined: 26 Jul 2006 Posts: 24

Thanks manishram1! Thanks for your details info.

I believe my company is using this method. I made the correction on July 26th 2006. Please see that! I was confused at the beginning.

But the reason that confused me was DBA suggested to use PKLIST( collection_a, collection_b,....collection_n) instead of PKLIST(*), so whenever there is a new program add in, the new program needs to add into the PKLIST. And there are a lot of problems in different test enviornments because the bind plan member is not insync with the DB2 in test enviornment1, test envirnment2...so on.

So what is the advantage of not using pklist(*). If we use pklist(*), can we just bind package and do not need to bind plan anymore.

Any good suggestion for the bind not insync problem?
Thanks again!

manishram1 · New User Joined: 23 Mar 2006 Posts: 34

In Detail consider that there are three test environments namely A,B,C
A----------->Collection_A
B----------->Collection_B
C----------->Collection_C

Always use PKLIST(Collection_A.*,Collection_B.*,Collection_C.*) in this case also there is not need of bind the plan only the package need to be.

PKLIST(*) will give syntax error...

Mani