 |
|

 |
1· |
What are the basic options included with CLEAN_Address? |
| |
The basic CLEAN_Address product includes address, name, telephone, and email verification and/or parsing. This is for the Windows product, which can support any Oracle database on any platform. The CLEAN_Address architecture contains a daemon process which can run on any server and support multiple Oracle databases (on any platform) from one install.
|
 |
2· |
What is the GeoCoder option? |
| |
The GeoCoder option returns the Latitude and Longitude combination accurate to the ZIP + 4® level (about the center of a city block). It also returns the Census Tract and Block. There is a procedure in the CLEAN_Address package for calculating the distance and direction given any 2 Lat/Long coordinate pairs.
|
 |
3· |
What is DPV™? |
| |
The DPV™ Product option from the USPS® (Delivery Point Validation) adds the highest level of validation available, going down to the house number and suite/apartment number level. This will also identify missing or invalid suite or apartment numbers.
|
 |
4· |
What is LACSLink™? |
| |
The LACSLink™ data is included with the DPV™ (Delivery Point Validation) subscription. It essentially remaps addresses that have undergone some sort of conversion from the USPS®. A common example of this is older rural route addresses being mapped to physical street addresses so emergency personnel can locate the address easier. LACSLink™ is also used to remap house numbers on streets
when a major metropolitan area grows to include outlying areas that may have the same street name and number.
|
 |
5· |
What is the average rate of correction when batch processing records? |
| |
The processing rate depends on the CPU speed, memory, and validation options installed - Basic US Validation, DPV™ (Delivery Point Validation), GeoCoder, Name, Telephone processing. Also, passing in the records in pre-sorted order (state or postal code) will improve validation rates. You can expect to see up to 3 million records/hr for basic validation on a decent machine.
|
 |

|
 |
1· |
What do I need on my system in order to install CLEAN_Address? |
| |
see Platform Requirements
|
 |
2· |
How much space does CLEAN_Address require in an Oracle Database? |
| |
The general answer to how much space is used in Oracle is:
Very minimal, since the data files don't reside within Oracle, but on the file system.
* The Oracle Database only holds the lookup tables and PL/SQL procedures, plus the postal codes table, which contains about 70K records for all city, state, zip combinations. Altogether this is about 50MB in Oracle.
* The data files for the Basic USPS® product are about 500MB, plus any options like DPV™ (900MB), GeoCoder (500MB), Canada (450MB), Rest of World (up to 3GB depending on countries).
|
 |
3· |
Can more than 1 database talk to a single installation of Clean_Address? The CLNADDRD.INI File requires database connection info, which implies that it can only connect to 1 database at a time. Does this mean that each database would need its own installation of Clean Address? |
| |
You can configure multiple INI files (clnaddr_dev.ini, clnaddr_prod.ini, etc) and invoke the CLEAN_Address daemon to read the respective file by passing the INI filename as the first parameter:
>>> clnaddrd.exe clnaddr_dev.ini
>>> clnaddrd.exe clnaddr_prod.ini
Note: This is also supported if the daemon is run through a Windows Service
|
 |

|
|
|
 |
1· |
Is there a way to run the CLEAN_Address() daemon as a service? |
| |
Yes, the daemon can be configured to run as a Windows service. First, modify the install_win_service.bat script in your CLEAN_Address() BIN directory (i.e. C:\CLEAN_Address\bin\install_win_service.bat) to map to your local install directory. Second, run the install_win_service.bat script to install and start the services.
Detailed instructions are included as a "readme.txt" file under your CLEAN_Address() installation directory.
Note: Services are specific to Windows. On a Unix platform the daemons may be started up within a minute after being shut down. This is done by the "cron" utility, which can be configured to run the script for restarting the daemons (at desired time intervals).
|
 |
2· |
What is the best way to use the daemon for more than one database (i.e. production and development)? Should we use another directory and service, or is there a way to modify the ini files to allow for two databases? |
| |
Copy the clnaddrd.ini file to another name, i.e.:
clnaddrd.ini to clnaddrd_DEV.ini
Reference this name as the first parameter in the clnaddrd.exe call.
i.e. clnaddrd.exe clnaddrd_DEV.ini will use this .ini file
Without the parameter it will look for clnaddrd.ini as a default.
The parameters should work fine in the Windows service as well.
|
 |
3· |
Does running the Daemon as a service create multiple daemons automatically? |
| |
The Daemon may run as either a program launched at startup or as a Service. The recommendation if running from a startup folder is to have multiple instances of the CLNADDRD.EXE program running on the machine to allow for batch jobs and max # of concurrent users.
You would need an additional service for every connection, so if you want to support DEV and PROD and have 2 daemons each, you would need to configure 4 services:
- CLEAN_Address Dev 1
- CLEAN_Address Dev 2
- CLEAN_Address Prod 1
- CLEAN_Address Prod 2
|
 |
4· |
Is there a calculation to determine how many daemons are needed based on batch jobs and concurrent users? |
| |
The number of daemons you'll need will depend on the number of addresses you need to process concurrently. An individual address is processed in sub-second response time, and addresses are processed in a FIFO queue fashion (First-In First-Out). So even if a batch job is running for 300K addresses, it will only have one address in the queue at a time since it would be a synchronous transaction, and a user request would still get processed.
>>> Some addresses for certain cities may take longer to process than others, based on the data supplied by the user and the number of USPS® addresses in a postal code. If more algorithms are required to correct an invalid address for these larger cities, it may take up to a second to process. (i.e. Some New York City blocks have a larger percentage of addresses per postal code)
>>> Overall, we've seen throughput as high as 700K addresses per hour for the daemon.
>>> For these reasons, we recommend at least 2 daemons per instance for concurrency.
Note: There is a high limit timeout that you can define for how long a process should wait for a response from the daemon, default 10 seconds, so even if there is a high concurrency rate at a point in time, this is more than sufficient time to process all requests.
|
 |
5· |
What are the minimum system requirements to run the Daemon? |
| |
There are very minimal system
requirements for the CLEAN_Address daemon. The hard drive space would be about 2GB for the US and the rest of the world.
|
 |

|
|
|

|
 |
1· |
Regarding the Tables installed in Oracle, are these only updated with each bi-monthly subscription CD, or do they get updated as Clean_Address is being used? |
| |
The only table in Oracle that contains postal data is the CLN_POSTAL_CODES table, which lists all zip, city, state, county combinations (no address data). This is used for showing a dropdown list to the user if they enter a postal code with multiple cities that they can select from. This table would have about 70K postal code records for the US.
>>> This table can be updated with the CLEANZIP.exe program, which does any insert/update/deletes to get it in sync with the latest bi-monthly CD.
>>> This is *not* required for the daemon processing, and can even be truncated if not used in your application. Think of this as a lookup table.
>>> The CLEAN_Address daemon does not write any data to the Oracle tables.
|
 |
|
|
|
|
|
|
|