Jump to navigation Jump to search
How To Set Your License String?
- Currently, MDADDR_SERVERMODE only has one value, “sticky”. Sticky is an option that can be set to change the way Address Object behaves when many instances are created and destroyed. This variable, turned off by default, will enable Address Object to retain some of the data files used for initialization in memory after the last instance of Address Object is de-allocated, but before the application ends. This may be useful for applications that use multiple instances (For example: Web services that use individual threads for each client) and have times where the number of instances drop to 0 while the application is still running. Using this variable should increase the speed of initialization for those qualifying applications. To set the sticky variable, follow these steps:
- For Unix (Linux and Solaris), add these lines to .cshrc or .profile of the login account that is running Address Object:
csh, tcsh: setenv MDADDR_SERVERMODE sticky bash, sh, ksh: MDADDR_SERVERMODE=sticky export MDADDR_SERVERMODE
- For Windows, add the following entry to your system environment variables:
Variable Name: MDADDR_SERVERMODE Value: sticky
- Then restart the application using Address Object.
How do I use checksums to validate the integrity of my files?
- Checksums are codes generated from files that can be used to check the integrity of a file. If two files have the same checksum, they can be assumed to be the same file. At Melissa Data, we use a md5 checksum utility (http://www.fourmilab.ch/md5/). If our tech support asks for your checksum, you can download the command line utility at the URL above. Then, after unzipping it, navigate to md5.exe from the command line, and type md5 “filename” for the checksum. We will then compare your checksum to ours to see if any corruption has occurred.
What is in my DQ Suite DVD?
- Here is a general overview of the structure and contents of the DQ Suite DVD:
- setup.exe [For Windows install]
- setup.sh [For Linux/Solaris install]
- changes.txt [Text file containing latest changes and updates]
- qstart.pdf [PDF file containing descriptions of the Objects, Install guides, Implementation guides, and other important information]
- Included Data Quality Objects Folders
- The Included Data Quality Objects folders are separated into the different Objects included in your DQ Suite DVD: Address Object, Email Object, Name Object and Phone Object.
- Each folder contains a PDF manual explaining the Objects’ methods, properties and initialization procedures.
- Data Files Folder
- Each Included Data Quality Objects directory contains a Data Files folder which contains necessary files to run the Object.
- For Address Object, the Data Files directory contains necessary data files as well as folders to the different Add-ons (DPV, LACSLink, SuiteLink, AddressPlus, RBDI and mdCanada).
- Operating System Folders
- Each Included Data Quality Tool directory contains folders for different Operating Systems: Windows, Linux, AIX, and Solaris.
- Sample Codes, Technologies (For Windows) and Libraries Folders
- Located within each Operating System Directory are folders for interfaces, samples, technologies and libraries.
- The interfaces and samples folders contain sample codes for different types of languages. Interface samples include wrappers for their respective languages.
- Readme files are included for step by step instructions on how to run sample codes.
- The Windows directory contains folders for COM and DLL technologies. The COM and DLL files are needed in order for the windows sample codes to run.
- All other Operating Systems contain Library folders for specific compilers such as GCC. These libraries are needed in order for the sample codes to run.
- This folder contains an Adobe Reader 9 installer for viewing PDF files, barcode fonts used for presorting, and other generic libraries used by Windows.
- The extras folder also contains a dashboard that provides you a more detailed overview of the Data quality suite.
- New scripts for automating the download and update procedure for Address, Name, Phone, Email, and Geocoder objects are now located in the extras directory.
How do I automate the DQ Suite setup?
- For Windows
- The Windows Setup program for Data Quality Tools accepts optional command line parameters. These can be useful to system administrators and to other programs calling the Setup program wishing to automate the entire process without clicking on the dialogs.
- Run the Setup on a test machine like so:
D:\\setup.exe /SAVEINF="c:\\setup.inf" - This can be any file name you wish.
- This instructs Setup to save installation settings to the specified file.
Now for any number of other machines, setup can run off the created INF file to run an identical setup on each individual machine.
D:\\setup /LOADINF="c:\\Scripts\\setup.inf" /SILENT /SUPPRESSMSGBOXES
- This instructs Setup to load the settings from the specified file after having checked the command line. This file can be prepared using the '/SAVEINF=' command as explained above.
- Acrobat Reader must already be installed on the client machine for a truly silent install.
- Note: Please remember to use quotes if the filename contains any spaces.
- For Unix
- The unix installer can take flags to set all the options of a install in one line. To customize an install, run the installer once through interactive mode and customize it the way you like. Then, copy the command line options that the install will provide you to replicate the install on other machines.
What do I need to do when installing the DQ Suite DVD?
- When you install the DQ Suite DVD, please pay attention to changes.txt on the root of the DVD. It will contain any changes that have been made to any of the objects which may require you to rewrite/recompile your application. Also, when using the wrappers in the Interfaces folder, please read the readmes for each wrapper you are using as they may contain changes to the build process you have to make.
What is multi-threaded programming, with respect to MelissaDATA’s data quality tools?
- When working with MelissaDATA API components, you are multi-threading in these situations:
- You have several threads, each creating an instance of an object.
- You have several threads, all using a single (or a few) instances of an object.
- Be aware that sometimes you are multi-threading without even realizing it. This is particularly true for web applications. For example, a web service will often handle multiple requests simultaneously. Each request will be handled on a separate thread, though the code you have written to handle a request is oblivious to this.
- What should be my primary concerns?
- Primarily, the thread that creates an instance to an object ‘owns’ that instance and any other threads should not use that instance.
- If you choose to violate this rule and ‘share’ instances across threads, your program must ensure that a thread is completely done using the instance before another thread attempts to use it. Often, this is done through the use of critical sections, mutexes or semaphores.
- Bear in mind that it is very difficult to debug multi-threaded applications, and the precautions needed to share instances further complicate the issue.
- The more practical solution is to ensure that each thread owns its own instance. However, when working with large numbers of threads, this can be problematic, as operating system limitations (open threads, file handles, memory, etc) can be a limiting factor.
- Why is threading an issue?
- At any given moment, an instance exists at a certain state. Two threads calling the same instance will usually cause the instance to change states in unexpected ways, leading to incorrect results and/or crashes.
- For example, say thread 1 calls the Address Object (AO) with an address. The AO at this point is in ‘State A’. Then, before thread 1 can obtain the AO’s results, thread 2 calls the AO with a different address, putting it into ‘State B’. When thread 1 retrieves its results, it will retrieve the ‘State B’ results rather than the correct ‘State A’ results.
- Can MelissaDATA’s API components detect improper thread usage and handle the situation accordingly?
- No, they cannot. It is not a fault of the programming, but rather is inherent to the way microprocessors and operating systems are designed and used.
- If I’m using a single-core/single-CPU machine, I don’t have to worry about threading issues, right?
- Wrong. The synchronization issue discussed in question 2 can happen even if the threading is not exactly simultaneous.