Collections Plans Packages and software versioning?

Lisa Westcott-Dryer

Collections Plans Packages and software versioning?
Help. I'm being asked to devise a method to be able to have multiple
versions of an application being developed at the same time! Yuk. I
hope someone out there has done this and can give me good parameters.

Basically there are 3 "regions" (using the term region, loosely)
DEVL,MODL,QUAL (are my HLQs on the same subsystem). I figure everything
must converge in the QUAL region before moving to production (PROD).
There are a lot of issues to wrestle with but my question is this. Can I
take and make additional COLLECTIONS and PLANs to handle the different
branches of programs in DEVL and MODL and therefore satisfy the
branching/versioning problem? After that how could I put them back
together in QUAL? Help!

Lisa Westcott-Dryer

[login to unmask email]

Re: Collections Plans Packages and software versioning?
(in response to Lisa Westcott-Dryer)
Howdy Lisa,

The easiest way would be to CREATE a DATABASE name qualified by region-id
(as you call it). This way you can hang identical-name DB2 objects off of
them
and not have to deal with COLLECTIONs etc. An example would be DEVLDB,
MODLDB and QYALDB. As you probably know the Database is the HIGHEST object
in the Heirarchy so any object attached to it could have the same name.

Hope This Helps,
Don Alden
Senior DB2 Consultant

