View previous topic :: View next topic
|
Author |
Message |
prasun dhara
New User
Joined: 01 Mar 2008 Posts: 49 Location: kolkata
|
|
|
|
Hi,
What is the performance impact if we use CollectionId.* instead of CollectionId.packagename during bind.
For example :
In the PKLIST
Collectionid.Package1
Collectionid.package2
will serv the purpose but if we use CollectionId.* then also purpose will be served. In this case what is the performance impact if all the packages are bound to a plan.
Thanks
Prasun |
|
Back to top |
|
|
daveporcelan
Active Member
Joined: 01 Dec 2006 Posts: 792 Location: Pennsylvania
|
|
|
|
At our shop we use the construct CollectionId.*
There is no performance impact from what we can tell.
There several thousand packages in the collection. |
|
Back to top |
|
|
prasun dhara
New User
Joined: 01 Mar 2008 Posts: 49 Location: kolkata
|
|
|
|
Ok, If there is no performance impact everyone should use collectionid.* . What is the benefit of using collectionid.package1 ?
Thanks
Prasun |
|
Back to top |
|
|
Nic Clouston
Global Moderator
Joined: 10 May 2007 Posts: 2455 Location: Hampshire, UK
|
|
|
|
Why not think a bit...
If I gve you a problem bind with collectioid.* and asked you to sort it out wouldn't one of the first things that you would do is find out which packages are involved?
So that is one benefit of explicitly stating the package names. |
|
Back to top |
|
|
prasun dhara
New User
Joined: 01 Mar 2008 Posts: 49 Location: kolkata
|
|
|
|
Even it is bound with COllectionid.* .. During run time error comes like
Ex. -805
Package (Subsytem.collectionid.package.Ctoken ) not found in plan
So it can be found easily for which package the problem is coming.
It will be of great help if you give an example where I can see a problem of using collectionid.*
Thanks
Prasun |
|
Back to top |
|
|
daveporcelan
Active Member
Joined: 01 Dec 2006 Posts: 792 Location: Pennsylvania
|
|
|
|
We see no problem with it at all.
We have over 20,000 Plans that point to a collectionid.*.
In fact it makes things much easier.
Just say you have a batch application that has a driver and 12 subroutines. Do you really want to list each subroutine called in the pklist for the plan? I do not.
If you add a new subroutine, you would have to Bind your plan again.
If subroutine number 10 calls the new subroutine, and number 10 is called from 16 different plans, then each one must be bound again.
I see no advantage to listing each package explicitly. |
|
Back to top |
|
|
don.leahy
Active Member
Joined: 06 Jul 2010 Posts: 765 Location: Whitby, ON, Canada
|
|
|
|
Our shop does not use collectionid.*, but that is a security/audit rule not a performance concern. They want to be able to tell at a glance which packages can be executed by a given Plan. It is a minor PITA for developers to remember to rebind the Plan whenever a new package is added to the list, but on the plus side it helps with impact analysis. |
|
Back to top |
|
|
prasun dhara
New User
Joined: 01 Mar 2008 Posts: 49 Location: kolkata
|
|
|
|
thanks don. I have understood the benefit in impact analysis part.but what is the benefit in security/audit?. |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
don.leahy wrote: |
Our shop does not use collectionid.*, but that is a security/audit rule not a performance concern. [Secuirty/Audit People] want to be able to tell at a glance which packages can be executed by a given Plan. |
|
|
Back to top |
|
|
daveporcelan
Active Member
Joined: 01 Dec 2006 Posts: 792 Location: Pennsylvania
|
|
|
|
don.leahy also wrote:
Quote: |
It is a minor PITA for developers to remember to rebind the Plan whenever a new package is added to the list |
In our case it is more than a minor pain, it would be a huge pain.
We have over 30,000 packages and 20,000 plans. Keeping track of what runs where (and the success of the system dependent on it) would be a case of the tail wagging the dog. |
|
Back to top |
|
|
don.leahy
Active Member
Joined: 06 Jul 2010 Posts: 765 Location: Whitby, ON, Canada
|
|
|
|
It's only a minor pain because we've been doing it that way since packages were first introduced. We have over 200,000 packages and 120,000 Plans in one of our DEV subsystems.
I agree that trying to retrofit this approach in a large shop would be a daunting task. I would never recommend it.
I've worked in shops that use collectionid.* and I much prefer it, even at the cost of losing a convenient impact analysis tool. |
|
Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009 Posts: 1788 Location: Bloomington, IL
|
|
|
|
Currently, when a SA in my shop runs a test, he binds all packages for the program(s) he is testing and adds them to his personal collection. He then creates a plan consisting of all packages in this collection.
There is pressure to have me change the execs and skeletons fabricating the JCL and control cards to bind all packages using tables in any of the (DB2) data bases that he uses in testing and add them to his personal collection. I'm trying to resist this pressure... |
|
Back to top |
|
|
M David Hunter
New User
Joined: 30 Jan 2012 Posts: 6 Location: United States
|
|
|
|
Quote: |
There is pressure to have me change the execs and skeletons fabricating the JCL and control cards to bind all packages using tables in any of the (DB2) data bases that he uses in testing and add them to his personal collection. I'm trying to resist this pressure...
|
Akatsukami,
My shop is wanting to set up personal collections for each SA. What is required to do this for one collection? How can I estimate the time this process would take for one SA? |
|
Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
|
|
|
|
this personal stuff has always left me with a nagging question:
what does it buy you?
you still have to create a 'production' version, which has to be tested.
what do you achieve with this 'personal' approach?
in the last 20 or 25 years,
i have consulted in nearly as many shops,
and no one has ever used this approach.
IMUO, it is a waste of time and resources,
which could be better spent upgrading the skill-sets of your programmers. |
|
Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009 Posts: 1788 Location: Bloomington, IL
|
|
|
|
M David Hunter wrote: |
Quote: |
There is pressure to have me change the execs and skeletons fabricating the JCL and control cards to bind all packages using tables in any of the (DB2) data bases that he uses in testing and add them to his personal collection. I'm trying to resist this pressure...
|
Akatsukami,
My shop is wanting to set up personal collections for each SA. What is required to do this for one collection? How can I estimate the time this process would take for one SA? |
To the best of my knowledge, no set-up is necessary; it is sufficient to specify the collection ID on the BIND PACKAGE and BIND PLAN commands. |
|
Back to top |
|
|
M David Hunter
New User
Joined: 30 Jan 2012 Posts: 6 Location: United States
|
|
|
|
Thanks for all the input. Great input. |
|
Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009 Posts: 1788 Location: Bloomington, IL
|
|
|
|
dbzTHEdinosauer wrote: |
this personal stuff has always left me with a nagging question:
what does it buy you? |
As I may have mentioned before: in my shop any given source module may be being modified by anywhere from two to two hundred programmers, each working independently of the others. Each individual programmer has heesh (<--- note use of non-sexist pronoun) own libraries, data bases, tables, packages, etc. Doing otherwise would make things even more chaotic and less productive than they are now. |
|
Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
|
|
|
|
Akatsukami,
my only response is that it sounds as if the programs are too big.
but, that does not negate the necessity of handling it the way you do. |
|
Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009 Posts: 1788 Location: Bloomington, IL
|
|
|
|
dbzTHEdinosauer wrote: |
Akatsukami,
my only response is that it sounds as if the programs are too big. |
I agree. And if I'd begun working here in 1974 instead of 2004, I might have stopped them
Some programs (not a high proportion, to be sure, but we have over 20,000 main programs; five percent of that is too many) are comprised of dozens or hundreds of source modules; a few of thousands. Every data item access is in a module that does only that (good structured design, right? ), and that subroutine is dynamically linked to hundreds of main programs...sometimes at the end of a call chain fifteen or twenty levels deep (every reusable business function is also in a separate dynamically-called subroutine...good structured design, right?) |
|
Back to top |
|
|
M David Hunter
New User
Joined: 30 Jan 2012 Posts: 6 Location: United States
|
|
|
|
Akatsukami wrote: |
Each individual programmer has heesh (<--- note use of non-sexist pronoun) own libraries, data bases, tables, packages, etc. Doing otherwise would make things even more chaotic and less productive than they are now. |
Akatsukami, my employer thinks we should head in this direction. A consultant told me that to do this I would need to create a collection for each programmer. But I interpret you comments as saying it's much more than this. Instead, if we have three programmers and 5 databases then I would need 15 databases and all the objects within each, and 3x the packages, etc? Is that what you are saying? Thanks for any response you may offer. |
|
Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
|
|
|
|
M David Hunter,
i would agree that your assumption is correct.
if everybody is to have their own environment,
because coordination of development is something that can not be obtained,
you need an environment for each person.
which is taking unit testing to the ultimate plateau.
there is another thread where a individual had a problem
proving that 'he' did not make a mistake,
after having to copy things from this library to that in order to test.
yes, forcing everyone to use the same libraries,
(most places i have worked have development, systems, qa, prod
and that is it)
means that development must be coordinated.
sites that can not coordinate development,
need to have the 'individual' approach,
which apparently is easier for the 'managers'. |
|
Back to top |
|
|
don.leahy
Active Member
Joined: 06 Jul 2010 Posts: 765 Location: Whitby, ON, Canada
|
|
|
|
In my experience, the individualized approach only works when each individual has expert knowledge about the test environment. Even with that, a lot of support from the DBA is required in order to keep the environments current and consistent. |
|
Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009 Posts: 1788 Location: Bloomington, IL
|
|
|
|
don.leahy wrote: |
In my experience, the individualized approach only works when each individual has expert knowledge about the test environment. Even with that, a lot of support from the DBA is required in order to keep the environments current and consistent. |
I just got done explaining to a sotfware engineer pretending to be a DBA that my problem was not getting the -803 SQLCODE, but that his exec was returning the message for a -553 SQLCODE.
There are certainly knowledgeable DBAs; I've met some. Most, however, seem to be clueless junior programmers with DBADMIN privilege. |
|
Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009 Posts: 1788 Location: Bloomington, IL
|
|
|
|
M David Hunter wrote: |
Akatsukami wrote: |
Each individual programmer has heesh (<--- note use of non-sexist pronoun) own libraries, data bases, tables, packages, etc. Doing otherwise would make things even more chaotic and less productive than they are now. |
Akatsukami, my employer thinks we should head in this direction. A consultant told me that to do this I would need to create a collection for each programmer. But I interpret you comments as saying it's much more than this. Instead, if we have three programmers and 5 databases then I would need 15 databases and all the objects within each, and 3x the packages, etc? Is that what you are saying? Thanks for any response you may offer. |
In essence, yes. Now, as Messrs. Brenholtz and Leahy indicate, this is not necessarily a good way of doing things, and I'm not claiming that it is; it's just the way things are done here.
When a developer is ready to unit, integrate, or regress test, he runs tools (some written by me, others not) that tell him what DB2 objects, IMS data bases, VSAM data sets, etc. his program uses, create personal copies for him, and load them from (suitably masked) production data. Data sets are generally given HLQs of project-number.TSO-id.
DB2 is messier. Local standards are that data base names must be no more than five characters. A programmer is assigned a "user code" (two arbitrary alphas) and one or more "versions" (arbitrary alphanumerics). The user code/version combo is suffixed to the generic (five-character) data base name, and used to qualify every DB2 object that doesn't need an actual authid. So, every developer essentially has his own environment.
Likewise, when the alpha-null (OK, seldom more than a few dozen) packages needed for his program are bound, they are added to the collection TSO-id. A plan TSO-id is then created from *.TSO-id.* (and a few other collections) and used in conjunction with the program. |
|
Back to top |
|
|
don.leahy
Active Member
Joined: 06 Jul 2010 Posts: 765 Location: Whitby, ON, Canada
|
|
|
|
In our shop there are several 'test sets' that are assigned to projects rather than individuals. Each set consists of the same DB2 and IMS definitions, suitably resized, used in the production environment. Naming conventions are used to distinguish between the sets. There are a *lot* of objects in each test set.
It works well, but it requires an entire team of specialists using an elaborate toolkit to keep everything up to date with production changes. |
|
Back to top |
|
|
|