Disallowing all automatic rebinds

One approach to handle binds and automatic rebinds while two releases coexist is to disallow all binds and disable all automatic rebinds on DB2® 10 members.

Procedure

To disallow or avoid automatic rebinds on a DB2 10 member:

  • Specify NO for the ABIND subsystem parameter. This disables all automatic rebinds on the DB2 10 member for any reason. The result is that you cannot run a plan or package on a DB2 10 member if it has gone through the following scenario:
    1. Binds on a DB2 10 member.
    2. Runs on a Version 8 or a DB2 9 member. This action causes an automatic rebind on the Version 8 or DB2 9 member.
    3. Attempts to run on a DB2 10 member.

      (This action returns a -908 SQLCODE (SQLSTATE '23510') because DB2 must automatically rebind the plan or package on DB2 10 before running it on the DB2 10 member.)

  • Begin general-use programming interface information.
    Use the resource limit facility to disallow BIND operations. Do this by inserting rows in the resource limit specification table (RLST) to set RLFFUNC to "1" and RLFBIND to "N". This ensures that nobody binds plans or packages on DB2 10.

    For example, the following INSERT statement for the RLST table, disallows all BIND operations for all authorization IDs (except those with installation SYSADM or installation SYSOPR authority) for all packages and plans:

    INSERT INTO authid.DSNRLSTxx
  (RLFFUNC,RLFBIND) VALUES('1','N');
    End general-use programming interface information.

What to do next

After all members of a data sharing group migrate to the current release, enable automatic rebinds by setting the ABIND subsystem parameter to YES. Allow bind operations by changing the RLST table accordingly or by stopping the resource limit facility by issuing a STOP RLIMIT command.