Daylight v4.9
Release Date: 1 February 2008

Name

thormake - create a Thor database and set its properties

Unix Synopsis

thormake [options ...] database sizepri sizexref

Description

thormake creates a Thor database (via the Thor server), and sets its properties (passwords, datatypes database, and optional indirect-data database, autocrunch limit, etc.).

The database-name part of database must be complete including a full path from the root of the host machine's file system. If the name includes environment variables, such as $DY_THORDB, they must be quoted on the command line to prevent expansion by the shell.

If the option SECURE_PASSWORDS is TRUE, passwords must be entered interactively. Otherwise, database passwords can be entered as part of database, all three separated by commas; for example:

mydb%readpw,writepw,execpw@host%hostpw
Empty passwords are allowed; e.g. "mydb%@host" creates a database with no passwords, and "mydb%,writepw,execpw@host" has write and exec passwords but no read password. (If you use this comma-separated entry technique, the combined length of all three passwords must be less that 100 characters.) If no passwords are in database (e.g. mydb@host), you will be prompted for the three passwords interactively.

The parameters sizepri and sizexref specify the number of entries in the hash tables for primary identifiers and cross-referencing identifiers. sizepri should be roughly equal to the total number of TDTs that will be stored in the database. sizexref should be roughly equal to the the number of non-SMILES identifiers in the database. For example, if a database will contain 25,000 TDTs, each of which has on average 5 non-SMILES identifiers (e.g. $NAM, $CAS, etc.), we would specify 25000 and 125000 for sizepri and sizexref, respectively.

The manual page for "thorfilters" describes features common to this and all "thorfilter" programs; refer to it for more information about this program and the syntax of "database".

Options

-AUTOCRUNCH_LIMIT limit
Specifies the fraction of unused space ("garbage") in the database which, if exceeded, triggers an automatic "crunch" when TDTs are being loaded into the database. For example, a value of 0.1 causes crunching whenever 10% of the database is unused space; a value of 1.0 suppresses auto-crunching completely. See thorcrunch(1) for more information.
-CACHE_WHEN NEVER|OK|ALWAYS
"Caching" causes part or all of the database to be loaded and retained in the server's memory for fast access. It can greatly improve performance, at the cost of using memory. See the Daylight Theory Manual for more details.

This option specifies how caching requests from client programs are to be handled. If set to NEVER, caching is prohibited, and client caching requests for the database are silently ignored. If set to OK, client caching requests are honored. If set to ALWAYS, the database is forced to the caching state specified by the CACHE_LEVEL option (below), and client caching requests for the database are silently ignored. Default is "" (unspecified -- use the Thor server's default, which typically is "OK").

-CACHE_LEVEL OFF|WRITETHRU|READWRITE|WRITETHRU_ALL|READWRITE_ALL
If the option CACHE_WHEN is set to ALWAYS, this option specifies the cache level. OFF disables caching altogether. WRITETHRU causes the database's hash table to be cached for reading, but writes are immediately posted to the disk. READWRITE caches the hash table for reading and writing; changes aren't posted to the disk until the database is closed. WRITETHRU_ALL caches the entire database (which may require considerable memory, depending on the database's size) for reading, but immediately posts modified records to the disk. READWRITE_ALL caches the entire database; changes aren't posted to the disk until the database is closed or "sync'ed". Default is "" (unspecified -- use the Thor server's default, "OFF").
-DATATYPES_DATABASE dbname
Specifies the auxiliary datatypes database, from which datatype definitions will be obtained. This can be a simple database name (e.g. "mydb_datatypes", but it is a good idea to use a full path (e.g. "$DY_THORDB/mydb_datatypes") so that changes in the server's search path won't affect which datatypes are used. If the database being create is a datatypes-definition database, this option should not be specified. If "dbname" contains a server specification (e.g. has @host at its end), the host must be the same as that specified as part of database. Default is none.
-INDIRECT_DATABASE dbname
Similar to -DATATYPE_DATABASE, but specifies the auxiliary indirect-data database, from which indirect-data expansions are retrieved. It too should be a full path, and must be on the same server as database. Default is none.
-MAXIMUM_DATABASE_SIZE size
The maximum number of TDTs you can specify for the "sizepri" and "sizexref" parameters. Intended to prevent accidentally creating absurdly-large databases. If you really want to make a huge database, you must raise this limit. Default: 100000000.
-TDT_LOCKING ENABLE|DISABLE|NOCHANGE
You can enforce or disable record locking. When a database is created, record locking is not enforced, and for most situations, record locking is unnecessary. None of the "thorfilters" programs (e.g. thorload(1), thorlist(1)) or sthorman make special use of record locking. You shouldn't use this feature unless you are writing your own Thor client programs (via the THOR Toolkit), and you have a specific need for record locking.
If record locking is enabled for a database, clients can "lock" records. A client that locks a record is said to "own" the record, and only the owner of a record can modify it and unlock it. Some Thor client programs also use the "rollback" feature, which allows a locked record to be written to the database but not "committed", then later "rolled back" to its original definition.
STANDARD THORFILTER OPTIONS:
----------------------------

The following options are common to most or all "thorfilter" programs. They are described in more detail in thorfilters(1).

-SECURE_PASSWORDS TRUE|FALSE

TRUE means don't allow passwords on the command line (require interactive entry). Default: TRUE.
-THOR_IPC_SERVICE service
Names the default TCP/IP service or "port" of the Thor server. Default: thor.

Return Value

Returns status zero if the database is successfully created and all properties set. Returns one if a problem is detected.

Examples

thormake '$DY_THORDB/mydb_datatypes' 50 1
Creates a datatypes-definition database, with 50 entries in the primary database. Datatype definitions have no cross references, so we make the cross-reference hash table the smallest legal value. Note that the database name is quoted to prevent the shell from expanding it; the environment variable "$DY_THORDB" is expanded by the server. The read, write, and executive passwords will be entered interactively.
thormake '$DY_THORDB/mydb' 10000 50000 \\ -DATATYPES_DATABASE '$DY_THORDB/mydb_datatypes'
Creates a database, with 10,000 entries in the primary database and 50,000 entries for non-SMILES cross references. The datatypes- definition database is "mydb_datatypes". The read, write, and executive passwords will be entered interactively.
thormake '$DY_THORDB/mydb%' 10000 50000 \\ -DATATYPES_DATABASE '$DY_THORDB/mydb_datatypes'
Same as the previous example above, but all passwords will be blank (and you won't be prompted to enter passwords). Only works if the option SECURE_PASSWORDS is FALSE (see thorfilters(1)).

Files

$DY_ROOT/bin/thormake

Daylight License

programs: thormanager

Related Topics

dayevict(1) daymessage(1) merlindbping(1) merlinload(1) merlinls(1) merlinping(1) merlinwho(1) thorchange(1) thorcrunch(1) thordbping(1) thordelete(1) thordestroy(1) thordiff(1) thordump(1) thorlist(1) thorload(1) thorlookup(1) thorls(1) thorping(1) thorwho(1)

sthorman(1) thorserver(1) merlinserver(1)

dt_setpassword(3) dt_thor_autocrunch_limit(3) dt_thor_cachecontrol(3) dt_thor_setreadonly(3) dt_thor_setauxillarydb(3) dt_thor_settdtlocking(3) dt_thor_tdtlocking(3) licensing(5)

Daylight Theory Manual, Daylight System Administration Manual

Bugs

None known.