COPY bind option

The COPY option copies an existing package, and names that package.

COPY

( collection-id.package-id )
( collection-id.package-id ) COPYVER

On: BIND PACKAGE

Copying the package recalculates the access paths in the copy.

To create a remote copy, this option copies SQL statements from a package at your local server. Therefore, you must hold the COPY privilege or its equivalent at the local server.

collection-id: The name of the collection that contains the package to copy, as listed in column COLLID of catalog table SYSPACKAGE.
package-id: The name of the package to copy, as listed in column NAME of catalog table SYSPACKAGE.
COPYVER(version-id): Determines the version of the package to copy. The default for version-id is the empty string.

Restrictions:

collection-id.package-id must identify a package on the local server.
You cannot copy to a package in the same collection. If you make the copy on the local server, collection-id. on the COPY option must not name the collection used on the PACKAGE option.
DB2® uses the ISO format for output values unless the SQL statement explicitly specifies a different format. Input values can be specified in one of the standard formats, or in a format that is recognized by the server's local date/time exit.

Defaults:

Process	Default value
BIND PLAN	N/A
BIND PACKAGE	None
REBIND PLAN	N/A
REBIND PACKAGE	N/A

COPY has no default. If you do not use COPY, you must use MEMBER. You cannot use both options.

The option values of the package copied (except the values of ENABLE, DISABLE, OWNER, and QUALIFIER) become the defaults for binding the new package. You can override a default by choosing a new value for an option on the BIND PACKAGE command.

Copy packages to remote servers: To copy and bind packages from DB2 10 for z/OS® to some other server that does not support all the new BIND options in DB2 10, use the OPTIONS(COMMAND) option on BIND PACKAGE COPY. Any options you do not explicitly specify on the BIND PACKAGE subcommand are set to the server's defaults. Using this option can prevent bind errors when you bind and copy packages to servers other than DB2 10 for z/OS.

BIND PACKAGE for remote SQL: To execute SQL statements in the native SQL procedure after a CONNECT SQL statement or SQL statements that contain a three-part name from a remote server, you need a package at the target server. Use the BIND PACKAGE COPY command to specify the following:

Target location as the target site on the CONNECT/implicit DRDA SQL
Collection ID as the native SQL procedure's schema
Package ID as the native SQL procedure's name
COPYVER as the native SQL procedure's version

Example 1: To copy a version to a remote server using the BIND PACKAGE command, issue::

CREATE PROCEDURE TEST.MYPROC LANGUAGE SQL VERSION ABC ...
BEGIN
...
CONNECT TO SAN_JOSE
...
END
BIND PACKAGE(SAN_JOSE.TEST) COPY(TEST.MYPROC) COPYVER(ABC) ACTION(ADD)

BIND PACKAGE with SET CURRENT PACKAGESET and SET CURRENT PACKAGE PATH: To use the SQL statements SET CURRENT PACKAGESET and SET CURRENT PACKAGE PATH, you must use the BIND PACKAGE COPY command to specify the following:

Target collection ID as the target of the SQL statements
Source collection ID as the native SQL procedure's schema
Package ID as the native SQL procedure's name
COPYVER as the native SQL procedure's version

Example 2: To use the SQL statement SET CURRENT PACKAGESET with the BIND PACKAGE command , issue:

CREATE PROCEDURE TEST.MYPROC LANGUAGE SQL VERSION ABC ...
BEGIN
...
SET CURRENT PACKAGESET = 'COLL2'
...
END
BIND PACKAGE(COLL2) COPY(TEST.MYPROC) COPYVER(ABC)
									ACTION(ADD) QUALIFIER(XYZ)

If you need to create a new copy because the native SQL procedure has changed and requires a regeneration, use the BIND COPY ACTION(REPLACE) command.

Catalog record: Column COPY of table SYSPACKAGE.