Positive Search-table
The Positive Search-table, or Cascade, consists of progressively widening search ranges. A positive Search-table is always returned unless the
NAMESET
Functions
NEG
is specified.
Every range in a Positive Search-table is built from the name in the ’Preferred Key’ word order and each successive range will use less of the input name (e.g. a three word name is entered range 1 uses three words (WWW); range 2 uses two words and an initial (WWI); range 3 uses two words (WW)). The difference between the Preferred key and the first range of a Positive Search-table is that the latter can find names with the words in any order, provided that Positive or Negative keys have been stored, as well as names with additional words.
When probes (
NAMESET
Functions: 1WORD, 2WORD, NWORD,
SSA-NAME3-OPTIONS #6 = C
– Code Probe) or special search ranges (
NAMESET
Functions:
CUSTOMSET
and
SECONDARY
) are also requested, these are returned at the start of the Search-table, before the cascade ranges. Secondary ranges use the same
START=
value as the positive search table. Custom ranges tend to be, but are not always, narrower search ranges than the first positive range this is determined by the person that defined the Customset definitions. For information on how to process such probes and ranges, prior to processing the Positive Search-table, see the
On-line Positive Search and Batch Positive Search
sections below.
Inclusive Search Range Processing
The Positive search ranges are also referred to as ’inclusive sets’, because each successive range includes the ranges prior to it in the Search-table. Following is a Positive Search-table example for 5-byte binary keys showing how the Start-keys progressively get lower and the End-keys progressively get higher.
PREFERRED-KEY: F19EBB4000
Start-key End-key
POS RANGE 1: F19EBB4000 F19EBB7FFF 40 00 30 G4 C 00 WWW*
POS RANGE 2: F19EBAC000 F19EBD7FFF 55 00 21 F3 C 00 WWI*
POS RANGE 3: F19E800000 F19EBFFFFF 60 13 20 F4 C 00 WW*
POS RANGE 4: F19D800000 F1A03FFFFF 75 16 11 D5 C 00 WI*
POS RANGE 5: F180000000 F1BFFFFFFF 80 28 10 D6 C 00 W*
POS RANGE 6: F080000000 F43FFFFFFF 95 35 01 A8 C 00 I*
END OF TABLE: 0000000000 FFFFFFFFFF 00 49 00 A9 C 00 *
To find the records identified by Search-range 1, the following example SQL could be used.
The key values would not normally be hard-coded in the SQL statement, this is done for demonstration purposes.
SELECT * FROM CUSTOMER-SSA-NAME3-TABLE
WHERE SSA-NAME3-KEY >= ’F19EBB4000’
AND SSA-NAME3-KEY <= ’F19EBB7FFF’
and, to find the records identified by Search-range 2, when prompted:
SELECT * FROM CUSTOMER-SSA-NAME3-TABLE
WHERE SSA-NAME3-KEY >= ’F19EBAC000’
AND SSA-NAME3-KEY <= ’F19EBD7FFF’
Exclusive Search Range Processing
Avoiding the re-reading of previously read records has obvious performance advantages. This is known as ’exclusive’ set processing, as processing each successive search range excludes the records from the ranges before it. Exclusive set processing is only appropriate if:
when processing a search range, the records found in previous search ranges are no longer required (e.g. the user does not want to see them on the screen); or
the search application uses a program array to hold the found records from each range.
The following example SQL shows how to process the first two ranges of the above Search-table as ’exclusive’ sets:
To find the records identified by Search-range 1:
SELECT * FROM CUSTOMER-SSA-NAME3-TABLE
WHERE SSA-NAME3-KEY >= ’F19EBB4000’
AND SSA-NAME3-KEY <= ’F19EBB7FFF’
To find the records identified by Search-range 2, when prompted, requires breaking that range into two distinct ranges. The first range starts at the Start-key for Range 2 and ends at Start-key for Range 1. The second range starts at the End-key for Range 1 and ends at the End-key for Range 2. This is shown by the following example:
SELECT * FROM CUSTOMER-SSA-NAME3-TABLE
WHERE SSA-NAME3-KEY >= ’F19EBAC000’
AND SSA-NAME3-KEY <= ’F19EBB4000’
SELECT * FROM CUSTOMER-SSA-NAME3-TABLE
WHERE SSA-NAME3-KEY >= ’F19EBB7FFF’
AND SSA-NAME3-KEY <= ’F19EBD7FFF’
How Much of the Search-table to Process
As can be seen in the Search-table example in ’Inclusive Search Range Processing’ above, the widest search range generated is the one based on the first character of the major word. This search range is mainly included for the sake of completeness and, in all but the rarest of applications, would never be used.
So how wide should an application search? At what search level or search range should it stop? The answer is that it should stop when the search range about to be processed is considered too wide, either from a performance or a quality point of view.
The meaning of ’too wide’ will differ from environment to environment, however, the means by which the width is measured is the same. The width (or depth) of a search can be measured by checking either the ’Scale’ or ’Contents’ fields in the Search-table entry. For example, a Scale of greater than ’23’ (approximately 200 records), or a Contents less than ’11’ (one word & one initial) may be considered too wide. How wide a Positive Search-table goes can also be controlled by the NAMESET
STOP=
Function.
For example, a value of
STOP=WI
would be the same as the application stopping when the Contents was less than ’11’.
On-line Positive Search
When an on-line search application requests a Positive Search-table, the typical approach is to process one search range at a time and display the results of that search range back to the user. The user should be given the option to ’widen the search’. If a widen search request is received, the application would then process the next search range in the Search-table returning the results from that range to the user.
If probes are requested (1WORD, 2WORD, NWORD) these should be processed in the same way as a normal Positive search range. In other words, process the probe range and return the results to the user, waiting for a prompt from the user before processing the next probe/range. These probes have a Set-id of ’C’ for this reason.
Other probes or ranges which can precede a positive search table and which may need to be processed differently, have a different Set-id. Customset probes/ranges have a Set-id of ’P’, Secondary Name ranges have a Set-id of ’2’, and Code Probes have a Set-id of ’S’. Normal processing would be to process each complete Set-id as one ’logical’ range. For example, if there are three entries at the top of the Search-table with a Set-id of 'P', process all three entries before returning to the user with the results. If the user chooses to widen the search, proceed then with the next range.
Following is an example Positive Search-table with Customset ranges:
PREFERRED-KEY: F19EBB4000
Start-key End-key
CUSTOM PROBE 1: F19E800000 F19EBFFFFF 60 13 20 F4 P 00 WW!
CUSTOM PROBE 2: F1A0000000 F1A0000003 55 00 20 D3 P 00 WI!
CUSTOM PROBE 3: F180000000 F180000003 80 28 10 D6 P 00 W!
POS RANGE 1: F19E800000 F19EBFFFFF 60 13 20 F4 C 01 WW*
POS RANGE 2: F19D800000 F1A03FFFFF 75 16 11 D5 C 01 WI*
POS RANGE 3: F180000000 F1BFFFFFFF 80 28 10 D6 C 01 W*
POS RANGE 4: F080000000 F43FFFFFFF 95 35 01 A8 C 01 I*
END OF TABLE: 0000000000 FFFFFFFFFF 00 49 00 A9 C 01 *
Batch Positive Search
Using a positive Search-table in batch is different than on-line because there is no one to show the results of an individual search to and no one who can direct the program to widen the search.
For the sake of good performance, such a batch process should either, process only one selected search range from the table, or process the ranges as ’exclusive sets’ stopping at a pre-determined depth.
Processing only one search range requires either the use of the
START=
and
STOP=
Function keywords, or requires the program to search through the Search-table looking for the required Contents or Scale value.
Processing the ranges as exclusive sets stopping at a pre-determined depth requires use of the
STOP=
Function keyword, or for the program to check the Contents or Scale values of each range it is about to process. This might be an approach used if the intent was to stop the search as soon as the first ’match’ was found.
There is normally no sense in requesting the 1WORD, 2WORD or NWORD probes for batch positive searches, as the records found would be found again in the first search range. The only exception to this would be if the intention of the application was to find only the first record that matched, and to return quickly.
Special search probes or ranges, i.e. Customset and/or Secondary ranges, definitely have a place in batch positive searches. If specified these would normally be processed in their entirety before proceeding to the Positive Search-table.
