Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved


Chapter 9 Using TIBCO Object Service Broker to Process CA Datacom Data : Using Rules

Using Rules
Accessing CA Datacom data using the TIBCO Object Service Broker rules language is similar to accessing TIBCO Object Service Broker data. The main difference is in the way CA Datacom interprets the request.
The following sections outline the differences encountered while using rules and point out normal TIBCO Object Service Broker rules behavior to consider when building applications.
Transaction Streams
If you issue a TIBCO Object Service Broker EXECUTE statement within a main (parent) transaction, it creates another (child) transaction stream, to a maximum of ten streams. The number of streams allowed in a TIBCO Object Service Broker transaction depends on the TRANMAXNUM Execution Environment parameter, which has a default of nine streams. Each transaction stream in TIBCO Object Service Broker that accesses CA Datacom data requires its own server thread.
Ensure that your system administrator is aware of the number of server threads required to accommodate all transaction streams accessing CA Datacom data in a single transaction.
Using TRANSFERCALL or DISPLAY & TRANSFERCALL statements in your rules minimizes server threads and reduces the possibility of CA Datacom locking contention.
Transaction Limitations
The number of DAT tables you can access per transaction depends on the POOLSIZE server parameter. Refer to Specifying the Startup Parameters for more information.
If you use the default parameter values, you can access at least 16 DAT tables in one transaction; more, depending on the size of the DAT table definitions. Refer to Estimating the CTABLESIZE Parameter for more information.
Retrieval Processing
The SELxx CA Datacom commands are used to retrieve data from CA Datacom for each retrieval statement (GET or FORALL) in your rule.
When TIBCO Object Service Broker runs in browse mode, no locks are taken in CA Datacom. When TIBCO Object Service Broker runs in update mode, the server retains an image of all the occurrences read (CA Datacom imposes a primary exclusive locking limit of 9999 occurrences). When the update to the occurrence completes, the server re-reads the occurrence that is being updated, and if the image matches the image originally retained, the occurrence is replaced or deleted. If the images do not match, the update is not done and LOCKFAIL is signalled.
GET Statement
A GET statement retrieves the first occurrence in the DAT table that satisfies the specified selection criteria.
FORALL Statement
A FORALL statement returns rows to TIBCO Object Service Broker in the order in which CA Datacom passes them. If you require a different order, you must include an ORDERED clause in your FORALL statement.
When running in update mode, the equivalent of an exclusive lock is applied to the row being updated. To accommodate the largest number of rows to be updated within a single transaction, increase the size of the EXCTLNO parameter in the CA Datacom master list.
Replace (Update) or Delete Processing
If the Duplicate Master Keys field is set to N, the row is re-read, checked against its previous image, and if the images match it is replaced or deleted. If the Duplicate Master Keys field is set to Y, only one row at a time is returned to the Execution Environment and the last row retrieved is replaced or deleted.
The DELETE where primary key= statement is not supported for DAT tables.
Insert Processing
To insert rows to CA Datacom tables, ensure your DAT table definition includes the entire row.
See Also
TIBCO Object Service Broker Parameters for more information about Execution Environment parameter.
TIBCO Object Service Broker Programming in Rules for information about the rules language and rules processing.

Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved