Package versioning

If you need to create multiple versions of an application, you can use the VERSION parameter in the PRECOMPILE command. This option allows multiple versions of the same package name (that is, the package name and creator name) to coexist.

For example, assume that you have an application called foo1, which is compiled from foo1.sqc. You would precompile and bind the package foo1 to the database and deliver the application to the users. The users could then run the application. To make subsequent changes to the application, you would update foo1.sqc, then repeat the process of recompiling, binding, and sending the application to the users. If the VERSION parameter was not specified for either the first or second precompilation of foo1.sqc, the first package is replaced by the second package. Any user who attempts to run the old version of the application will receive the SQLCODE -818, indicating a mismatched timestamp error.

To avoid the mismatched timestamp error and in order to allow both versions of the application to run at the same time, use package versioning. As an example, when you build the first version of foo1, precompile it using the VERSION parameter, as follows:

  DB2 PREP FOO1.SQC VERSION V1.1

This first version of the program may now be run. When you build the new version of foo1, precompile it with the command:

  DB2 PREP FOO1.SQC VERSION V1.2

At this point this new version of the application will also run, even if there still are instances of the first application still executing. Because the package version for the first package is V1.1 and the package version for the second is V1.2, no naming conflict exists: both packages will exist in the database and both versions of the application can be used.

You can use the ACTION parameter of the PRECOMPILE or BIND commands with the VERSION parameter of the PRECOMPILE command. You use the ACTION parameter to control the way in which different versions of packages can be added or replaced.

Package privileges do not have granularity at the version level. That is, a GRANT or a REVOKE of a package privilege applies to all versions of a package that share the name and creator. So, if package privileges on package foo1 were granted to a user or a group after version V1.1 was created, when version V1.2 is distributed the user or group has the same privileges on version V1.2. This behavior is usually required because typically the same users and groups have the same privileges on all versions of a package. If you do not want the same package privileges to apply to all versions of an application, you should not use the PRECOMPILE VERSION parameter to accomplish package versioning. Instead, you should use different package names (either by renaming the updated source file, or by using the PACKAGE USING parameter to explicitly rename the package).