Before you begin installing GT.M, perform the following tasks:
Read the GT.M Release Notes documentation. The release documents contain the latest information that may be critical for installing and configuring GT.M. They are located at the User Documentation tab on the GT.M website (www.fis-gtm.com).
Determine whether or not, GT.M access is restricted to a group. Keep the group name handy as you will have to enter it during the installation process.
Set the environment variable gtm_log to a directory where GT.M should create log files. In conformance with the Filesystem Hierarchy Standard, FIS recommends /var/log/fis-gtm/$gtmver
as the value for $gtm_log unless you are installing the same version of GT.M in multiple directories. Note that $gtmver
can be in the form of V6.1-000_x86
which represents the current GT.M release and platform information.
If you do not set gtm_log, GT.M creates log files in a directory in /tmp (AIX, GNU/Linux)
. However, this is not recommended because it makes GT.M log files vulnerable to the retention policy of a temporary directory.
Important | |
---|---|
Starting with V6.0-000, gtmsecshr logs its messages in the system log and the environment variable gtm_log is ignored. |
If you need to perform UTF-8 mode operations in GT.M, you must have at least ICU version 3.6 installed. GT.M uses ICU 3.6 (or above) to provide the support for UTF-8 mode. GT.M generates the distribution for UTF-8 mode only if ICU 3.6 (or above) is installed on your system. GT.M uses the system default version of ICU. GT.M expects ICU to have been built with symbol renaming disabled and issues an error at startup if the currently installed version of ICU has been built with symbol renaming enabled.
Caution | |
---|---|
Installing GT.M on an NFS mounted directory is not recommended. Several NFS characteristics violate GT.M database design assumptions which may manifest themselves as hard to diagnose problems. If you still choose to install and operate GT.M from an NFS mounted directory, there are chances that at some point you will face significant problems with performance and response time. While you should never operate GT.M database and journal files from an NFS mounted directory you can safely, except on Linux, use an NFS mounted directory for keeping source and object code modules and performing sequential file IO. While NFS mounted files may work for you, historically they have not provided sufficient support for file locking over NFS to prevent intermittent errors when you have a significant concurrent file activity. |