Binding the Gateway Plan

Copyright © Cloud Software Group, Inc. All Rights Reserved

Chapter 1 Installing Service Gateway for DB2 : Binding the Gateway Plan

Binding the Gateway Plan

After linking, the Gateway plan must be bound.

Determining Binding Procedure

How the Gateway plan is bound depends on whether you are using static SQL. To determine if you are using static SQL, view the tables of type DB2 and any static SQL information using the @STATICSQL tool. For more information about @STATICSQL, refer to Chapter 3, Using Static SQL.

Binding With Static SQL or Stored Procedures

Member BINDDB2S in the JCL data set (<HLQNONV>.<INSTVER>.JCL) binds the Gateway plan using members XBINDDB5 and XBINDDB7 of the CNTL data set (<HLQNONV>.<INSTVER>.CNTL) as input. The DB2 subsystem must be active to bind the Gateway plan.

BINDDB2S also references member XBINDDB6 in the data set defined in the @DB2SERVERJCL export table. XBINDDB6 (automatically generated by @STATICSQL each time you generate or remove static SQL) identifies additional DBRMs to include in your plan.

To bind the plan, do as follows:

1.

If you are binding a Gateway for the first time, customize members BINDDB2S and XBINDDB5.

Member XBINDDB5 identifies the DB2 subsystem and the Gateway plan name, as shown in the sample below:

DSN SYSTEM($DB2SSI$)
BIND PLAN($PLNAME$) -
  MEMBER(HDB2SREQ,HDB2SEL,HDB2ISRT,HDB2REPL,HDB2DLET,HDB2STPR -
    STATIC SQL HANDLERS if any
    STORED PROCEDURES if any
    .
    .
    .

The value of $PLNAME$ must be the same as the value of the PLAN gateway parameter. Modify $PLNAME$ as required.

If you are using the BROWSEPLAN and UPDATEPLAN gateway parameters, you must run this job once more for each of these parameters that you use, changing the PLAN gateway parameter accordingly. For more information, refer to Specifying the Gateway Plan to TIBCO Object Service Broker.

2.

Review member XBINDDB7 in the CNTL data set and customize if required. XBINDDB7 contains the remainder of the bind parameters as shown in the following sample:

) -
ACTION(REPLACE) RETAIN -
VALIDATE (RUN) -
ISOLATION (RR) -
ACQUIRE(USE) -
RELEASE(COMMIT)

3.

Submit BINDDB2S.

It should end with RC=0.

Sample bind parameters use ISOLATION(RR) for integrity, ACQUIRE(USE) and RELEASE(COMMIT) for maximum concurrency, and VALIDATE(RUN) for static SQL purposes. This is consistent with TIBCO Object Service Broker processing.

ISOLATION(CS) could lose data integrity during updates, because when DB2 releases locks on data, the data could still reside in a TIBCO Object Service Broker buffer. You can view the original data; be aware that data whose locks were released by a DB2 application or by a TIBCO Object Service Broker transaction could have changed. If you change the ISOLATION parameter to Cursor Stability (CS), ensure that TIBCO Object Service Broker pseudo-conversational coding techniques are used by applications updating DB2 data or that prior to an update the data row is required if you are unsure if the cursor is still positioned on the current DB2 page.

Consider using the DB2 BIND PACKAGE subcommand to manage the binding of Static SQL handlers. If you use it, you can have different ISOLATION and RELEASE parameters for each handler and it alleviates rebinding the entire Gateway plan each time a new Static SQL handler is introduced.

Binding Without Static SQL

Member BINDDB2 in the JCL data set binds the Gateway without static SQL using members XBINDDB5 and XBINDDB7 of the CNTL data set as input. The DB2 subsystem must be active to bind the Gateway plan.

To bind the Gateway without Static SQL, complete the following steps:

1.

If binding a Gateway for the first time, customize members BINDDB2 and XBINDDB5.

Member XBINDDB5 identifies the DB2 subsystem and the Gateway plan name as shown in the sample in Binding With Static SQL or Stored Procedures.

The PLAN parameter must correspond with the name provided by the PLAN gateway parameter. Modify this name as necessary.

If you are using the BROWSEPLAN and UPDATEPLAN gateway parameters, you must run this job once more for each of these that you use, changing the PLAN parameter accordingly.

2.

Review member XBINDDB7 in the CNTL data set and customize if required.

XBINDDB7 contains the remainder of the bind parameters as shown in the sample member in Binding With Static SQL or Stored Procedures.

Sample bind parameters use ISOLATION(RR) for integrity, ACQUIRE(USE) and RELEASE(COMMIT) for maximum concurrency, and VALIDATE(RUN) for static SQL purposes (modify this parameter to VALIDATE(BIND). This is consistent with TIBCO Object Service Broker processing.

ISOLATION(CS) could lose data integrity during updates, since when DB2 releases locks on data, the data could still reside in a TIBCO Object Service Broker buffer. You can view the original data; be aware that data whose locks were released by a DB2 application program or by a TIBCO Object Service Broker transaction could have changed. If you change the ISOLATION parameter to Cursor Stability(CS), ensure that TIBCO Object Service Broker pseudo-conversational coding techniques are used by applications updating DB2 data.

3.

Submit BINDDB2.

It should end with RC=0.