Endevor and DB2

sushanth bobby · Posted: Fri Nov 27, 2009 4:13 pm

Hi,

We are planning in the mode for installing ENDEVOR scm, my doubt here is, Is there a need for a separate database for each stage for each system.

enrico-sorichetti · Posted: Fri Nov 27, 2009 4:21 pm

sushanth bobby · Posted: Fri Nov 27, 2009 4:35 pm

Thank You Very Much Enrico,

I meant stage as DEV --> ACPT --> QUAL --> PROD.

Sources i meant as source code, loads, compile listings & DBRM.

Sushanth

kgrimes · Posted: Mon Nov 30, 2009 8:53 pm

Hi Sushanth,

Most Endevor shops handle this situation by varying the DB2 QUALIFIER for each stage of the Endevor life cycle. So that each stage of the Endevor life cycle would point to a different occurrence within the same DB2 database where ever you wish to share databases. Each stage would have it's own set of output libraries such as loadlib, dbrmlib, jcllib, etc. and the Endevor processors bind the DBRM to the correct QUALIFIER for each stage.

Kevin

sushanth bobby · Posted: Mon Nov 30, 2009 9:20 pm

Thanks kgrimes,

Can i know what are inputs that endevor will ask when you want to compile & link-edit a DB2 program. Like SYSTEM, SUBSYSTEM, ELEMENT name, ENVIRONMENT, STAGE, DB2 QUALIFIER, COLLECTION.... is there anything like this endevor will ask as an input from the programmer.

Since i haven't seen the endevor screen, i have no idea what are the inputs it will ask.

Sushanth

kgrimes · Posted: Mon Nov 30, 2009 10:05 pm

Hi Sushanth,

Generally speaking, it is not a good idea to ask the programmers for anything that controls the configuration management or change management processes. You should define a consistent and repeatable process. In fact, most compliance programs require it.

Therefore, all required parameters should come from (or be derived from) the Endevor configuration where ever possible. (It is almost always possible if you really try.)

Endevor processor groups are normally used to define all the parameters required for any compile, link, and bind process.

However, it is also possible that the Endevor processors could dynamically create any required parameters based on the inventory classification (System, Subsystem, Type) and location (Environment and Stage).

Regardless of the tools used to manage source code and the change management process, there are many complexities with properly managing DB2 code. If you are not an Endevor Administrator and you have not even seen an Endevor screen, then you should definitely seek assistance from a qualified Endevor consultant who has a successful track record of Endevor implementations that include DB2.

As a Senior Endevor Consultant with 17 years of Endevor Administration experience, I'm available to help my clients plan, design, configure, and implement Endevor to support DB2 processing.

Regards,
Kevin

sushanth bobby · Posted: Mon Nov 30, 2009 11:31 pm

Hi Kgrimes,

enrico-sorichetti · Posted: Tue Dec 01, 2009 12:11 am

the bind parameters should not change across different db2 instances

the only thing to be changed would be the subsystem name, should not be an issue

build the bind command for each stage/level/db2_environment and let the endevor support integrate them .

kgrimes · Posted: Tue Dec 01, 2009 3:05 am

The DB2 bind parameters may or may not change for each stage of the Endevor life cycle depending on your site standards and configuration. The parameters that are most likely to change include: the DB2 subsystem name, OWNER, QUALIFIER, and EXPLAIN.

kgrimes · Posted: Tue Dec 01, 2009 3:11 am

Sorry, the list of parameters that are most likely to change should also include the DB2 Collection if you are using DB2 packages.

sushanth bobby · Posted: Tue Dec 01, 2009 11:32 am

Thank You Very Much ENRICO & KGRIMES