help with plans, packages, pklists & collections!!!!

Melissa Rogers

help with plans, packages, pklists & collections!!!!
We are very new to DB2 and we are trying to establish BIND standards and
procedures. I have read through a lot of the archives to help me understand
the use of plans, packages, pklists and collections. We definitely want to
use packages but we are having difficulty deciding how these packages should
be placed into collections, pklists and plans. The first idea we came up
with for batch was to bind every program into a package. The package name
will equal the program name. The collection identifier will be created from
the name of the job stream. Every program that is part of the job stream
will have the same collection identifier in its package name. The plan name
will then equal the job stream name and will have a pklist consisting of one
collection (collection name.*). This would work similarly for online jobs
except the collection identifier name would be created from the CICS transid
and the plan name would equal the transid. We would then use a variable in
the job stream JCL to allow for different plans to be executed. Does this
logic seem reasonable or should we be considering other options? My concern
is with binding and rebinding. If a program change is made and the package
has 4 different collection ids and likewise is in 4 different plans, does
this mean the program needs to be rebound 4 different times for each
collection it is part of?
From the messages I have read in the archives, it sounds like people rather
use one plan for online and one plan for batch. Does this mean you are also
limiting your collection names to keep the pklist at a minimum or is your
pklist very long? Could someone point us in a "right" direction? Being new
to DB2 and having no applications in production and limited programs being
developed in test we want to try and make "good" decisions from the start.
I would appreciate any suggestions. Thanks, Melissa



[login to unmask email]

Re: help with plans, packages, pklists & collections!!!!
(in response to Melissa Rogers)
Melissa, what you purposing will work, but (you knew there was one coming
right), it seems to me that you will have a large number of collection ID's
and Plans to keep up with, And yes, you would have to bind the program
into ever how many collections ID's that you have it in.

One suggestion would be to divide it by application. For instance, payroll
would be one collection Id, You could have plan break down in some type of
meaningful boundaries. This could be the trans ID. Then in the plan you
would have the collection ID. * Then when bind a payroll program, you
should only have to bind it once in that collections ID. You then could use
this and apply it across all your application. You know that once you see
the plan up and bind it once, if you put a collection ID.* in it, you do
not have to bind it again when the program changes. You just have to bind
the package.

My response was not as long as your questions, but I hope this helps.

John C. Lendman
DBA
[login to unmask email]
(561) 694-5085
Beeper FPL 7413



"Melissa Rogers"
<[login to unmask email] To: [login to unmask email]
ATE.NY.US> cc:
Sent by: "DB2 Data Subject: help with plans, packages, pklists &
Base Discussion collections!!!!
List"
<[login to unmask email]>


01/10/02 12:35 PM
Please respond to
"DB2 Data Base
Discussion List"






We are very new to DB2 and we are trying to establish BIND standards and
procedures. I have read through a lot of the archives to help me
understand
the use of plans, packages, pklists and collections. We definitely want to
use packages but we are having difficulty deciding how these packages
should
be placed into collections, pklists and plans. The first idea we came up
with for batch was to bind every program into a package. The package name
will equal the program name. The collection identifier will be created
from
the name of the job stream. Every program that is part of the job stream
will have the same collection identifier in its package name. The plan
name
will then equal the job stream name and will have a pklist consisting of
one
collection (collection name.*). This would work similarly for online jobs
except the collection identifier name would be created from the CICS
transid
and the plan name would equal the transid. We would then use a variable in
the job stream JCL to allow for different plans to be executed. Does this
logic seem reasonable or should we be considering other options? My
concern
is with binding and rebinding. If a program change is made and the package
has 4 different collection ids and likewise is in 4 different plans, does
this mean the program needs to be rebound 4 different times for each
collection it is part of?
From the messages I have read in the archives, it sounds like people rather
use one plan for online and one plan for batch. Does this mean you are
also
limiting your collection names to keep the pklist at a minimum or is your
pklist very long? Could someone point us in a "right" direction? Being new
to DB2 and having no applications in production and limited programs being
developed in test we want to try and make "good" decisions from the start.
I would appreciate any suggestions. Thanks, Melissa








KATHY JONES

