FOCUS constructs an ADABAS request based on the Master File, Access File, and the report request. The root of the subtree is the entry segment into the database for a particular request.
For ADABAS structures, the root of the subtree must be a segment in the Access File containing singly occurring fields (ACCESS=ADBS). The ADABAS calls generated to retrieve data for this entry segment depend on the Access File information that has been supplied for the segment and the selection tests in the request.
The first decision the ADABAS Interface makes for the entry segment is whether to retrieve all the records of the segment or just a subset.
All records are retrieved for a segment if either of the following conditions exists:
IS, EQ, GE, GT, LT, LE, or FROM...TO
For example:
field IS value1 [(OR value2... OR valuen)]
field IS (ddname)
field FROM value1 TO value2 [(OR value3 TO value4...)]
field GE value1
field GT value1
field LT value1
field LE value1
group EQ 'value1/value2/value3'
When you are using one or more of these selection tests against a descriptor, the Interface uses the inverted list to retrieve a subset of the records for the segment.
For example, consider the following selection criterion:
field IS value1 [(OR value2... OR valuen)]
In this example, any combination of full values or partial values triggers the use of inverted lists except when the $ (used to indicate a masked field) is in the first position of the value. If the $ is in the first position of the value, the search conducted by ADABAS is not done through the descriptor's inverted list. Instead, the search is conducted physically through the database in the same manner that a Read Physical call performs a retrieval. See Read Physical Calls for more information, and the FOCUS for IBM Mainframe User's Manual for more information on using the $ as a masking character.
Once the Interface determines whether to retrieve all or a subset of the segment records, it decides which access strategy to use based on the Access File attribute settings. The following are the strategies that the Interface can use:
The selection logic is designed to implement as many of the record selection tests as possible at the ADABAS level. It minimizes the number of I/O operations required to access the necessary data by issuing efficient calls to ADABAS.
Read Physical calls read every database record in a physical file, and then return every record for the entry segment to FOCUS. FOCUS must then select the records that meet the request's selection criteria and discard the rest.
The ADABAS Interface issues Read Physical (L2) calls to retrieve all records for the entry segment when:
See Report Considerations, for more information about retrieval of records with no screening on a descriptor.
The steps the ADABAS Interface and ADABAS perform to complete a Read Physical call are:
Subsequent retrieval for the entry segment is completed by issuing the same Read Physical call with the User Control Block unmodified. The ADABAS Interface terminates retrieval when one of the following occurs:
Read Physical (L2) calls can be faster than Read Logical (L3) calls depending on the request and the data dispersion of the physical storage. Ask your ADABAS database administrator if you should use SEQFIELD for a given ADABAS record, or if Read Physical would be more efficient.
When designing a database, it is necessary to know the contents of the files being created. Defining descriptors is very important for efficiency. The ADABAS Interface does not know information about the different fields or which field is more efficient to parse first unless the Access File has this information. The Access File tells the ADABAS Interface how to access your data in the most efficient manner. The order of the fields (for example, DSC, NOP, or SPR descriptors) is very important in the Access File, as the Interface uses this order when executing an IF or WHERE statement.
The Access File needs to have information about the index fields used in the report request. The order in which you define these fields is very important. ADABAS is field oriented, not positional. The order of the fields will not affect retrieval, except for the selection of which inverted list to use.
The Access File controls the order of the IF or WHERE statements, so the database administrator can set up the Access File in the order of the most efficient reads. The user will then receive the requested data much more efficiently. The order in the Access File controls the order of retrieval.
The ADABAS Interface uses Read Logical (L3) calls to retrieve all records for the entry segment when the Access File contains a SEQFIELD value for that segment and the report request does not contain an optimizable selection test on an inverted list, and CALLTYPE=RL.
SEQFIELD is generally used to suppress Read Physical calls when there is no optimizable selection test on an inverted list. A Read Physical call will be issued if a SEQFIELD is not defined.
The steps the ADABAS Interface and ADABAS perform to complete a Read Logical call without starting values are:
Subsequent retrieval for the entry segment is done by issuing the same Read Logical call with the User Control Block unmodified. The records are returned in ascending value of the inverted list. The ADABAS Interface terminates retrieval when one of the following occurs:
In an ADABAS file that has no record types, you can select the value of SEQFIELD from any inverted list containing entries for all records on the file.
SEQFIELD is required when the ADABAS file has several record types. In this case, the value of SEQFIELD is an inverted list which has entries for a single record type.
If the descriptor used as the SEQFIELD is null-suppressed or contains null-suppressed fields, only records where the descriptor is populated will be included in the retrieval. An entry is not included in the inverted list if a field is null and will not be returned by ADABAS to FOCUS. See your Software AG documentation for more information about null-suppression and how it affects data retrieval.
The ADABAS Interface constructs Read Logical (L3) calls for the root of the accessed subtree when the following conditions exist:
When a report request contains multiple optimizable selection tests, the order of descriptors in the Access File determines the order in which FOCUS applies the selection tests. FOCUS issues a Read Logical (RL) call using the first descriptor listed in the Access File that participates in a selection test.
Therefore, for efficient processing you should describe the most restrictive descriptor at the beginning of its segment in the Access File. The order of descriptors in the Master File has no effect on selection processing.
The steps the ADABAS Interface and ADABAS perform to complete a Read Logical call are:
Subsequent retrieval for the entry segment is done by issuing the same Read Logical call with the User Control Block unmodified. The records are returned in ascending value of the inverted list.
The ADABAS Interface terminates retrieval when one of the following occurs:
If there are multiple values specified in the request (for example, WHERE field EQ value OR value..., WHERE field FROM val1 TO val2 OR val3 TO val4) and RECORDLIMIT or READLIMIT has not been reached, the ADABAS Interface releases the Command ID and reissues the Read Logical call with the next starting value. For each set of values, the ADABAS Interface terminates retrieval when one of the above occurs.
The manipulation of ISN lists is done on the initial call to ADABAS. Both the intermediate lists and the resulting list may be very large and may take up a large percentage of ADABAS workspace. The ADABAS work area is shared by all ADABAS users, and complex FINDs may affect programs that are updating the database. You may want to suppress FINDs altogether. Accomplish this suppression by specifying CALLTYPE=RL on every Access File segment. Ask your ADABAS database administrator whether to use FIND processing.
The ADABAS Interface constructs a simple FIND (S1) call, using a single inverted list structure, for the root of the accessed subtree if one of the following conditions is met:
CALLTYPE=FIND instructs the Interface to generate FIND calls to retrieve records from the inverted lists. This method is the default for processing selection criteria on inverted lists for a segment (if CALLTYPE is omitted from the Access File segment declaration).
A FIND call is always generated when there is a selection test on a field that has been described in the Access File as TYPE=NOP in a retrieval request.
For performance considerations, a FIND (S1) call does not issue a READ ISN (L1) call if an answer set containing only one record is returned. The GET FIRST option returns the first record in the inverted list. This reduces unnecessary I/O calls. If the FIND call returns more than one ISN in a list, the GET NEXT option of L1 is used to start reading the ISN list from the second entry.
The steps performed by the ADABAS Interface and ADABAS to complete a FIND (S1) call are:
All subsequent retrieval for this entry segment is done using the Read ISN (L1) call issued against the ISN list held by ADABAS. L1 commands are issued until one of the following occurs:
The ADABAS Interface constructs complex FIND (S1) calls, using two or more inverted list structures, for the root of the accessed subtree if one of the following conditions is met:
The steps performed by the ADABAS Interface and ADABAS to complete a FIND call on multiple inverted list structures are:
All subsequent retrieval for this entry segment is completed using Read ISN (L1) calls issued against the ISN list held by ADABAS. L1 commands are issued until one of the following occurs:
The ADABAS Interface issues the ADABAS Read Descriptor Value (L9) direct call when you use the FOCUS COUNT verb or SUM CNT.field within a report request. L9 calls are, by definition, limited to descriptors defined to FOCUS with the following:
L9 calls allow an aggregate ISN count to be returned for each unique value on the inverted list at a cost of only one call per unique value. This technique allows a dramatic efficiency gain over passing each record to FOCUS and having FOCUS process the count.
Selection criteria (for example, WHERE descriptor EQ '1234') are passed along with the L9 call to further limit the number of calls. If any non-descriptor fields are mentioned in the TABLE request, a Read Descriptor Value (L9) direct call is not possible and FOCUS uses its own internal count processing. If a BY field is used, it must be the same field or GROUP name used as the object of the COUNT verb.
Here is an example of the SUM CNT.field using EMPFILE1:
TABLE FILE EMPFILE1
SUM CNT.DEPT_S03
BY DEPT_S03
END
| Information Builders |