Selection Considerations

The ADABAS Interface analyzes all selection criteria that apply to a specific report request and uses the criteria to minimize its search for data. If a record fails any of the selection tests, FOCUS does not attempt to retrieve any descendant records. Retrieval continues with the next record in the parent segment. If there is no other record in that parent segment and it is not the root of the Master File, FOCUS moves back up to the next record in the previous segment.

The selection tests that you impose on a high-level segment are much more efficient at reducing I/O operations than criteria imposed on lower level segments. If you know in advance which selection criteria are likely to be used most frequently, design the Master File to take advantage of the hierarchical structure in the ADABAS Interface.

Selection Order in the Access File

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.

RECORDLIMIT and READLIMIT

For any request, you may limit the number of ADABAS records retrieved from the database and the number of FOCUS read operations performed. Use the RECORDLIMIT and READLIMIT keywords to impose these limitations by adding the following conditions to a report request

{WHERE|IF} RECORDLIMIT {EQ|IS} n
{WHERE|IF} READLIMIT {EQ|IS} n

where:

n

Is the number of records or read operations at which you want to limit the search.

You add these conditions to any report request, or incorporate them into file security through the FOCUS DBA facility. See the FOCUS for IBM Mainframe User's Manual for more information on the preceding FOCUS commands and keywords.

Consider the following example

TABLE FILE VEHICLES
PRINT PERSONNEL_ID MAKE MODEL YEAR
WHERE RECORDLIMIT EQ 5
END

which produces this report:

    PAGE      1

    PERSONNEL_ID   MAKE             MODEL                YEAR
    ------------   ----             -----                ----
    11500330       CITROEN          BX LEADER              85
    11400313       ALFA ROMEO       SPRINT GRAND PRIX      84
    30034217       AUSTIN           MINI                   80
    30034228       TALBOT           SOLARA                 83
    30008427       AUSTIN           MINI                   80

Notice that only five records are reported as requested.

Optimization of the FIND Call Using Non-descriptor Fields

It is possible to use non-descriptor fields as search criteria and have the calls to ADABAS use the search buffer rather than read through the entire database.

The ADABAS Interface provides improved optimization by allowing the search buffer to be generated using non-descriptor fields. This optimization occurs whenever CALLTYPE=FIND is specified in the Access File and you include an IF or WHERE test referencing a non-descriptor field in your report request.

It may prove to be more efficient to alter your retrieval strategy and perform a Read Physical (L2) call when large amounts of data exist. A SET command is provided for changing the default ADABAS call when selecting non-descriptor fields.

The syntax is

{MVS|CMS} ADBSINX SET NDFIND {ON|OFF}

where:

MVS

Indicates the MVS operating system.

CMS

Indicates the CMS operating system.

ON

Causes the search buffer to be generated with any field (non-descriptor and/or descriptor field). This value is the default.

OFF

Causes the search buffer to be generated with only descriptor fields. If the request does not use any descriptor field, the Read Physical call is generated.

This command only applies if CALLTYPE=FIND is specified in the Access File.