-----Original Message-----
From: Westcott-Dryer, Lisa [mailto:[login to unmask email]
Sent: Thursday, January 04, 2001 2:05 PM
To: [login to unmask email]
Subject: Collections Plans Packages and software versioning?


Help. I'm being asked to devise a method to be able to have multiple
versions of an application being developed at the same time! Yuk. I hope
someone out there has done this and can give me good parameters.

Basically there are 3 "regions" (using the term region, loosely)
DEVL,MODL,QUAL (are my HLQs on the same subsystem). I figure everything
must converge in the QUAL region before moving to production (PROD). There
are a lot of issues to wrestle with but my question is this. Can I take and
make additional COLLECTIONS and PLANs to handle the different branches of
programs in DEVL and MODL and therefore satisfy the branching/versioning
problem? After that how could I put them back together in QUAL? Help!

Lisa Westcott-Dryer



[login to unmask email]

Re: Collections Plans Packages and software versioning?
(in response to Don.Alden@I-STRUCTURE.COM)
We have 1 PLAN (per program) each for DEVEL and PROD. (Our equivalent to
QUAL is just one of the DEVEL environments. Within DEVEL we have 28
standard "environments" . Each environment has its own CICS region,
Collection ID, DBRMLIB, SOURCE Lib, COPYLIB, etc., LOADLIB.

Projects are normally assigned 2 environments (sometimes more), one for
developers to work do project development, the second for client accepance
testing (ie QUAL). Developer Senior Analysts (and project managers to a
lesser exent) are responsible for assigning the available environments to
projects.

In our setup, only DBA is allowed to make table changes in the "standard
environments". When a project move to production, dba applies change to
all these env. So, if you use this approach, it is in your (DBA) interest
to limit number of environments you support.

For some of our apps developers also have "Personal DB's". These tend to
get out of hand because they are not maintained. So table definitions
rapidly get out of date, and lots of disk space can be wasted by unused
data or bad PRI/SEC QTY allocations.

Make sure you have a good (consistent) naming convention so that it is easy
for everyone to link all parts. ie we started off with Env "A" had DB "A"
and Collection ID "A". Then things started getting interesting.
Developers asked for second db in an Env. DBA said OK, Env "A" now has DB
"A1" and "A2" with matching collection ids "A1" "A2". Then developer said,
"we have Env A, but we don't need 2 DBs, but this other project does need
another db, move db "A1" to Env "B". And DBA said ok. Eventually we ended
up with a mess where DB names no longer always related env name and things
get confusing. (no I wasn't a DBA then, so it's 'not my fault' <BG>).





"Westcott-Dryer, Lisa" <[login to unmask email]>@RYCI.COM> on
2001/01/04 03:05:21 PM

Please respond to DB2 Data Base Discussion List <[login to unmask email]>

Sent by: DB2 Data Base Discussion List <[login to unmask email]>


To: [login to unmask email]
cc:
Subject: Collections Plans Packages and software versioning?



Help.  I'm being asked to devise a method to be able to have multiple
versions of an application being developed at the same time!  Yuk. I hope
someone out there has done this and can give me good parameters.

Basically there are 3 "regions" (using the term region, loosely)
DEVL,MODL,QUAL (are my HLQs on the same subsystem).  I figure everything
must converge in the QUAL region before moving to production (PROD). There
are a lot of issues to wrestle with but my question is this. Can I take
and make additional COLLECTIONS and PLANs to handle the different branches
of programs in DEVL and MODL and therefore satisfy the
branching/versioning problem?  After that how could I put them back
together in QUAL? Help!

Lisa Westcott-Dryer





Tim Lowe

Re: Collections Plans Packages and software versioning?
(in response to Rohn.Solecki@MTS.MB.CA)
Lisa,
IF you do not need separate tables for each of "environment" in your DB2
subsystem, then you may not need to create separate collections or plans at
all. You could simply put each "environment" into a separate DBRMLIB, and
then cleanup your packages based on the dbrmlib, package, collection and
version.
For example, our package cleanup process currently keeps only the most
current version of each package in each collection for each dbrmlib.
This way, if different projects want more "versions", then they use more
dbrmlibs.
Please note that when these additional dbrmlibs go away, you need to
cleanup all of their packages in order to avoid having some very old
packages kept around forever.

But, once you decide that you need separate tables for each environment,
the problems can become much more complex. In that case, you need to
provide some integrity to make sure which set of tables that your
subroutines are updating. Then, separate collections and plans are a good
idea. And, managing packages for "common subroutines" also becomes more
complex. (and then you wonder why you didn't just create more DB2
subsystems)

Good luck. I hope this helps.

Thanks,
Tim

P.S. We have discussed this several times on this list in the past, you
might want to check the archives.



James Campbell

Re: Collections Plans Packages and software versioning?
(in response to Tim Lowe)
Commiserations Lisa, it'll be a mess to control. All the following comments
are dependant on fitting into whatever promotion schemes you currently use.

Start by considering load libraries - mainly because your clients can
understand them and the way you manage packages is dependant on how you
handle load libraries. (I am presuming promotion is DEVL->MODL->QUAL)

Are you going to have
- a QUAL library that has has every module that is (at least) at this level
- each branch has a MODL library that has only programs that are at that
level in that branch
- and a DEVL library for modules at that level
and STEPLIBs which concatenate from bottom to top up the hierarchy.
OR are you going to have a single load library at each level in each branch
that contains all modules that have been promoted from that level. So your
STEPLIB is a single library.

The advantage of the first is a clean promotion path. A program will be
compiled/copied into a higher level library and deleted from the library
from whence it came. The disadvantage is that JCL could/might be a bit
messy to manage (although with suitable INCLUDE code it could be managed).

The advantage of the second is clean consistant JCL (one STEPLIB). The
disadvantage is that when a program is promoted (especially into QUAL), it
has to be copied into into all lower levels - except those where there is a
genuine need for a different version to exist (eg the program is being
worked on in that branch). And how do you know where this situation exists?
This is the bit that makes me think the first alternative is the better
option.

If you go for the first option you can now consider how to manage packages.
You need to choose between having
- one collection for each branch/level. This will only work if you use
versioning based on either the level or on the branch that the module was
compiled at or you use AUTO (with auto's clean up problems). (If you use a
fixed version, you end up having the same problem of working out "do I need
to bind this package into this collection" that you'ld have with the single
load library option.)
- a hierachy of collections that mirror the hierarchy of load libraries.
In each case, when you promote a module, you have to bind the resulting DBRM
into all the 'down hierarchy' collections.

How you manage PKLISTs in plans now falls out of your collection choice.

Where life becomes interesting is how you manage development of the the same
object (table or module) in two branches simultaneously. Let's look at them
separately

- modules (ie the same module is being worked on in two branches at the same
time). This is easy - for you. You turn to the application development
manager and say "it's your problem". As a reference note, the way SCLM
handles this problem is that, once one of the branchs' code is promoted into
the common level, it will not, by default, promote the second branch's code.
Either, the second branch has to de-migrate the first branch's code, or a
special override needs to be used. In either case, it is the responsibility
of the second branch's coders to incorporate the first branch's code.

- tables. This is where life pays you back for the ease with which you
handle program code. I really don't think you'll be able to generate a
hard-and-fast process to manage changes. Sometimes you might find it easy
to to change all DEVL tables together, sometimes you might have to wait for
a change to get to QUAL before you can put it into other branches, sometimes
you'll be turning to the application people and telling them that there is a
deadlock in the proposed changes and that you and they will need to sit down
and develop a schedule for implementing all the changes. What ever you do,
make sure you keep documentation on all changes until they have been
implemented into all environments.

Put a bit of care into your naming standard. Currently you might use just
the letters D, M, Q and P in plan, package, table qualifier names. You can
- use additional pairs for the other branches (eg A and B, E and F, etc).
This could be tricky because, when promoting you need to make sure you
specify both letters correctly. Do you want to promote from D to B?
- add an additional character for the branch. (eg D1 and M1, D2 and M2
etc). I would go for this, but does your overall scheme allow it?

Hope this gives you a few thoughts.

/* standard disclaimer */
James Campbell
DBA
Hansen Corporation, Doncaster
+61 3 9843 8442
[login to unmask email]

-----Original Message-----
From: Westcott-Dryer, Lisa [mailto:[login to unmask email]
Sent: Friday, January 05, 2001 8:05 AM
To: [login to unmask email]
Subject: [DB2-L] Collections Plans Packages and software versioning?


Help. I'm being asked to devise a method to be able to have multiple
versions of an application being developed at the same time! Yuk. I hope
someone out there has done this and can give me good parameters.

Basically there are 3 "regions" (using the term region, loosely)
DEVL,MODL,QUAL (are my HLQs on the same subsystem). I figure everything
must converge in the QUAL region before moving to production (PROD). There
are a lot of issues to wrestle with but my question is this. Can I take and
make additional COLLECTIONS and PLANs to handle the different branches of
programs in DEVL and MODL and therefore satisfy the branching/versioning
problem? After that how could I put them back together in QUAL? Help!

Lisa Westcott-Dryer




**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************