jerryte
Active User
Joined: 29 Oct 2010
Posts: 202
Location: Toronto, ON, Canada
|
|
|
|
I am in the process of converting plan-dbrm binds into package-dbrm binds. This is required for upgrade to version 10. To do this I have to setup some new collections. I would like to hear from others if they follow a naming standard for their db2 collections.
I was thinking of using a name that consists of the table creator id followed by a string that indicates the level of the program ie. development, QA test, or production. That way I know which database the packages will access. It also allows us to have 3 versions of a program. (note: we are not using package versioning at this time).
Please share your thoughts or ideas. |
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009
Posts: 1788
Location: Bloomington, IL
|
|
|
|
Our development, system test, and production systems are on different sysplexes. On our development sysplex (which spend 99.9% of my time logged into, and on which 99% of my code is used -- I am a Tool(TM) Developer  -- we have a generic production collection and regional office collections (because each regional office has its own LPAR and DB2 subsystem). When a developer is going to unit test a change, he will create the necessary objects and bind the necessary packages into his own collection (name = primary authid), and then create a plan from his collection, the regional collection, and the generic collection, in that order (all this will usually be done with my team's tools; the developer may not actually know how to write DDL or JCL).
This, of course, may be completely unsuitable to your needs  |
|
