Communities
A collaborative platform to connect and grow with like-minded Informaticans across the globe
Product Communities
Connect and collaborate with Informatica experts and champions
Discussions
Have a question? Start a Discussion and get immediate answers you are looking for
User Groups
Customer-organized groups that meet online and in-person. Join today to network, share ideas, and get tips on how to get the most out of Informatica
Get Started
Community Guidelines
Knowledge Center
Troubleshooting documents, product guides, how to videos, best practices, and more
Knowledge Base
One-stop self-service portal for solutions, FAQs, Whitepapers, How Tos, Videos, and more
Support TV
Video channel for step-by-step instructions to use our products, best practices, troubleshooting tips, and much more
Documentation
Information library of the latest product documents
Velocity (Best Practices)
Best practices and use cases from the Implementation team
Learn
Rich resources to help you leverage full capabilities of our products
Trainings
Role-based training programs for the best ROI
Certifications
Get certified on Informatica products. Free, Foundation, or Professional
Product Learning Paths
Free and unlimited modules based on your expertise level and journey
Resources
Library of content to help you leverage the best of Informatica products
Tech Tuesdays Webinars
Most popular webinars on product architecture, best practices, and more
Product Availability Matrix
Product Availability Matrix statements of Informatica products
SupportFlash
Monthly support newsletter
Support Documents
Informatica Support Guide and Statements, Quick Start Guides, and Cloud Product Description Schedule
Product Lifecycle
End of Life statements of Informatica products
Ideas
Events
Change Request Tracking
Marketplace
English
  • Identity Resolution 10.5 HotFix 2
  • All Products

Table of Contents

Search

  1. Preface
  2. Introduction
  3. SSA-NAME3 Overview
  4. Introduction for Application Programmers
  5. Appendix A: Glossary

Introduction to SSA-NAME3 (EXTN) Service Groups

Introduction to SSA-NAME3 (EXTN) Service Groups

Back Next

What is the Purpose of SSA-NAME3?

What is the Purpose of SSA-NAME3?

The purpose of using SSA-NAME3 is to find potential matches on a database for exact, incomplete or inaccurate names upon which we are
SEARCHING
. For example, if
Mary Evans Jones
 is stored on the customer database, we want to be able to retrieve her record even if we search on
Mary Evans
,
Maria Jones
,
M. Evens
, or
M E Jones
, to name a few.

How do we Achieve this?

This is accomplished by storing specially formatted 5-byte KEYS (8-byte keys in some implementations) for each customer. Then, for a search name, we locate all keys within a RANGE that is likely to include this search name or a variation of it.
In fact, we usually store MORE THAN ONE KEY –
alternate
 keys – for each customer. For example, for
Mary Evans Jones
, we would include a key not only with
Jones
 as its major component, but also one with
Evans
 as a major word. Then, if an operator searches on the name
Mary Evans
, the search key range produced for
Mary Evans
 will INCLUDE the
Mary Evans
 key we had created for the customer
Mary Evans Jones
.

Where are the SSA-NAME3 Keys Stored and in What Format?

These keys are stored on
ANY TYPE OF INDEXED FILE
 and in
ANY RECORD LAYOUT
. The only requirement is that they are stored somewhere where you can
FIND
 or
LOCATE
 a given key and then
READ NEXT
 until the end of a range of keys is reached.
If you are accustomed to using a relational database, you could define a simple relational table containing the
SSA-NAME3
 key, the customer name from which the
SSA-NAME3
 key was created, and the unique key for this customer record - for example, customer number.
