Daylight v4.9
Release Date: 1 February 2008

Name

thorchange - change database properties

Unix Synopsis

thorchange [options] database

Description

thorchange changes the properties of database (passwords, datatypes database, indirect-data database, autocrunch limit, etc.).

The syntax of the database name is discussed in thorfilters(1) and in database(5).

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,oldpw@host%hostpw
Empty passwords are allowed; e.g. "mydb%@host" specifies a database that has no current password, and no changes are made to its passwords. The specification "mydb%,writepw,execpw,oldpw@host" uses "oldpw" to open the database, then changes the write and executive passwords, but leaves the read password alone. The combined length of all three passwords must be less that 100 characters. If no passwords are in database specification (e.g. mydb@host), you will be prompted for the three passwords interactively.

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 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 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 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 are not posted to the disk until the database is closed. WRITETHRU_ALL caches the entire database (which may require considerable memory, depending on the database size) for reading, but immediately posts modified records to the disk. READWRITE_ALL caches the entire database; changes arenot posted to the disk until the database is closed or "synced". Default is "" (unspecified -- use the Thor server 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 search path will not 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.
-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 should not 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.
-SETACCESS WRITEABLE|READONLY|NOCHANGE
Change a database from writable to read-only, or from read-only back to writable. A read-only database has some special features: the server doesnot try to set a "lock" file, and the files on disk can be read-only. This means that a read-only database can reside on non-writable media, such as a CD-ROM. (A writable database files must be individually writable, even if you never open it with write permission.)
A read-only database cannot be modified in any way. Because of this, thorchange(1) uses the following strategy. If you specify WRITABLE, the database is made writable before any other changes are attempted. If you specify READONLY, the database is first made writable (unless it already is), then other changes are made, and finally it is made read-only. (See the example below.) Default is NOCHANGE.
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 donot 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

thorchange '$DY_THORDB/mydb' -DATATYPES_DATABASE '$DY_THORDB/mydb_datatypes'
Changes the datatypes database of "mydb" to "$DY_THORDB/mydb_datatypes". The current executive password is obtained interactively.
thorchange mydb%hamlet,othello,macbeth,shakespeare
Opens "mydb" using the current executive password "shakespeare", then changes the read, write, and executive passwords to "hamlet", "othello", and "macbeth", respectively.
thorchange '$DY_THORDB/medchem95%foo,bar,baz,' -SETACCESS READONLY
Puts passwords on the medchem95 database (the database is read-only to begin with, and has no passwords). First opens it with an empty password, changes it to "writable", adds read, write, and executive passwords ("foo", "bar", and "baz", respectively), then changes the database back to read-only.

Files

$DY_ROOT/bin/thorchange

Daylight License

programs: thor
Uses the "thor" license if passwords are being changed, or access is being changed (-SETACCESS READONLY|WRITEABLE). This allows users to add passwords to commercial databases, or to make commercial databases read-only, even though they do not normally do Thor database management.
programs: thormanager
Uses the "thormanager license if any changes except passwords and READONLY/WRITEABLE are being made.

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) thormake(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.