GT.M processes use UNIX Interprocess Communication (IPC) resources to coordinate and control access to the database and journal files, implement M LOCKs, and replicate databases. IPC resources are used not only by GT.M, but also by UNIX for its operation by other UNIX-based applications. For example, the Fidelity Information Services PROFILE application uses IPC resources for the Message Transport Manager (MTM) and the Heavy Thread Manager (HTM).

Although this appendix focuses on IPC resources used by GT.M for database access and replication, you must be familiar with other uses of IPC resources to administer your system effectively. Insufficient IPC resources can result in improper operation of the computer system, including GT.M and system hangs.

For database access and M locks, GT.M uses one UNIX shared memory segment and one semaphore set with three semaphores per database region. For replication, GT.M uses one shared memory segment and one semaphore set with three semaphores for the JournalPool, and one shared memory segment and one semaphore set with four semaphores for the Receive Pool.

IBM RS/6000 Users

AIX has a limit of 10 segment registers per 32-bit process. A GT.M process can access a maximum of 10 database regions in an unreplicated environment, and 8 if GT.M replication is active. If the Memory Mapped (MM) access method is used, two segment registers are used for each region and the maximum number of database regions drops to five (four with replication). Adjust the number appropriately if there is a mix of MM and Buffered Global (BG) access.

Current versions of GT.M do not use UNIX message queues. GT.M uses temporary socket files for IPC. Each process creates the files it needs in the directory specified by its gtm_tmp environment variable. By default, the socket files are created in /tmp.

	Socket files must be in a directory that is read/write accessible to all GT.M processes.