Oppolzer - Informatik / Blog

I will try to tell you what we do, but I'm almost sure that this
will apply to almost nobody else out there.

Our packages have no versioning and are always overwritten
during BIND, so there are never two "official" versions of the
same package.

That only works, because all our modules have a version number
as part of the module name !!! the last two digits ... and they are
called by an ALIAS without the two digits. The load module ALIAS
always points to the actual version of the module.

That is: the module is called AV471105, the alias AV4711 points
to it, the callers call AV4711 (dynamically). AV471104 is still on
the production library, and if there are problems with the new version,
the ALIAS can be linked to the previous version (module Fallback).

The DBRMs and packages have the names of the modules with the
version numbers, so there is no need for DB2 versioning.

That said: if module AV471106 is in development stage, AV471105
is in production stage. No problem with the DBRMs and packages,
they are different from the DB2 point of view.

As long as the developers do private tests, they have private databases
and private collections, so they may do BINDs as they like, but when
the module enters the normal staging chain (the different test
environments,
there are many, before production), there will be only one version of the
package (and one version of the module) at any given time.

Apart from our very special (and very old logic) with the version numbers
in the module names (which is 40 years old): you could do the same, IMHO.
That is: allow the developers to do private BINDs and private tests,
as they like, but limit the versions of the modules and packages to a
certain number (in extremis: one, like in our case) after the module enters
the staging chain.

This has to be managed by an appropriate change and configuration
management system. At our site, from that time on, the module is
automatically promoted (time controlled) through the different stages;
there is no action required by the application people and no action
by the DB or system admins. Even cleanup of the test environments is
done automatically, after the module entered production.

I'm sure, this will be the same at many other sites.

Kind regards

Bernd



Am 03.12.2013 14:25, schrieb A.B.:
>
> Is there any possibility of using Package Stability - Planmgmt - and
> maintaining the production version in a separate Collection? You would
> still need a one-off clean up but at the price of some initial effort
> it may provide a better solution. Having said that, there are probably
> many reasons why you can't / don't want to go that way.
>
> A.
>