Check that the response code parameter is in the correct position in the parameter list.

For SSA-NAME3 Services that use the 2-byte error number in the parameter list, check the full 20-byte response code at offset 42 into the Work-area parameter.

Check that the Application is using the same version of the Service Group, the same Service Name and the same Function Code or Definition.

Check that the name being keyed is exactly the same.

Check that the parameter lengths for the SSA-NAME3 Call in the application match the definitions in this manual and the user defined lengths in the Algorithm Definition, particularly that the Name length is the same as specified in the Algorithm definition.

To ensure that the Application is using the same version of the Service Group as the Test-bed, add a Call to the

INFO

Service to dump the Service Group Signature (

INFO

table

USGSIG

). Run the same

INFO

Call in the Test-bed and compare the two signatures.

When Customization & Generation is performed on Windows, and the application is running on a target computer, check that the results of the Test-bed on Windows match the results of the Test-bed on the target.

Check that the Application is using the same version of the Service Group & Matching Scheme definitions.

Check that the records being matched are the same in the Application as in Testbed, particularly that you are using the correct lengths and offsets.

Check that the parameter lengths for the SSA-NAME3 Call are correct.

If there are any Pre-cleaning rules in the Edit List (

*S/*W

) which only apply to one case (either lower or upper), check that the correct case is being used in both the application and Test-bed.

To ensure the Application is using the same version of the Matching Schemes as the Test-bed, add a Call to the

INFO

Service to dump the Service Group Signature (

INFO

table

SCSIG

). Run the same

INFO

Call in the Test-bed and compare the two signatures.

Check that the same Score is being produced from Test-bed.

Check that the field offsets and lengths for the two records are exactly the same as defined in the Matching Scheme.

Check the

METHODS-TABLE

in the Test-bed output to determine which Method is returning the unreasonable Score.

Check the

METHOD

in the Scheme Definition has valid Options selected.

Ensure that the name is in the database.

Ensure that the application is pointing to the correct file in the correct database.

Is the name being found, but the Matching process is filtering it out? To check, temporarily disable the

MATCH Call

. If the Score is too low, there may be a problem with the

MATCH Call

parameters, or the Matching Scheme may need tuning.

Display or print the keys that are stored for that name on the database and check that these keys match the keys generated by Test-bed for the same name (Note: when using 5-byte binary keys your application will need to display them using a 10-byte hex edit mask or routine).

Display or print the search key ranges generated by SSA-NAME3 for your application and check that they match the search ranges generated by Test-bed for the same name.

If either of the previous two checks fail, make sure the Test-bed is using the same Service Group, Service Name and Function definition as the application. If these are the same, make sure that the name being passed to SSA-NAME3 is the same as provided to Test-bed, and that the name length in the application is the same as in the Algorithm.

Check that at least one of the search key ranges generated by SSA-NAME3 includes at least one of the keys stored on the database for that name (i.e. that the database key is greater than or equal to the search range start key and less than or equal to the search range end key). If not, the search name may be too different from the database name for this SSA-NAME3 Search Strategy to pick it up and another Strategy may be required. If one of the search ranges does include the database key, check the application is indeed processing that search range. If it is, check the application code and database access statement.

Check that the operating system or network are not causing the problem by testing some non-SSA-NAME3 programs or functions.

Typically, the fewer words used in the Search name, the longer the search will take, especially for common names. Obviously a search on a name like

SMITH

or

TAN

alone will potentially take a while.

Ensure that a proper Frequency Table was built for the Algorithm being used.

Check that the Application is not processing all levels of a Positive Search-table.

Check that the Application is not processing the search range which has a depth of ’00’.

Check if the Application is processing a search range which has a Contents of less than ’11’.

Ensure that the SSA-NAME3 key is properly indexed and the database is not simply doing a table scan to satisfy the search.

Check on how many files are being accessed to build the search results. The more table joins occurring, generally the longer the response time. Ideally, the SSA-NAME3 key and other identifying data should all be stored in the one file or table (see the Database Design Notes section for further details).

Check the lengths and positions of the parameters on the SSA-NAME3 Call match the definitions in the Algorithm being used.

The Work-area parameter may not be large enough. Simulate the Call using the Test-bed and check the

WSIZE

value - the Work-area should be at least this large.

When a change is made to an Algorithm, Edit-list or Matching Scheme, a strict sequence of Generation jobs must be run to re-build the Service Group. If Generation is done on Windows, the Service Group Data File must be transferred to the target computer. Ensure the correct sequence of steps has been carried out by referring to the

GENERATION and TESTING GUIDE FOR SSA-NAME3 SERVICE GROUPS

.

Run the Test-bed on Windows to see if the change has taken effect there.

Run the Test-bed on the target computer to see if the change has taken effect there.

If the application statically links the Service Group, ensure that link has been done.

If the application dynamically loads the Service Group, ensure the dynamically loadable Service Group has been copied to the correct environment for the application to load it and there is not a ’rogue’ copy lying around for it to pick-up.

Some changes to an Algorithm or Edit-list require that the database keys need to be re-built. Check if this is the case and that the keys have indeed been re-built.

Ensure the application is pointing to the correct database and file.