Re: help with plans, packages, pklists & collections!!!!
(in response to John_Lendman@FPL.COM)
Being somewhat new to DB2 too (less than 2 years), I will relate what we do here.
We have a plan for each application group for example: M6515BAT for batch and M6515OL1 for online. The collection ids are CM6515BA and CM6515OL. We also have under that plan, CSUBRTNB for batch sub-routines and CSUBRNTO for online subroutines. We have one collection id for payroll online that has several different packages M5510101, M6010101, etc but in batch they each belong to a separate batch collection id. I think it depends on the size of your shop. The DBA I am learning from feels it is easier to track a problem down if things are in separate collections and plans than all lumped into one. And I agree with that. just my two cents worth


Kathy Jones
Central Information Services
Clark County School District
Senior Database Analyst
NT DB2 DBA
702-799-5040 x366
[login to unmask email]

>>> [login to unmask email] 01/10/02 09:35AM >>>
We are very new to DB2 and we are trying to establish BIND standards and
procedures. I have read through a lot of the archives to help me understand
the use of plans, packages, pklists and collections. We definitely want to
use packages but we are having difficulty deciding how these packages should
be placed into collections, pklists and plans. The first idea we came up
with for batch was to bind every program into a package. The package name
will equal the program name. The collection identifier will be created from
the name of the job stream. Every program that is part of the job stream
will have the same collection identifier in its package name. The plan name
will then equal the job stream name and will have a pklist consisting of one
collection (collection name.*). This would work similarly for online jobs
except the collection identifier name would be created from the CICS transid
and the plan name would equal the transid. We would then use a variable in
the job stream JCL to allow for different plans to be executed. Does this
logic seem reasonable or should we be considering other options? My concern
is with binding and rebinding. If a program change is made and the package
has 4 different collection ids and likewise is in 4 different plans, does
this mean the program needs to be rebound 4 different times for each
collection it is part of?
From the messages I have read in the archives, it sounds like people rather
use one plan for online and one plan for batch. Does this mean you are also
limiting your collection names to keep the pklist at a minimum or is your
pklist very long? Could someone point us in a "right" direction? Being new
to DB2 and having no applications in production and limited programs being
developed in test we want to try and make "good" decisions from the start.
I would appreciate any suggestions. Thanks, Melissa






James Campbell

Re: help with plans, packages, pklists & collections!!!!
(in response to KATHY JONES)
Melissa

Try 1 collection per table qualifier. That is, there is a one-to-one
relationship between the QUALIFIER value and the PACKAGE
value. To make things easy, they could even be the same.

When you get into stored procedures and UDFs, again a one-to-
one relationship between the schema name and the table
qualifiers. Again, they could be the same.

Whether you have
- one plan per "program"
- one plan per table qualifier
- or, as you suggest, one plan per job
is a tuning decision. Many tuning utilities report by plan name. So
you need a way of being able to run program X in job Y with a plan
that is not used by anything else. Your way is as good/bad as
many others.

In all case the PKLIST is just a single entry (although some shops
do have
utility packages that live in a common collection - so they have two
collection.* entries in theirs).


The other thing you need to consider is fallback/multiple versions of
programs. You can do this one of two ways:
- when you pre-compile you use auto versioning. (The version
code is then based on the timestamp of the precompile.) But this
means that your collection accumulates many versions of the
package. You will have to clean these out.
- the second way is to use a fixed version. Each time you re-
compile a program, the old package-version is discarded. But if
you want to be able to go back and run an old version of the the
program, its package no longer exists. This is especially a problem
in CICS where you might
- pre-compile, compile and link a program
- bind the package
- CEMT NEW the program.
Between steps 2 and 3 you cannot run the program - because
you're using the new package with the old program. And what
happens if the CEMT NEW fails?

To handle this some people use a "previous version collection".
(Which is also in the PKLIST for their CICS plans.) Before step 2
they BIND COPY the current package from the "active collection" to
"previous version collection". Now if they run the program before
the CEMT NEW has finished, DB2 will get the appropriate package
- just from a different collection.

Just some thoughts
James Campbell

On 10 Jan 2002 at 12:35, Melissa Rogers wrote:

