You can tune several aspects of your application rules and tables to make accessing Adabas data more efficient. This section provides some suggested techniques for building efficient applications.
A descriptor index is built within the Adabas database to aid efficient access to data in Adabas. It enables access to the data in an order determined by a particular field, sub-component of a field, or a combination of multiple fields (descriptor, subdescriptor and superdescriptor).
Using the Adabas direct call interface, you can choose the access path that Adabas uses. In Natural, for example, you can tell Adabas to access by descriptor. You can also do this with this SDK; unfortunately this breaks the consistent interface to data that TIBCO Object Service Broker tries to provide across all data sources. An application written using these techniques can lose some of its portability across different data sources without code changes. That is, you can lose the ability to move your data from Adabas into TDS or another DBMS without affecting the application. Therefore, use this feature carefully.
To access by descriptor index, the descriptor field in the table definition must be marked as a descriptor by setting the
Des field to Y. The access statement in the TIBCO Object Service Broker rules should be in the form:
This statement uses the greater than or equal to (>=) operator instead of just equal to (=). Although using equal to (=) is correct, greater than or equal to (>=) is more efficient since access to the Adabas table is with a direct Adabas
L3 or
L6 command, which reads data via the descriptor index that makes up the
descriptor_field in the table definition. This requires the reading of only part of the index instead of the entire index. For this to occur, set the
Des column for the descriptor field to a value of Y.
If you require more than one record, ensure that your rule has a means of ending the loop as soon as all required records have been returned. This can be done by calling a subsequent rule to do a check that issues a SIGNAL
signal when all qualifying records have been received.
The higher-level rule containing the FORALL should either have an ON signal... exception or the access statement should take the form FORALL.....UNTIL
signal. The examples below show a combination of rules for narrowing access by descriptor.
When the value of FIELD1 changes, the loop terminates and processing continues at the next rules statement.
RULE EDITOR ===> ADATEST
_
_ ---------------------------------------------------------
_ ---------------------------------------------------------
_ FORALL TABLEA WHERE FIELD1 >= ABCD UNTIL END_OF_DATA:
_ CALL TEST_FOR_END;
_ CALL PROCESS_TABLEA;
_ END;
_ ---------------------------------------------------------
RULE EDITOR ===> TEST_FOR_END;
_
_ ---------------------------------------------------------
_ TABLEA.FIELD1 > 'ABCD'; | Y N
_ ----------------------------------------------------+----
_ SIGNAL END_OF_DATA; | 1
Using descriptor indexes can slow the performance since TIBCO Object Service Broker tries to balance two factors when getting the external data. TIBCO Object Service Broker compensates by reducing either of the following:
This reduction is achieved by sending a request for data with the response being a block of data from the external database. The maximum size of the data in this block is approximately 3.9 KB. As a result, one message in response to the TIBCO Object Service Broker rules code can contain many rows of data.
In the previous example, more rows could have been read from Adabas than required. To be efficient as possible, you are provided with the option of predefining the number of rows that are returned in response to TIBCO Object Service Broker rules code.
|
|
Using the SERVER=>EE Block field to limit the number of occurrences accessed in one case can have a detrimental effect on other accesses to that ADA table by increasing the overhead of the message traffic. Refer to Specifying ADA Table Header Fields for the description of the SERVER=>EE Block field.
|
|
•
|
Set the Occurs/Read (occurrences per read) field (default 5) to the most appropriate value for your data.
|
In general, an efficient data-access design via Natural is also efficient in TIBCO Object Service Broker, since both generate direct calls and send them to Adabas for resolution. Although both can optionally do some additional evaluation of the found set returned from Adabas, it is more efficient in both cases for Adabas to do the work wherever possible. This is especially true for sorting returned items and is true of virtually all databases.
When data sequence is important, code FORALL statements appropriately. It is possible that the same FORALL statement, retrieving the same number of similarly structured rows from either Adabas or TDS using the same table definition, returns the data in a different sequence from each database. This occurs because Adabas returns data in descriptor index sequence, if the search expression uses one, whereas the same search on TDS returns data in primary-key sequence, which is the ISN in the case of Adabas.
This usually does not matter, as long as the same set of records is returned; normally the same operations are carried out on all records retrieved. However, if the record sequence is important, there are two possible solutions:
Use the TIBCO Object Service Broker Partial Match LIKE operator and the NOT EQUAL (¬=
or NOT =) operator only in combination with other operators. There is no direct command equivalent to these operators in Adabas, so using them alone forces a full sweep of all records in the file to satisfy the request. Using them with additional arguments enables Adabas to return a much smaller found set to TIBCO Object Service Broker.
The equality (=) operator is applied first to retrieve each occurrence with AreaCode equal to
905 and
then the NOT operator is applied before the data is passed on to the Execution Environment.
The only area in which consumption of CPU can be affected is in the table definition. Use the following techniques in your TIBCO Object Service Broker tables to optimize system performance:
