GT.M
| Company type | Software |
|---|---|
| Industry | Database management systems |
| Predecessor | Greystone Technology Corp |
| Founded | 1980s |
| Founder | Greystone Technology Corp |
Area served | Worldwide (Europe, India, North America) |
| Products | GT.M database engine, MUMPS compiler |
| Owner | FIS |
| Parent | FIS |
| Website | sourceforge |
GT.M is a high-performance key–value database engine designed specifically for transaction processing. It belongs to the category of "schema-less" or "NoSQL" databases. Additionally, GT.M functions as both an application development environment and a compiler for the ISO-compliant MUMPS programming language.
Originating in the 1980s from Greystone Technology Corp, GT.M implements the ANSI standard M language on AIX and Linux platforms. It retains the classic features of M and incorporates an optimizing compiler that produces object code, eliminating the need for internal interpreters during runtime.
The database engine transitioned to an open source model in 2000 and is currently maintained by FIS. GT.M serves as the foundation for FIS's FIS Profile banking software, supporting financial institutions across Europe, India, and North America. Notable clients include Capital One 360 (US), Tangerine (Scotiabank, Canada), and UK challenger banks such as Atom Bank, Tandem Bank, Sainsbury's Bank, Scottish Widows, and Barclays Direct.
In the healthcare sector, GT.M underlies open source Electronic Health Record systems like WorldVistA and Medsphere's OpenVista. It is also acknowledged as an open source healthcare partner by Red Hat. The entire codebase comprises roughly two million lines of code.
Technical overview
GT.M consists of three main components: a language subsystem, a database subsystem, and utility tools. While these components are tightly integrated, each can operate independently while sharing a unified data structure and typing system.
Data organization and typing
Similar to MUMPS, GT.M does not distinguish between separate data types; strings (non-numeric) are enclosed in quotes to differentiate them from variables. Numeric values can be interpreted as strings and vice versa through implicit coercion. For example, evaluating 1+"42" results in 43, with any non-numeric characters ignored during numeric conversions.
The only data structure supported is multi-dimensional sparse arrays that allow up to 32 subscripts. Scalars are represented as arrays with zero subscripts. Arrays may contain nodes with various subscript depths simultaneously. Variables are instantiated upon assignment and have local scope. Accessing the database resembles array referencing but uses a caret (^), signifying global variables that possess single global scope; these persist beyond process lifetimes and are shared among processes. Variable names consider only the first 31 characters significant.
Commands such as Kill and ZKill remove entire subtrees of values.
GT.M supports internationalization through Unicode (ISO/IEC-10646) encoding.
Database subsystem
A GT.M logical database is composed of one or more global variable namespaces. Each namespace is linked via a global directory to physical database files where data is stored. Multiple global variables can coexist within a single database file; however, each variable must be fully contained within one file.
Database files can hold up to 224 million blocks, with block sizes commonly set between 4KB and 16KB. For instance, using an 8KB block size allows a global variable to grow up to approximately 1,792GB. Every global variable node (comprising the variable name, subscripts, and value) must fit inside a single block, which includes a 16-byte overhead. Keys may be as long as 255 bytes.
The engine operates without a daemon; instead, individual processes access database files directly under standard operating system permissions and security frameworks such as SELinux. Each process contains all necessary database management logic and coordinates with other processes for file operations. To ensure crash recovery, journaled databases first record updates in journal files.
GT.M provides ACID-compliant transaction processing by employing optimistic concurrency control techniques. An example transaction:
TStart()
Set ^Capital("France")="Paris"
Set ^Country("Paris")="France"
TCommit
demonstrates how data integrity is maintained during concurrent operations.
The system supports a plug-in model for encrypting data at rest; GT.M includes a reference plug-in utilizing GnuPG encryption.
Language subsystem
In contrast to the database where global variable nodes must reside within a database block, local variable strings in GT.M can expand up to 1MB in size. The GT.M runtime environment offers dynamic memory allocation accompanied by garbage collection. The quantity of local variables and nodes is constrained solely by the available process storage. By default, local variables persist for the duration of the process, although variables created with the New command have a more restricted lifetime.
GT.M routines undergo dynamic compilation and linking, executing within the address space of each individual process. Except for the 32-bit x86 Linux variant, object modules may be incorporated into shared libraries using the standard ld utility, facilitating memory sharing. This feature is essential for extensive applications like VistA, which contains over 20,000 routines and compiled code exceeding 200MB. Large medical centers running VistA can support thousands of simultaneous user processes.
GT.M provides an almost complete implementation of the ISO standard M language (formerly known as MUMPS).
M code within GT.M can invoke C functions (and other languages with C-compatible interfaces), and conversely, a C main() program can call M routines. Notable examples include a GT.M module available on CPAN, m_python enabling Python integration, and EGTM bindings for Erlang.
Web services developed with GT.M can be deployed under Internet super servers such as inetd or xinetd. Web-based applications frequently utilize layered frameworks like EWD or CFMumps.
Platforms
GT.M offers full support on the following platforms:
- AIX running on IBM System p
- Linux on both x86_64 and IA-32 (x86) architectures. The YottaDB fork extends support to ARM processors.
Support for GT.M has been discontinued on:
While the Linux IA-32 codebase includes modifications to operate under Cygwin on Windows, this environment is not officially supported.
Licensing
On Linux platforms (x86-64 and IA-32) as well as OpenVMS on Alpha/AXP, GT.M is distributed as Free / Open Source Software (FOSS) under the GNU Affero General Public License version 3. For other operating systems, it is offered under proprietary licensing terms.
Common applications
GT.M’s primary usage lies within healthcare and financial sectors. Its initial production deployment took place in 1986 at the Elvis Presley Memorial Trauma Center in Memphis, Tennessee. Via FIS Profile, it supports banking institutions across the United States, Canada, Spain, France, Italy, Vietnam, and Thailand.
Commercial solutions provide access to GT.M databases through SQL and ODBC interfaces.
Further reading
- Ignacio Valdes (November 17, 2002), K.S. Bhaskar Receives 2002 LMN Achievement Award, linuxmednews.com