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.

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.

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...

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?

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.

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.

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?)

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.