REBIND PLAN (DSN)
The DSN subcommand REBIND PLAN rebinds an application plan when you make
changes to the attributes of the plan, such as the package list.
For example, you can use REBIND PLAN when you change authorizations, modify package lists for the plan, or use RUNSTATS. If the rebind is successful, the process prepares an application plan and updates its description in the catalog table SYSPLAN.
REBIND PLAN is generally faster and more economical than BIND PLAN. But if you change the SQL statements or recompile a program, you should use BIND PLAN with the option ACTION(REPLACE).
Environment
You can use REBIND PLAN through DB2I, or enter the REBIND PLAN subcommand from a DSN session running in foreground or background.
Data sharing scope: Group
Authorization
The plan owner must have authorization to execute all SQL statements embedded in the plan for REBIND PLAN to build a plan without producing error messages. For VALIDATE(BIND), DB2® verifies the authorization at bind time. For VALIDATE(RUN), DB2 initially verifies the authorization at bind time, but if the authorization check fails, DB2 rechecks it again at run time. If you use the PKLIST keyword, you must have EXECUTE authority for the packages or collections specified on PKLIST.
The plan owner must be a role to execute REBIND PLAN in a trusted context with role ownership.
The following table explains the authorization required to run REBIND PLAN, depending on the options specified.
| Option | Authorization required to run REBIND PLAN |
|---|---|
| REBIND PLAN with no change in ownership because the OWNER keyword is not specified. | The authorization IDs of the process must have one of the following
authorities:
|
| REBIND PLAN with no change in ownership, although the original owner is specified for the OWNER keyword. | The authorization IDs of the process must have one of the following
authorities:
|
| REBIND PLAN with change of ownership. (An authorization ID that is not the original owner is specified in the OWNER keyword.) | The new OWNER must have one of the following authorities:
Specifying the OWNER: If any of the authorization IDs has the BINDAGENT privilege granted from the owner, then authorization-id can specify the grantor as OWNER. Otherwise, OWNER authorization-id must be one of the primary or secondary authorization IDs of the binder. |
| COLLID, specifying (*), indicating all packages in the collection | You do not need any authorization privileges for this option. |
| COLLID, specifying individual packages | Authorization ID of the process must include one
of the following authority:
|
| PKLIST, specifying individual packages | Authorization ID of the process must include one
of the following authorities:
|
| PKLIST, specifying (*), indicating all packages in the collection | Authorization ID of the process must include one
of the following authorities:
|
Syntax
.-,---------.
V |
>>-REBIND PLAN--(-+---plan-name-+-+-)--------------------------->
'-*-------------'
>--+---------------------------+--+-------------------------+--->
| .-COLLID(*)-------------. | '-OWNER(authorization-id)-'
'-+-COLLID(collection-id)-+-'
>--+---------------------------+-------------------------------->
'-QUALIFIER(qualifier-name)-'
>--| enable-block |--| pklist-block |--+------------------+----->
+-NODEFER(PREPARE)-+
'-DEFER(PREPARE)---'
>--+-------------------------+--+--------------------------+---->
'-ACQUIRE(-+-USE------+-)-' '-CACHESIZE(decimal-value)-'
'-ALLOCATE-'
>--+------------------------+----------------------------------->
'-CURRENTDATA(-+-NO--+-)-'
'-YES-'
>--+------------------------------+----------------------------->
'-CURRENTSERVER(location-name)-'
>--+------------------------+--+-------------------+------------>
'-DBPROTOCOL(---DRDA---)-' '-DEGREE(-+-1---+-)-'
'-ANY-'
>--+-------------------------------+---------------------------->
'-DISCONNECT(-+-EXPLICIT----+-)-'
+-AUTOMATIC---+
'-CONDITIONAL-'
>--+--------------------------+--+-------------------------+---->
'-DYNAMICRULES(-+-RUN--+-)-' '-ENCODING(-+-ASCII---+-)-'
'-BIND-' +-EBCDIC--+
+-UNICODE-+
'-ccsid---'
>--+--------------------+--+---------------+-------------------->
'-EXPLAIN(-+-NO--+-)-' | .-I-. |
'-YES-' '-FLAG(-+-W-+-)-'
+-E-+
'-C-'
>--+-----------------------+--+---------------------+----------->
'-IMMEDWRITE(-+-NO--+-)-' '-ISOLATION(-+-RR-+-)-'
'-YES-' +-RS-+
+-CS-+
'-UR-'
>--+------------------------+--+-------------------------+------>
| .-NO--. | | (1) |
'-KEEPDYNAMIC(-+-YES-+-)-' | .-NONE-------. |
| | (2) | |
'-REOPT(-+-ALWAYS-----+-)-'
+-ONCE-------+
'-AUTO-------'
>--+--------------------+--+-----------------------------+------>
'-OPTHINT('hint-id')-' | .-,---------------. |
| V | |
'-PATH(---+-schema-name-+-+-)-'
'-USER--------'
>--+-----------------+--+---------------------------+----------->
| (3) | '-RELEASE(-+-COMMIT-----+-)-'
'-PATHDEFAULT-----' '-DEALLOCATE-'
>--+--------------------------+--+---------------------+-------->
'-ROUNDING(-+-CEILING--+-)-' '-SQLRULES(-+-DB2-+-)-'
+-DOWN-----+ '-STD-'
+-FLOOR----+
+-HALFDOWN-+
+-HALFEVEN-+
+-HALFUP---+
'-UP-------'
>--+----------------------+------------------------------------->
'-VALIDATE(-+-RUN--+-)-'
'-BIND-'
>--+---------------------------------------------------------+-><
'-CONCURRENTACCESSRESOLUTION(-+-USECURRENTLYCOMMITTED-+-)-'
'-WAITFOROUTCOME--------'
- REOPT(VARS) can be specified as a synonym of REOPT(ALWAYS)
- NOREOPT(VARS) can be specified as a synonym of REOPT(NONE)
- The PATHDEFAULT keyword cannot be specified with the PATH keyword.
enable-block >>-+--------------------------------------------------------------------------------+->< | .-,------------. .-------------------------------------. | | V | V | | '-+-+-ENABLE--+--(---+-BATCH----+-+-)-+----+---------------------------------+-+-' | '-DISABLE-' +-DLIBATCH-+ | | .-,---------------. | | +-DB2CALL--+ | | V | | | +-CICS-----+ | +-DLIBATCH(---connection-name-+-)-+ | +-IMS------+ | | .-,------. | | +-IMSBMP---+ | | V | | | +-IMSMPP---+ | +-CICS(---applid-+-)--------------+ | '-RRSAF----' | | .-,-----. | '-ENABLE(*)-------------------------' | V | | +-IMSBMP(---imsid-+-)-------------+ | .-,-----. | | V | | '-IMSMPP(---imsid-+-)-------------'
pklist-block >>-+--------------------------------------------------------------------------+->< | .-,----------------------------------------------------------. | | V | | +-PKLIST(---+---------------+--.--+-collection-id-+--.--+-package-id-+-+-)-+ | +-location-name-+ '-*-------------' '-*----------' | | '-*-------------' | '-NOPKLIST-----------------------------------------------------------------'
Option descriptions
For descriptions of the options shown in the syntax diagram, see the topic BIND and REBIND options for packages and plans.
Usage notes
Rebinding multiple plans: If you rebind multiple plans, DB2 commits each successful rebind before rebinding the next plan.
When you cannot rebind a plan: You
cannot rebind a plan while that plan is executing.
Examples
- Example: Rebinding a plan to replace the package list
- Suppose that PLANA uses package list COLLA.* Suppose that you
want to replace that package list with COLLB.* Issue a command like
this one:
REBIND PLAN (PLANA) - PKLIST(COLLB.*) - FLAG(W) - VALIDATE(BIND) - ISOLATION(CS)This REBIND command also does the following things:
- Uses FLAG(W) to issue warning, error, and completion messages, but not informational messages.
- Uses VALIDATE(BIND) to point out any error conditions during the bind process.
- Uses ISOLATION(CS) to prevent other applications from changing the database values that this application uses only while the application is using them. This isolation level protects changed values until the application commits or terminates. In this example, the isolation is not set for the packages, so ISOLATION(CS) becomes the isolation level for the plan and the packages.
- Omits the OWNER keyword to leave the plan's owner authorization ID the same.
- Omits the ENABLE or DISABLE keywords to use the connections previously defined for the plan.