> We are very new to DB2 and we are trying to establish BIND standards and
> procedures. I have read through a lot of the archives to help me understand
> the use of plans, packages, pklists and collections. We definitely want to
> use packages but we are having difficulty deciding how these packages should
> be placed into collections, pklists and plans. The first idea we came up
> with for batch was to bind every program into a package. The package name
> will equal the program name. The collection identifier will be created from
> the name of the job stream. Every program that is part of the job stream
> will have the same collection identifier in its package name. The plan name
> will then equal the job stream name and will have a pklist consisting of one
> collection (collection name.*). This would work similarly for online jobs
> except the collection identifier name would be created from the CICS transid
> and the plan name would equal the transid. We would then use a variable in
> the job stream JCL to allow for different plans to be executed. Does this
> logic seem reasonable or should we be considering other options? My concern
> is with binding and rebinding. If a program change is made and the package
> has 4 different collection ids and likewise is in 4 different plans, does
> this mean the program needs to be rebound 4 different times for each
> collection it is part of?
> From the messages I have read in the archives, it sounds like people rather
> use one plan for online and one plan for batch. Does this mean you are also
> limiting your collection names to keep the pklist at a minimum or is your
> pklist very long? Could someone point us in a "right" direction? Being new
> to DB2 and having no applications in production and limited programs being
> developed in test we want to try and make "good" decisions from the start.
> I would appreciate any suggestions. Thanks, Melissa
>
>
>



Melissa Rogers

Re: help with plans, packages, pklists & collections!!!!
(in response to James Campbell)
Thanks to everyone who has responded to this. All of this information has
been very helpful!!!


-----Original Message-----
From: James Campbell [mailto:[login to unmask email]
Sent: Friday, January 11, 2002 5:17 AM
To: [login to unmask email]
Subject: Re: help with plans, packages, pklists & collections!!!!


Melissa

Try 1 collection per table qualifier. That is, there is a one-to-one
relationship between the QUALIFIER value and the PACKAGE
value. To make things easy, they could even be the same.

When you get into stored procedures and UDFs, again a one-to-
one relationship between the schema name and the table
qualifiers. Again, they could be the same.

Whether you have
- one plan per "program"
- one plan per table qualifier
- or, as you suggest, one plan per job
is a tuning decision. Many tuning utilities report by plan name. So
you need a way of being able to run program X in job Y with a plan
that is not used by anything else. Your way is as good/bad as
many others.

In all case the PKLIST is just a single entry (although some shops
do have
utility packages that live in a common collection - so they have two
collection.* entries in theirs).


The other thing you need to consider is fallback/multiple versions of
programs. You can do this one of two ways:
- when you pre-compile you use auto versioning. (The version
code is then based on the timestamp of the precompile.) But this
means that your collection accumulates many versions of the
package. You will have to clean these out.
- the second way is to use a fixed version. Each time you re-
compile a program, the old package-version is discarded. But if
you want to be able to go back and run an old version of the the
program, its package no longer exists. This is especially a problem
in CICS where you might
- pre-compile, compile and link a program
- bind the package
- CEMT NEW the program.
Between steps 2 and 3 you cannot run the program - because
you're using the new package with the old program. And what
happens if the CEMT NEW fails?

To handle this some people use a "previous version collection".
(Which is also in the PKLIST for their CICS plans.) Before step 2
they BIND COPY the current package from the "active collection" to
"previous version collection". Now if they run the program before
the CEMT NEW has finished, DB2 will get the appropriate package
- just from a different collection.

Just some thoughts
James Campbell

On 10 Jan 2002 at 12:35, Melissa Rogers wrote:

> We are very new to DB2 and we are trying to establish BIND standards and
> procedures. I have read through a lot of the archives to help me
understand
> the use of plans, packages, pklists and collections. We definitely want
to
> use packages but we are having difficulty deciding how these packages
should
> be placed into collections, pklists and plans. The first idea we came up
> with for batch was to bind every program into a package. The package name
> will equal the program name. The collection identifier will be created
from
> the name of the job stream. Every program that is part of the job stream
> will have the same collection identifier in its package name. The plan
name
> will then equal the job stream name and will have a pklist consisting of
one
> collection (collection name.*). This would work similarly for online jobs
> except the collection identifier name would be created from the CICS
transid
> and the plan name would equal the transid. We would then use a variable in
> the job stream JCL to allow for different plans to be executed. Does this
> logic seem reasonable or should we be considering other options? My
concern
> is with binding and rebinding. If a program change is made and the
package
> has 4 different collection ids and likewise is in 4 different plans, does
> this mean the program needs to be rebound 4 different times for each
> collection it is part of?
> From the messages I have read in the archives, it sounds like people
rather
> use one plan for online and one plan for batch. Does this mean you are
also
> limiting your collection names to keep the pklist at a minimum or is your
> pklist very long? Could someone point us in a "right" direction? Being
new
> to DB2 and having no applications in production and limited programs being
> developed in test we want to try and make "good" decisions from the start.
> I would appreciate any suggestions. Thanks, Melissa
>
>
>