Fail Safe level‑1 processing guarantees consistency when updating both TDS and IMS data from a single instance of the Gateway in a single transaction. At the end of a transaction, the Data Object Broker requests that the Gateway commit outstanding updates. As part of IMS commit processing, the Gateway updates an IMS transaction database to record the successful commit. If the Gateway does not respond to the Data Object Broker in a reasonable amount of time, the transaction is flagged as being in doubt. Locks held on TDS data remain in place until the problem is resolved.
When a connection is re-established between the Data Object Broker and a Gateway with the same configuration as the one that failed, the Data Object Broker asks the Gateway if the in-doubt transaction completed. The Gateway checks the IMS transaction database to determine this. If the update is completed in IMS, the TDS updates are applied and the locks are released.
Member XIMSTRXD exists in the CNTL data set. Modify this member as explained in the USAGE section at the top of the member. The transaction database holds a maximum of one segment occurrence for each combination of the Gateway and a Data Object Broker.
After defining an IMS transaction database, you must extract and load the transaction database into TIBCO Object Service Broker. When this is completed, you must define a TIBCO Object Service Broker IMS transaction table that points to the IMS transaction database. The default name for this table is @IMSFSTRXDB.
At startup, the Gateway asks the Data Object Broker for the TIBCO Object Service Broker IMS transaction table definition specified in the FSTABLENAME gateway startup parameter. This table definition is bound for the life of the Gateway and is used at transaction end to update the IMS transaction ID database.
The transaction table can be managed in TIBCO Object Service Broker like any other IMS table. For example, you can write a TIBCO Object Service Broker rule to clean up the Fail Safe database when shutting down the Gateway.