Impact of package bind options

When you bind ODBC packages, you must specify certain values for several bind options. You should also consider specific ODBC recommendations for several other bind options.

The requirements and recommendations for the bind options are as follows:
  • CURRENTDATA(NO)

    Binding the ODBC packages with CURRENTDATA(NO) reduces lock contention and processor utilization, which results in increased application concurrency and improved performance. Use of CURRENTDATA(NO) also allows block fetching for distributed, ambiguous cursors.

  • DYNAMICRULES(BIND)
    Binding the ODBC packages with this option offers encapsulation and security similar to that of static SQL. The recommendations and consequences for using this option are as follows:
    1. Bind DB2® ODBC packages or plan with DYNAMICRULES(BIND) from a 'driver' authorization ID with table privileges.
    2. Issue GRANT EXECUTE on each collection or plan name to individual users. Packages are differentiated by collection; plans are differentiated by plan name.
    3. Select a plan or package by using the PLANNAME or COLLECTIONID keywords in the DB2 ODBC initialization file.
    4. When dynamic SQL is issued, the statement is processed with the 'driver' authorization ID. Users need execute privileges; table privileges are not required.
    5. The CURRENTSQLID keyword cannot be used in the DB2 ODBC initialization file. Use of this keyword results in an error at SQLConnect().
  • ENCODING

    The ENCODING bind option controls the application encoding scheme for all static SQL statements in a plan or package.

    Requirement: You must specify ENCODING(EBCDIC) when you bind packages to the local DB2 for z/OS® ODBC subsystem.
  • SQLERROR(CONTINUE)
    Important: Start of changeThe SQLERROR(CONTINUE) bind option bypasses every error that occurs during the bind operation for the package. The recommendation is to ensure that only expected SQLCODEs are bypassed.End of change

    Use SQLERROR(CONTINUE) for the following purposes:

    • When you bind DSNCLIMS on a down-level server. The symptoms of binding to a down-level server are:
      • Binding DSNCLIMS results in SQLCODE -199 on the VALUES INTO statement. Bind with the SQLERROR(CONTINUE) keyword to bypass this error.
      • Binding DSNCLIMS results in SQLCODE -199 on the DESCRIBE INPUT statement. Apply APAR PQ24584 and try the bind again to bypass this error. Alternatively, you can bind with the SQLERROR(CONTINUE) keyword, however, the SQLDescribeParam() API will be unavailable to you at the down-level server.
    • When you bind DSNCLIMS on a DB2 subsystem with MIXED DATA=YES

      Binding DSNCLIMS on any DB2 subsystem that is configured with MIXED DATA=YES results in SQLCODE -130. Bind with SQLERROR(CONTINUE) keyword to bypass this error.

    • When you bind DSNCLIMS on a DB2 subsystem with MIXED DATA=NO
      Binding DSNCLIMS on any DB2 subsystem that is configured with MIXED DATA=NO results in SQLCODE -189. You can bind DSNCLIMS with SQLERROR(CONTINUE) to bypass this error. However, if you do this you cannot fetch from an ASCII DBCLOB column using the SQLGetData() API or LOB LOCATORs. Before you can do that, you must:
      • Define your DB2 subsystem with MIXED DATA=YES, with valid mixed and graphic ASCII CCSIDs.
      • Rebind DSNCLIMS.