Copyright © Cloud Software Group, Inc. All Rights Reserved

Error Handling and Recovery

This section describes how the Gateway handles TIBCO Object Service Broker requests with respect to the following:

•	Synchronization and recovery

•	Error handling

Synchronization and Recovery

If your TIBCO Object Service Broker transaction is running in browse mode, the Ready Mode specified in the first IDM table accessed in the transaction determines how CA‑IDMS data is locked. If your TIBCO Object Service Broker transaction is running in browse mode, a shared retrieval (SR) Ready Mode is automatically used, regardless of what is specified in the first IDM table accessed in the transaction. No locks are taken in browse mode and you cannot update the data. A CA‑IDMS transaction spans the same length of time as a TIBCO Object Service Broker transaction.

Notes on Synchronization and Recovery

•	A normal end of transaction results in a DML FINISH being sent to CA‑IDMS.

•	A COMMIT request sent to the Gateway results in a DML COMMIT being sent to CA‑IDMS.

•	A ROLLBACK request sent to the Gateway or a transaction failure results in a DML ROLLBACK being sent to CA‑IDMS.

•	TIBCO Object Service Broker ROLLBACKs must be followed by a transaction end.

•	TRANSFERCALL and DISPLAY & TRANSFERCALL statements are allowed after a ROLLBACK.

The COMMITLIMIT exception does not apply to IDM tables. Requests to update CA‑IDMS data are processed as they are encountered and are not buffered in the Intent List.

Updating CA‑IDMS Data Only

Transactions that update only CA‑IDMS data are recoverable under CA‑IDMS.

Updating TIBCO Object Service Broker and CA‑IDMS Data

TIBCO Object Service Broker provides a method of ensuring data integrity when a TIBCO Object Service Broker transaction updates both CA‑IDMS 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 CA‑IDMS and TIBCO Object Service Broker data can result in discrepancies if the Gateway or the Data Object Broker abnormally terminates during transaction end processing. Refer to Implementing Fail Safe Processing for more information.

When a ROLLBACK request is sent to the Gateway, a DML ROLLBACK is sent to CA‑IDMS and the TDS Intent Lists are discarded.

Error Handling

The TIBCO Object Service Broker runtime environment signals system exceptions to permit an application to recover from an error. A three-level hierarchy of exceptions exists. All errors encountered when accessing CA‑IDMS data through the Gateway are trapped under one of the following exceptions:

 

ERROR

An error is detected and no lower-level exception handler is coded in the application.

 

ACCESSFAIL

A table access error is detected.

 

GETFAIL	No occurrence satisfies the selection criteria. The CA‑IDMS status codes 0326 or 0307 raise this exception.
DELETEFAIL	The primary key specified for a DELETE statement does not exist. The CA‑IDMS status codes 0326 or 0307 raise this exception. Note  This exception is raised only when a DELETE statement includes a WHERE primary_key = value.
INSERTFAIL	The primary key provided for an INSERT statement already exists. The CA‑IDMS status code 1205 raises this exception.

 

INTEGRITYFAIL

An attempt to violate data integrity is detected.

See Also

TIBCO Object Service Broker Programming in Rules about exception handling.

@SERVERERROR Tool

You must pass @SERVERERROR the contents of RETURN_MESSAGE, which has the following format:

pppIDnnnx serverid serveruserid source: Message

The following list describes the variables necessary to pass the RETURN_MESSAGE contents to @SERVERERROR:

ppp	The user-specified 3 character product ID.
nnn	The CA‑IDMS external message number.
x	The message severity (E for error, W for warning, and I for information).
serverid	The server ID of the Gateway.
serveruserid	The Gateway user ID (IDPREFIX + ###) of the Gateway.
source	The code portion of the Gateway that trapped the error and returned the message (for example, CSECT, rule, or function).
Message	The actual error message text.

If a specific message from a specific instance of Service Gateway for IDMS/DB 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 the @IDMSTATUSCODES control table. 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.

Table Processing

When the SERVERERROR exception is raised and the @SERVERERROR rule is called by your application, the following steps take place:

1.	@SERVERERROR reads the @SERVERMSGCNTL table and looks up the specific message identifier handlers.

2.	The appropriate message handler looks up the external error codes in the correct control tables.

3.	If any codes are found, they call the associated user-written handler.

4.	The user-written handler can use other functions and data stored in specific tables to handle specific external error/status codes.

Considerations

@SERVERERROR can be called at any time, although it is useful only for parsing TIBCO Object Service Broker IDMS/DB messages generated due to external CA‑IDMS 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 IDnnnx mentioned on page 103.

See Also

TIBCO Object Service Broker Shareable Tools for more information on the @SERVERERROR and RETURN_MESSAGE tools.

Copyright © Cloud Software Group, Inc. All Rights Reserved