---

Note: You must have a UNIX account on every server you want to access.

---

The DataMover creates files on the server machine on behalf of each user. The DataMover configuration file, .datamove, lets you control where these files are created and whether different classes of files are saved or discarded. This file is located on the server, in your home directory. A sample .datamove file called datamove.sample is located on the server, in the /usr/lib/MineSet/datamove directory.

If the .datamove file is absent, or if a particular entry is not present in the .datamove file, the DataMover uses a default value for that entry.

Each entry in the DataMover's configuration file must be on a separate line. For example:

file_cache = directory_name

where file_cache specifies the location in which the DataMover stores its output data files and models resulting from mining algorithms. If the file_cache directory does not exist, the DataMover attempts to create it on its first invocation. The default file_cache directory is ./mineset_files/%U. The %U is a wildcard that is filled in with the user's login name on the client machine. This is useful in reducing contention if many users want to log in to a common account on the server. If multiple sessions were simultaneously connected to the same file_cache directory, they could overwrite each other's server files, causing incorrect and unexpected results. To prevent this, DataMover maintains a lock at the file_cache directory level. The second and later attempts to connect to a particular file_cache directory result in failure and an error message. The user can recover from such a failure by killing one of the DataMover's attempts to connect to a given file in the cache directory.

The file_cache should be a directory in a file system with sufficient room to hold all of a user's output and temporary files. DataMover will create this directory if it doesn't already exist. These are deleted when the DataMover no longer needs them, unless one of the following keep options is set:

keep_client_upload
keep_client_download
keep_classifier_files
keep_classifier_options_files
keep_mlc_input
use_ascii_mlc_input

Each of these entries is described below.

keep_client_upload (default no)

Keep files uploaded from the client for processing. If kept, they will be in the client_upload subdirectory.

keep_client_download (default no)

Retain on the server a copy of data files and visualizations after they are downloaded to the client. If kept, the files will be in the client_download subdirectory.

keep_classifier_files (default yes)

Keep the persistent classifiers (decision trees and so forth) generated by mining operations. The tactic is generally useful.

keep_classifier_options_files (default no)

Keep the options file that is used when generating, or inducing the classifier. This tactic is not useful. If kept, the files will be in the mlc_work subdirectory.

keep_mlc_input (default no)

Keep input files used for mining (MIndUtil or associations) operations. If kept, the files will be in the mlc_work subdirectory.

use_ascii_mlc_input (default no)

Normally the DataMover creates MineSet binary files for MIndUtil input. If this option is set, create ascii files instead.

aggregation_memory_limit (default 2147483647)

Memory limit (in bytes) for aggregation operations. This can be no larger than the system-wide limit set in the dm_config file.

optimize_history=yes

The DataMover is able to rewrite histories to remove redundant computations. The optimize_history parameter controls whether or not to do this. Since this rewriting can speed up processing considerably, it is normally turned on.

A file in the file_cache directory is the result of a successful operation. If an operation returns an error (that is, Tool Manager reports a message beginning “fatal error on server,”) nothing should be changed in the file_cache directory. Two examples help illustrate the point:

If you are using relational databases, the MineSet DataMover server must be configured to find information in the databases. The DataMover works with Oracle^® versions 7.2 or later, INFORMIX^®, and Sybase^®.

The DataMover server reads the /usr/lib/MineSet/datamove/dm_config file during start up. This file is not created by Inst during installation. It must be created by the system administrator, who must log in as root to edit this file. It can be created via an editor such as jot, vi, or Emacs. An example file can be found in /usr/lib/MineSet/datamove/dm_config.sample. The format of this file is as follows:

Oracle {
"ORACLE_SID", "ORACLE_HOME";
}

Oracle_Remote {
“DATABASE_NAME”, “ADMIN_DIRECTORY”;
}
Informix {
"INFORMIXSERVER", "INFORMIXDIR";
}
Sybase {
"DSQUERY", "SYBASE";
}

Each optional entry describes the databases in use at your site. If your server is not running any databases, that is, you intended to use MineSet with ASCII files only, simply make an empty dm_config file.

The line "ORACLE_SID", "ORACLE_HOME" is filled in with the specific information and repeated once for each Oracle database to be accessed via the DataMover. ORACLE_SID and ORACLE_HOME are Oracle specific parameters defining an Oracle instance.

The Oracle_Remote section is for accessing remote Oracle databases via SQL*NET V2. The DATABASE_NAME entry is a logical name for the remote database, as defined in a tnsnames.ora file. The ADMIN_DIRECTORY entry is where DataMover searches for the tnsnames.ora file. This file is described in Oracle's SQL*NET documentation. Remote access to databases is described in more detail in “Using MineSet to Connect to Remote Databases”.

