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


Chapter 5 Using TIBCO Object Service Broker to Process Adabas Data : Using Rules

Using Rules
Accessing Adabas data using the rules language is similar to accessing TIBCO Object Service Broker data. The main difference is in the way Adabas interprets the request.
The following sections outline differences encountered while using rules and also point out normal TIBCO Object Service Broker rules behavior that you must consider when building applications.
Transaction Streams
If you issue a TIBCO Object Service Broker EXECUTE statement within a main (parent) transaction, it creates another transaction stream (child transaction), to a maximum of nine 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 Adabas data requires its own thread.
Ensure that your system administrator is aware of the number of the threads required to accommodate all transaction streams accessing Adabas data in a single transaction.
Using TRANSFERCALL or DISPLAY & TRANSFERCALL statements in your rules minimizes the threads and reduces the possibility of Adabas locking contention.
Table Access Dependencies
The number of ADA tables you can access per transaction depends on the POOLSIZE parameter. Refer to Supplying the Startup Parameters.
If you use the default startup and configuration parameter values, you can access at least sixteen ADA tables in one transaction. Your ability to access more tables depends on the size of the ADA table definitions. Refer to Estimation of the CTABLESIZE Parameter for more information.
Retrieval Processing
The Adabas Lx and Sx commands are used to retrieve data from Adabas for each retrieval statement (GET or FORALL) in your rule. The command you use depends on the request and the mode of the transaction.
When TIBCO Object Service Broker runs in browse mode, no locks are taken in Adabas. When TIBCO Object Service Broker runs in update mode, Adabas takes an exclusive lock on every occurrence that is read. When an exclusive lock cannot be obtained by Adabas, a LOCKFAIL exception is returned.
If the number of occurrences locked exceeds the maximum value for the NISNHQ Adabas parameter, a SERVERERROR exception is returned to the requesting rule along with a message documenting that this condition occurred.
Refer to Exceptions for more information about LOCKFAIL and SERVERERROR.
Some expressions cause the retrieval processing to do a complete sweep of the Adabas file. Wherever possible, specify at least one equality operator to restrict the amount of data retrieved. Refer to Taking Advantage of Adabas Features for more information on using rules efficiently.
GET Statement
A GET statement retrieves the first occurrence in the ADA table that satisfies the specified selection criteria.
A TIBCO Object Service Broker GET is equivalent to an Adabas FIND FIRST statement.
FORALL Statement
A FORALL statement returns occurrences to TIBCO Object Service Broker in the order in which Adabas passes them. If you require a different order, you must include an ORDERED clause in your FORALL statement, or specify ordering in the table definition.
If you know that you require only one record, use a GET statement rather than FORALL.
The TIBCO Object Service Broker FORALL is equivalent to an Adabas READ or FIND statement.
When running in update mode, the equivalent of an exclusive lock is applied to the occurrence being updated. To accommodate the largest number of occurrences that can be updated within a single transaction, increase the size of the NISNHQ parameter in the Adabas configuration as needed.
Replace (Update) Processing
A REPLACE statement that contains an operator is allowed for non-Adabas data only. This is not supported for ADA tables; the occurrence to be replaced must first be retrieved by a GET or a FORALL.
Sample REPLACE Statement Wrapped in FORALL

 
FORALL TABLEA WHERE FIELD1 = ABCD:
TABLEA.FIELDn=’A’;
REPLACE TABLEA;
END;

 
Delete Processing
Deleting an occurrence of a repeating structure whether it is a repeating group or a multiple value field is not supported. However, if you want to remove data from a repeating structure, use the same technique in TIBCO Object Service Broker as you would in Adabas, which is to nullify all the fields in the occurrence and replace this empty occurrence. For alphanumerics, set the field to spaces and for numerics to zeros.
A DELETE statement that contains an operator is allowed for non-Adabas data only. This is not supported for ADA tables; the occurrence to be DELETED must first be retrieved by a GET or a FORALL.
Here is a sample DELETE statement:

 
GET TABLEA WHERE FIELD1 = ABCD;
DELETE TABLEA;

 
Insert Processing
Adabas supports two kinds of insert processing according to the Internal Sequence Number (ISN). The ISN is either assigned by the system or the user specifies the ISN at insert time. The kind of processing to be used is determined in the table definition ISN Assigner field.
An ISN value must always be specified in the INSERT statement, even if it is assigned by the system. When the ISN Assigner field is set to SYSTEM, the supplied ISN value is ignored. This is because the ISN is a key field, which is a required field in the TIBCO Object Service Broker rules language.
See Also
TIBCO Object Service Broker Programming in Rules for general information about using the TIBCO Object Service Broker rules language and about TIBCO Object Service Broker transaction processing.

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