The Gateway BIND parameters and the DB2 subsystem, not TIBCO Object Service Broker, determine how DB2 data is locked. A DB2 transaction spans the same length of time as a TIBCO Object Service Broker transaction.
When a commit is issued, DB2 data is committed and locks are released. The cursor position is maintained, because the DB2 statement is coded using WITH HOLD (as in
EXEC SQL DECLARE HURC01 CURSOR WITH HOLD FOR HURS01). Only at transaction end does the DB2 Gateway close the cursor.
TIBCO Object Service Broker provides a method of ensuring data integrity when a TIBCO Object Service Broker transaction updates both DB2 and TIBCO Object Service Broker data in the same transaction. This method is referred to as Fail Safe level‑1 processing.
If you did not request Fail Safe processing, transactions that update both DB2 and TIBCO Object Service Broker data can result in discrepancies if the Gateway or the Data Object Broker abnormally terminate during transaction end processing. Refer to
Implementing Fail Safe Processing for more information.
Using Static SQL for your application enables DB2 accesses to be done more quickly using less resources. When your application is complete, you can collect your TIBCO Object Service Broker DB2 access statements and use them to generate Static SQL. To do this, your system administrator must bring up an Execution Environment with the DB2LOG Execution Environment parameter set to Y. Refer to
Chapter 3, Using Static SQL for more information.
TIBCO Object Service Broker Parameters for further information on parameters.
The TIBCO Object Service Broker runtime environment signals system exceptions to enable an application to recover from an error. A three-level hierarchy of exceptions exists. Each exception traps the exceptions that appear below it in the hierarchy. All errors encountered when accessing DB2 data through the Gateway are trapped under one of the following exceptions:
|
There is a lock on an occurrence or a table is unavailable. SQL error codes -904, -913, and -30040 all raise this exception.
|
|
The DB2 authorization ID does not have permission to perform the requested action on the specified object. SQL error codes -551, -552, -553, -554, -555, and -556 all raise this exception.
The external security interface is implemented and one of the checks performed by the HRNSECD2 macro supplied by TIBCO Object Service Broker failed. Refer to Implementing External Security for more information.
The external security interface is implemented and the EXTERNALUSERID parameter is set to GROUP and is greater than eight characters.
|
|
A new transaction requested an instance of the Gateway and no Gateway is available. Control is passed back to the rule, so that the rule can try the transaction again. If this exception is raised too often, consider requesting more Gateways or reviewing the amount of work being done in your transactions.
|
|
The Gateway made a request to DB2 and DB2 returned an error code that does not map to one of the specific TIBCO Object Service Broker exceptions. The ON SERVERERROR handler can call @SERVERERROR to parse the error message (contained in ENDMSG).
|
|
A transaction was in progress when the connection to an instance of the Gateway was broken or the Gateway failed. Control is passed back to the rule for transaction cleanup.
SQL error codes -911, -918, -919, -929, ‑30020, -30030, -30041, -30072, and ‑30073 also raise this exception.
|
You must pass @SERVERERROR the contents of
RETURN_MESSAGE, which has the following format:
If a specific message from a specific Gateway has some information that is required to process the error, the table driven approach to the execution of
@SERVERERROR causes a rule (specified for that error by the developer using
@SERVERERROR) to execute. The error message is interpreted in the
@SERVERERROR processing and put into a temporary table until required.
To customize error handling, you must update data in one of the control tables @DB2SQLMSGCNTL or @DB2CAFMSGCNTL. The definition of these tables is owned by TIBCO Object Service Broker and must not be modified. The data you update in them is owned by you.
When the SERVERERROR exception is raised and the @SERVERERROR rule is called by your application, the following steps take place:
@SERVERERROR can be called at any time, although it is useful only for parsing TIBCO Object Service Broker DB2 messages generated due to external DB2 errors. The original message can always be retrieved using @SE_MSG when
@SERVERERROR has been called. The information parsed by
@SERVERERROR has transaction scope.
You can add your own instances in the @SERVERMSGCNTL table, provided that the OWNER specified begins with letters A to Z and the key values in their instance are message identifiers in the form D2
nnnx mentioned in
Using @SERVERERROR.
In TIBCO Object Service Broker, you CALL a stored procedure table mapping (TIBCO Object Service Broker table of type DB2, subtype P) from a rule. The Gateway sets up a DB2 SQLDA as per the columns in the table definition and issues the following:
On successful return (SQLCODE +466), the Gateway builds a row from all IN, INOUT and OUT parameters and returns. The SQLDA also contains the number of result sets that the stored procedure has generated. This information is returned in the #RS# field of the table.
If the stored procedure has generated any result sets, the field @HANDLE@ will be set to a non-zero value denoting the context of this particular call. That context remains available until discarded, either explicitly via a @DB2PROCDISCARD call or implicitly at the transaction end time. The caller is expected to fetch a result set through the FORALL statement against the predefined result-set mapping (TIBCO Object Service Broker table of type DB2, subtype R), which is parameterized by the @HANDLE@ available upon the CALL statement. The cursor-name attribute of this table denotes the particular result set to be fetched.
If the stored procedure reports multiple result sets, you can fetch them in any order. However, only one FORALL statement is possible at one time: A current FORALL against a result set is closed—and the respective result set discarded—by a subsequent FORALL against another result set.