GT.M

Al igual que MUMPS, GT.M no tiene un concepto real de diferentes tipos de datos, aunque las cadenas (aquellas que no son completamente numéricas) deben colocarse entre comillas para diferenciarlas de las variables. Los números pueden tratarse como cadenas de dígitos, o las cadenas pueden tratarse como números mediante operadores numéricos (coerción, en la terminología de MUMPS). Los datos se tratan en función del contexto y las reglas de GT.M: 1+"42"produce el resultado 43, el primer carácter de 43es 4, y 20+"30 DUCKS"es 50(ya que los caracteres no numéricos se descartan durante las operaciones numéricas). ^{[ 8 ]}

Solo existe una estructura de datos: matrices dispersas multidimensionales (nodos clave-valor, subárboles y memoria asociativa son descripciones igualmente válidas) con hasta 32 subíndices. Un escalar puede considerarse como un elemento de la matriz con cero subíndices. Los nodos con diferente número de subíndices (incluido un nodo sin subíndices) pueden coexistir libremente en la misma matriz. Por ejemplo, si se quisiera representar las capitales nacionales de los Estados Unidos :

Establecer capital ("Estados Unidos")="Washington" Establecer capital ("Estados Unidos",1774,1776)="Filadelfia" Establecer capital ("Estados Unidos",1776,1777)="Baltimore" 

Las variables se crean bajo demanda cuando se les asignan por primera vez. Por lo tanto, el primer comando Set anterior crearía la variable Capital. Las variables tienen ámbito en el lenguaje y se denominan variables locales . Un acceso a la base de datos se parece a un acceso a un array, por ejemplo:

Establecer ^Capital("Estados Unidos")="Washington" 

pero el acento circunflejo (^) indica que se trata de un acceso a la base de datos. Las variables utilizadas para el acceso a la base de datos tienen un ámbito global único y, por supuesto, persisten y se comparten entre procesos. Se denominan variables globales . Los primeros 31 caracteres del nombre de una variable son importantes.

Los comandos Kill y ZKill se utilizan para eliminar subárboles de valores.

GT.M utiliza Unicode ( ISO/IEC-10646 ) para la compatibilidad con conjuntos de caracteres internacionales.

La base de datos lógica de un proceso GT.M consta de uno o más espacios de nombres de variables globales , cada uno con un número ilimitado de variables globales. Para cada espacio de nombres de variables globales, un directorio global asigna las variables globales a los archivos de base de datos donde residen. Un número ilimitado de variables globales puede caber en un archivo de base de datos; cada variable global debe caber en un único archivo de base de datos.

Un archivo de base de datos consta de hasta 224M (276.168.704) bloques de base de datos. Un bloque de base de datos es un múltiplo de 512 bytes, con un tamaño máximo de 65.024 bytes. Los tamaños de bloque más comunes son 4 KB, 8 KB y 16 KB; por lo tanto, con un tamaño de bloque de 8 KB, una variable global individual puede crecer hasta 1.792 GB. Un nodo de variable global (variable global, subíndices más valor) debe caber en un bloque de base de datos y cada bloque tiene una sobrecarga de 16 bytes. Por lo tanto, el nodo más grande que cabe en una base de datos con un tamaño de bloque de 4 KB es de 4.080 bytes. Una clave (variable global más subíndices) puede tener hasta 255 bytes.

El motor de base de datos no utiliza demonios y los procesos que acceden a ella operan con identificadores de usuario y grupo normales. Un proceso tiene acceso a un archivo de base de datos solo si la propiedad y los permisos de dicho archivo (junto con cualquier control de acceso por capas, como SELinux ) lo permiten. Cada proceso dispone, dentro de su espacio de direcciones, de toda la lógica necesaria para gestionar la base de datos, y los procesos cooperan entre sí para gestionar los archivos de base de datos. Cuando se registran las transacciones de un archivo de base de datos, las actualizaciones se escriben en los archivos de registro antes de escribirse en los archivos de base de datos, y en caso de un fallo del sistema, los archivos de base de datos pueden recuperarse a partir de los archivos de registro.

El motor de base de datos también admite el procesamiento de transacciones . Por lo tanto, código como este:

TStart()  Establecer ^Capital("Francia")="París"  Establecer ^País("París")="Francia" TCommit

Implementa una transacción ACID . GT.M utiliza control de concurrencia optimista para gestionar las transacciones.

Una arquitectura de complementos permite cifrar la base de datos para proteger los datos en reposo. GT.M se distribuye con un complemento de referencia que utiliza GnuPG .

A diferencia de las bases de datos, donde los nodos de variables globales deben caber dentro de un bloque, las cadenas de variables locales pueden alcanzar hasta 1 MB. El entorno de ejecución GT.M proporciona asignación dinámica de memoria con recolección de basura. El número de variables locales y el número de nodos en las variables locales solo están limitados por la memoria disponible para el proceso. El alcance predeterminado de una variable local es la vida útil del proceso. Las variables locales creadas dentro de rutinas mediante el comando New tienen un alcance más limitado.

Las rutinas GT.M se compilan y enlazan dinámicamente para su ejecución en el espacio de direcciones de cada proceso. A excepción de la implementación de GT.M de 32 bits para la plataforma Linux x86, los módulos objeto también pueden ubicarse en bibliotecas compartidas con el ldcomando estándar, en cuyo caso la memoria utilizada es compartida. Esto es importante porque una aplicación como VistA tiene más de 20 000 rutinas cuyo código objeto compilado supera los 200 MB. Un gran hospital que ejecuta VistA puede tener miles de procesos de usuario ejecutándose simultáneamente.

Salvo un par de pequeñas excepciones, GT.M incluye una implementación casi completa del estándar ISO M (conocido cariñosamente como MUMPS por razones históricas).

En GT.M, el código M puede llamar libremente al código C (o al código en otros lenguajes con una interfaz compatible con C), y el código C puede llamar libremente al código M (de modo que el programa de nivel superior puede ser un C main()). Por ejemplo, es un módulo GT.M en CPAN , m_python Archivado el 31-03-2010 en Wayback Machine para acceso desde Python o enlace EGTM para Erlang .

Los servicios web escritos en GT.M se pueden implementar bajo un super servidor de Internet como inetd o xinetd . Las aplicaciones habilitadas para la web pueden usar software en capas como EWD (archivado el 8 de enero de 2010 en Wayback Machine) o CFMumps .