Skip to content

Promote

Promotion of the SP results in its deployment to the target Db2 subsystem. The target of the promotion must be covered by a logical Db2 subsystem definition and, by default, the standard templating provided by that definition will be applied.

There are 3 methods which may be used to promote (and install) native SQL SPs:

Drop/Create

This process does not differ to a great extent from the existing promotion mechanism for DDL in general. Facilities exist whereby the administrator can provide their own validation and manipulation routine. Changes required for test promotion levels (and, quite often, different target production environments) are made by the promotion (or installation) mechanism as the component is applied to the target environment. This is the methodology that the existing Db2 templating mechanisms follow. The facilities for native SQL SPs extend this method to allow the administrator to take control of both validation and manipulation of the SP component. This is implemented as an HLL exit point from CMNDB2DD where control is passed to a routine of the sites choosing (specified via SYSIN parameters). The incoming DDL is already allocated to the step and is available to be read from that ddname. The exit can request the termination of the process (and issue error messages), it will also be in a position to replace the incoming DDL values and pass the updated DDL either directly to Db2 (i.e. let CMNDB2DD apply the DDL directly) or output it to a dataset to be passed on to whichever Db2 processing utility the user site wishes to use. This is not a 'standard' HLL exit because the promotion job must be able to run on an LPAR other than the one where HLLX is running, and there may be no direct means of communicating back to ZMF in order to drive HLLX, so the exit is called directly from the execution of CMNDB2DD. The invocation method is very similar to standard HLLX, you will be able to code this exit in REXX or any LE-language.

Alter Add Version

If versioning has been requested in the admin definition for the logical subsystem then a row indicating the current active version will be written to the 'Db2 Object Attribute Table' to allow for a potential future demote action. A separate (optionally held) job will be submitted to activate the new version of all Native SQL SPs included in this promotion. If allowed to execute immediately then the changed SP will be activated at time of promote, else at a time later when the job is released. Indication of the current active version (i.e. prior to activating the just promoted version) is kept in the local CMNZMF.CMNDB2_ATTRIBS table.

These actions are implemented jointly between CMNDB2DD and CMNDB2AV. The keyword SPVERSION=YES is used to have CMNDB2DD generate activation transactions which are written to an external file. CMNDB2AV picks up these transactions and, based on their content, proceeds to save prior active version information and then activate the newly promoted SP.

Bind Deploy

When this deployment method is chosen we will route the relevant bind deploy command to the originating Db2 subsystem as indicated in the admin definitions. This is achieved from CMNDB2DD running on the target site and issuing a remote call to IBMs stored procedure called ADMIN_COMMAND_DSN. The location of the source subsystem will be provided on the call to this SP and it will issue the bind deploy command to the source Db2. The usual remote promotion job which executes at the target site will contain the ALTER request required to activate the new version of the SP.

These actions are, again, implemented by a combination of CMNDB2DD and CMNDB2AV. CMNDB2DD issues the BIND DEPLOY command (which is routed via a call to srclocation. SYSPROC.ADMIN_COMMAND_DSN) as a result of the SPVERSION=BOTH keyword. This results in version activation transactions being written to an external file and the BIND DEPLOY command being issued. Note that CMNDB2DD waits for confirmation that the

BIND DEPLOY has worked before proceeding. If it fails for some reason then messages are written to the CMNDB2DD SYSPRINT dataset and it finishes with rc=8. As a result, the CMNDB2AV activation process does not run. If all goes well then the BIND DEPLOY will have distributed the new version of the SP to the target Db2 subsystem and the ensuing CMNDB2AV execution will activate it.