Each line in the Informix section defines a database server that, in turn, can contain several databases. The server is checked at runtime to determine which databases it contains, so there is no need to record the individual databases in the dm_config file. The first entry is the INFORMIX server (corresponding to the INFORMIXSERVER environment variable), and the second is the INFORMIX directory (corresponding to the INFORMIXDIR environment variable).

Each entry in the Sybase section defines a database server (or, in Sybase terminology, an SQL Server^™). The first entry is the Sybase SQL Server name (corresponding to the DSQUERY environment variable); the second is the Sybase home directory (corresponding to the SYBASE environment variable).

An example configuration file might be as follows:

Oracle {
"v73", "/usr/people/oracle/v73";
"wrhse", "/opt/oracle";
}

Oracle_Remote {
   “lifeseq”, “/usr/lib/MineSet2/datamove/”;
}
Informix {
"learn_online", "/u5/informix";
}
Sybase {
"MINESET", "/usr/sybase/10.0.2.4";
}

This configuration file lets the DataMover access:

Each of the INFORMIX and Sybase servers can, in turn, contain multiple databases.

For Sybase, DataMover uses vendor-supplied shared libraries as its connection to the databases. One of the purposes of the dm_config file is to specify where DataMover must look for its shared libraries. DataMover looks in the $SYBASE/lib/ directory for the following shared libraries: libct.so, libcs.so, ibcomn.so, libintl.so, libtcl.so, libinsck.so.

Sometimes it is convenient to use MineSet with data that is already stored as a file, but requires further processing before it can be mined or visualized. In this case, the data file can be made available (with a modest effort) to the Tool Manager/DataMover.

First, the data file must be in a tab-delimited format, with the same number of fields in each line. A numeric or string field with a single “?” character appearing between delimiters is loaded as a Null value.

For a detailed discussion of null values, refer to Appendix J, “Nulls in MineSet.”

The contents of the data file must be described to Tool Manager/DataMover via a file with the .schema extension. The format of the .schema file is shown next:

#
#  A line beginning with a "#" is a comment
#
input {

#  The first line lists the data file which is described.  It 
#  must be a simple filename, not a path.  

     file "carmodels.data";

#  Fields are listed left to right in the line, legal 
#  types are float, double, int, string, date, fixedString and  
#  dataString
#  Be sure to end every line with a semicolon ";"

     float mpg;
     int cylinders;
     float cubicinches;
     int horsepower;
     int weightlbs;
     double timeaccelerate;
     date when_introduced;
     string origin;
     	fixedString(3) manufacturer_code;
     dataString model;
}

The schema and data files must be located in the same directory. If you prepare a dataset in this fashion on the client machine, it can be opened with the Tool Manager's Find File dialog. If the file requires any additional processing, it is copied to the server. Sometimes this is not convenient, especially if the file already exists on the server, or is large. In this case, the .schema and .data files must be copied (or symbolically linked) into your file_cache directory on the server. The directory used as the file cache is specified in your .datamove file; the default is ./mineset_files/%U, where %U becomes your login name on the client machine.

For a more extended description of MineSet .schema files see Appendix A.

Sometimes it might not be feasible to install DataMover on the machine running the database server. In this situation, DataMover can be installed on an intermediate server, and DataMover then can use the database vendor's networking facility to connect to the remote database. (This sometimes is referred to as a three-tier architecture.)

Alternatively, you can load, or reload, the sample data separately. Each data directory in /usr/lib/MineSet/DBexamples on the server contains files necessary to load the data into any of the supported databases. These files are:

README - explains the data

*.sql - sets up an Oracle table
*.ctl - control file for loading into Oracle

*_syb.sql - sets up a Sybase table
*.bcf.fmt - Sybase format file

*_inf.sql - sets up an INFORMIX table
*_load.sql - loads the data into the INFORMIX table

In the *.ctl file, the separator is declared in the line

" fields terminated by X'20'  "

The separator is specified in ASCII hexadecimal; thus:

X'20' is used for ` '
X'2c' is used for `,'
X'09' is used for `\t'

Perform the following steps on the server with an Oracle database:

Perform the following steps on the server with a Sybase database:

where dataset is the table name (created using <dataset>_syb.sql), in means
"load into the dbms," <dataset>.data refers to the name of the ASCII data file, and -f points to the already-created format file. (When reading in from a file, the data types are character.)

Perform the following steps on the server with an INFORMIX database: