Versions

When using packages, you can keep multiple versions of a single package that refer to different versions of the corresponding application program. This way, the programmer can use a previous incarnation of a program without rebinding. Before the availability of packages, when programmers wanted to use an old version of a program, they were forced to rebind the program's plan using the correct DBRM. If the DBRM was unavailable, they had to repeat the entire program preparation process.

You can specify a version as a parameter to the DB2 precompiler identifier up to 64 characters long. If so instructed, the precompiler can automatically generate a version identifier (which will be a timestamp). The version identifier is stored, much like the consistency token, in the DBRM and the link is generated from the precompile.

Other than the specification of the version at precompilation time, versioning is automatic and requires no programmer or operator intervention. Consider the following:

• When a package is bound into a plan, all versions of that package are bound into the plan.

• When a program is executed specifying that plan, DB2 checks the version identifier of the link that is running and finds the appropriate package version in the plan.

• If that version does not exist in the plan, the program will not run.

• To use a previous version of the program, simply restore and run the load module.

Versioning is a powerful feature of DB2 packages. You must take care, however, to administer the versions properly. Whenever a package is bound from a DBRM with a new version identifier, a new version of the package is created. As old versions of a package accumulate, you must periodically clean them up using the FREE command. Monitoring this accumulation is particularly important when the version identifier defaults to a timestamp because every new bind creates a new version.