In applications where a match is expected, use a Positive Search strategy and always search with the most complete name data available, even if the words are suspect. If a match is not found the search can progress to lower levels.

Understand that an approach which involves sorting the candidate records or processing many records before displaying a few can adversely effect response time. The compromise is, however, that such an approach often improves the effectiveness of the search and decreases the network load.

Use a search strategy which does not involve re-reading previously read records (e.g. use an ’exclusive’ positive search strategy rather than ’inclusive’ one see the

Exclusive Search Range Processing

section).

Ensure that the search is not operating at a wider level than it needs to go for the match requirements. For example, if the batch run is looking only for definite matches then use a narrower search strategy than would be used for suspect matches.

Match and sort the candidates in order of their likeness to the search data, before displaying the results. This is called ’Ranking’ and often saves the user from the need to page through multiple screens.

Decrease the number of screens needed to make the choice by removing headings and redundant data. This may be worth some smart screen layout to handle the great variability in name and address field lengths. A fixed field approach often wastes space and can actually make the screen difficult to read. Likewise, using two lines per candidate record increases the number of screens required to present search results.

SSA-NAME3 is compute-only at run-time and is fully re-entrant. In a multi-user environment try to use only one copy per address-space.