![]() |
Copyright © TIBCO Software Inc. All Rights Reserved |
This section describes how the Gateway handles TIBCO Object Service Broker requests with respect to:Locking of IMS data is determined by the PROCOPT parameter for the database PCB in the Gateway PSB and not by TIBCO Object Service Broker. The IMS unit of work spans the same length of time as a TIBCO Object Service Broker transaction.DL/I CHKPs are sent from the Gateway to IMS at the end of a transaction. After a COMMIT or ROLLBACK is issued from a rule, an end of transaction is required.
• A COMMIT request sent to the Gateway, or a normal end of transaction results in a DL/I CHKP being sent to IMS.
• A ROLLBACK request sent to the Gateway or a transaction failure results in a DL/I ROLB being sent to IMS.
• Intermediate COMMITs and ROLLBACKs are not allowed if IMS data is updated.
The exception COMMITLIMIT does not apply to IMS tables. Requests to update IMS data are processed as they are encountered, and are not buffered in the intent list.TIBCO Object Service Broker provides a method of ensuring data integrity when a transaction updates TIBCO Object Service Broker and IMS and DB2 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 TIBCO Object Service Broker and IMS and DB2 data can result in discrepancies if the Gateway, the Data Object Broker, or the IMS Control Region abnormally terminate during transaction end processing. Refer to Implementing Fail Safe Processing for more information.For IMS data access only, when a ROLLBACK request is sent to the Gateway, a DL/I ROLB is sent to IMS and the TDS intent list is discarded.For concurrent access to IMS and DB2 data, when a ROLLBACK request is sent to the Gateway, a DL/I ROLB is sent to IMS, IMS coordinates the ROLLBACK with DB2, and the TDS intent list is discarded.The TIBCO Object Service Broker runtime environment signals system exceptions so an application can recover from an error. A three-level hierarchy of exceptions exists. All errors encountered when accessing IMS or DB2 data through the Gateway are trapped under one of the following TIBCO Object Service Broker exceptions:
No occurrence satisfies the selection criteria. The IMS status codes GB and GE raise this exception. The primary key specified for a DELETE statement does not exist. The IMS status codes GB and GE raise this exception. The primary key provided for an INSERT statement already exists. The IMS status codes II, LB, and LD raise this exception. The primary key provided for a REPLACE statement does not exist. The IMS status codes GB and GD raise this exception.
A table definition error is detected. The IMS status codes AC, AK, AM, AT, AU, GD, and V1 raise this exception. There is a lock on a segment occurrence. The IMS status code BA raises this exception. Permission for the requested action on the TIBCO Object Service Broker object is denied.
• The EXTERNALUSERID parameter is set to GROUP and it is greater than eight (8) characters
• One of the checks performed by the System Authorization Facility (SAF) compliant external security package failedRefer to Implementing External Security for more information. A new transaction requested an instance of the Gateway, and no Gateway is available or running. Control is passed back to the rule so it can try the transaction again. If the exception is raised very often, consider more Gateways or review the amount of work being done in your transactions. The Gateway made a request to IMS, and IMS returned an error code that does not map to an TIBCO Object Service Broker exception. The ON SERVERERROR handler can call @SERVERERROR to parse the error message contained in ENDMSG. One of the following conditions occurred and control is passed back to the rule for transaction cleanup:
• A transaction was in progress when the connection to an instance of the Gateway broke.
• Integrity with the current SL/I unit of work was lost. IMS backs out all database updates made by the Gateway since the last checkpoint. The IMS status codes BB and BC raise this exception. An attempt was made to update a table with invalid data. The data could have failed a validation rule or reference checking. The IMS status codes DA, DX, IX, NI, and RX raise this exception.TIBCO Object Service Broker Programming in Rules about exception handling.The following list describes the variables necessary to pass the RETURN_MESSAGE contents to @SERVERERROR:
The code portion of the server that trapped the error and returned the message (for example, CSECT, rule, or function). 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 @IMSMSGCNTL or @IMSMSGRCCNTL. 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.The list below shows how tables are processed when the SERVERERROR exception is raised and the @SERVERERROR rule is called by your application:
• @SERVERERROR reads the @SERVERMSGCNTL table and looks up the specific message identifier handlers.
• The appropriate message handler looks up the external error codes in the correct Gateway control tables.
• The user-written handler can use other functions and data stored in specific tables to handle any specific external error/status code.@SERVERERROR can be called at any time, although it is useful only for parsing TIBCO Object Service Broker IMS messages generated due to external IMS errors. The original message can always be retrieved using @SE_MSG after @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 IMnnnx mentioned on page 139.TIBCO Object Service Broker Shareable Tools for more information on the @SERVERERROR and RETURN_MESSAGE tools.
![]() |
Copyright © TIBCO Software Inc. All Rights Reserved |