It will become clearer as to why the format of the indexed file is unimportant to SSA-NAME3. But how do you decide, then, exactly how to lay out this file? Here is an EXAMPLE of a typical record layout for what we will refer to as the
SSA-NAME3 KEY FILE
:
SSA-NAME3 Key
Customer Name
Other Identifying Data
Customer No
@#$%ˆ
John Smith
. . .
A12345
(&%$#
John Smith
. . .
A12345
(*#$%
Geoff Brown
. . .
B23671
)(&&%
Geoff Brown
. . .
B23671
With this type of format, there will be
MULTIPLE SSA-NAME3
key records for most customer names - one for each alternate key for this customer. Moreover, the customer name and other identifying data will be
REPEATED
 for each
SSA-NAME3
 key record created. You could also simply store the
SSA-NAME3
 key and the Customer No, however, the above method will provide the best performance when doing name searches and is well worth the extra disk space required. For more information on the subject of database design and performance, see the
How Does a User Determine Which is the Correct Record?
section below, or the
Database Design Notes
section in the
APPLICATION REFERENCE FOR SSA-NAME3 SERVICE GROUPS
 manual.

How are the SSA-NAME3 Keys Created?

You first create a
KEY LOAD
 application program, using COBOL, Visual Basic or whatever development language you are accustomed to using. The program should be linked or have access to the Callable SSA-NAME3 routine using the conventional methods for your environment.
The key load program will
CALL SSA-NAME3
 with each customer name as a parameter passed to it; all SSA-NAME3 keys (i.e., alternate keys) for that customer name will be returned in an array. You then WRITE these keys to the "
SSA-NAME3 Key
" database table (or other indexed file), along with whatever other matching information you have decided to store, and in whatever format you decided upon. As you read on to see more on how SSA-NAME3 is used, you will better be able to decide just what information you want stored on the
SSA-NAME3
Key File.
The following pseudo-code for the key load program (with comments) will help clarify how this works: 

READ NEXT CUSTOMER DATA BASE RECORD UNTIL EOF;
     MOVE CUSTOMER-NAME TO SSA-NAME3-NAME-IN;
     MOVE ’BLDKEY’ TO SSA-NAME3-FUNCTION;
     CALL SSA-NAME3 USING SSA-NAME3-FUNCTION,
                          SSA-NAME3-NAME-IN;
The above Call does not show the exact API requirements – these are described in the
APPLICATION REFERENCE FOR SSA-NAME3 SERVICE GROUPS
 manual.
You now have returned to you a
KEYS-STACK
array with the different alternate keys for this customer. For each key in the array, create a record in the
SSA-NAME3
 Key File. 

DO FOR (ALL KEYS IN KEYS-STACK FOR THIS CUSTOMER-NAME);
   MOVE KEY(N) TO SSA-NAME3-KEY-FILE.SSA-NAME3-KEY;
   MOVE CUSTOMER-NAME TO SSA-NAME3-KEY-FILE.CUST-NAME;
Optionally, move other identifying information. This will be addressed at a later stage. 

    MOVE CUSTOMER-ID TO SSA-NAME3-KEY-FILE.CUST-ID;
    WRITE SSA-NAME3-KEY-FILE RECORD;
END DO;
Note that the only interface the key load application program had with SSA-NAME3 was to send it a name and some other parameters. SSA-NAME3 didn’t care what kind of database this name came from. Also, all that SSA-NAME3 returned essentially was an array of keys. It didn’t care where those keys were stored they could be written to a DB2 or Oracle table, a VAX RMS file, a VSAM KSDS, or any other type of indexed data base or file system.
What we have at the conclusion of the load program is a file indexed on
SSA-NAME3
 key.

How are the SSA-NAME3 Keys Used for Searching?

The initial loading of the
SSA-NAME3
 keys is a one-time operation. Of course, in a production environment, whenever new customers are added to the database, or names changed, new
SSA-NAME3
 keys must be generated for these - this is normally done as part of the maintenance transactions.
Once the
SSA-NAME3
 Key file has been created you can use it from within an application program that performs the
SEARCH
 function. Let’s assume that the search program is an on-line program, although the concepts apply as well to batch programs.
The following pseudo-code will help describe how this search program works: 

GET CUST-SEARCH-NAME FROM SCREEN;
MOVE CUST-SEARCH-NAME TO SSA-NAME3-NAME-IN;
MOVE ’POSSRCH’ TO SSA-NAME3-FUNCTION;
CALL SSA-NAME3 USING SSA-NAME3-FUNCTION,
                     SSA-NAME3-NAME-IN;
The above Call does not show the exact API requirements – these are described in the
APPLICATION REFERENCE FOR SSA-NAME3 SERVICE GROUPS
 manual.
The example
POSSRCH
 function will return an array of
SEARCH KEY RANGES
. It is these
SEARCH
 ranges that we are now interested in, rather than the storage keys.
The positive search ranges in this example go from narrow (only the closest matches to search record returned) to wider than would ever actually be used in practice. The choice of which search range(s) to use is a discussion in itself, and should be discussed more thoroughly with an SSA technical support person. Let’s assume we’re using the narrowest range (the first one in the search table array).
To continue with the code: 

FIND SSA-NAME3-KEY-FILE.SSA-NAME3-KEY >= START-SEARCH-KEY
DO WHILE (SSA-NAME3-KEY-FILE.SSA-NAME3-KEY <= END-SEARCH-KEY);
   MOVE SSA-NAME3-KEY-FILE.CUST-NAME TO DISPLAY SCREEN;
   MOVE SSA-NAME3-KEY-FILE.CUST-ID TO DISPLAY SCREEN;
   READ NEXT SSA-NAME3-KEY-FILE RECORD;
END DO;

What are the Results of the Search?

After performing the above search you will have on the screen a list of customer names whose
SSANAME3
 keys fall within the search range just referenced.
Now your application program may provide a facility for the operator to select one of these names and retrieve the actual
CUSTOMER DATA BASE
 record to which a certain
SSA-NAME3 KEY FILE
 record points.
For example, if the customer search name was
Mary Evans Jones
, the list displayed may contain: 

         Name        Customer No
         Mary Jones  1236
         Mary Evans  9812
         M.Jones     7745
         M.E.Jones   2176
         M.Evans     3737
         Evan Marie  9508

How Does a User Determine Which Is the Correct Record?

Displaying the name alone will most likely not be enough to tell the user which customer is the correct one other identifying information will be required. The operator could go and display the customer master record for each name, but this is not the most efficient way.
This brings us back to one of the first questions - what data do we store on the
SSA-NAME3
Key File? In the key load example described above we stored the customer name and customer id along with each
SSA-NAME3
key created. This customer name is what is displayed on the screen list of names.
For efficiency, we also recommend storing additional identifying information with each key on the
SSA-NAME3
 key file. For example, you may want to store date of birth and street address if this what the users would commonly use to confirm a match. Now, when you display the records retrieved from the
SSA-NAME3
 Key File for a given search range, you will see not only the customer name but this additional information as well making the choice easier.
The reason for storing the other identifying data in the same table as the
SSA-NAME3
 name keys is that the application or DBMS does then not need to join multiple tables to retrieve that data, and this leads to a saving in I/O. Equally as important for performance is that the table must be ordered physically by the
SSA-NAME3
 name key this means that records with similar names are stored physically close to each other in the table and the DBMS will need less I/O to retrieve those records.
0 COMMENTS
We’d like to hear from you!