FIS usually supports new operating system versions six months or so after stable releases are available, and we usually support each version for a two-year window.

We support GT.M releases in a rolling support model based on two years of certified releases. A release becomes no longer officially supported once a given release is more than one release beyond the two year window. Historically we have produced GT.M releases on a quarterly basis, subject to change. Note: customers always get the best support by staying current with releases as they are made available.

FIS will continue to attempt to support any release of GT.M in use by a Profile customer under that client's maintenance agreement, while that agreement is still in effect. FIS's ability to provide an appropriate level of support may become increasingly costly to the client. In other words, FIS may need to enact a special maintenance agreement to continue to provide support. The additional costs required would be maintain client release level specific servers, operating systems and other ancillary software for a given and reasonable time frame beyond the normal window.

FIS policy is only to provide remediation, in the current release, for identified issues in generally available and supported releases. It is not FIS policy to provide ongoing support of client specific release levels of unsupported software.

GT.M cannot be patched, and bugs are only fixed in new releases of software.

FIS maintains and releases GT.M on Linux as OSS. GT.M does not include any OSS libraries.

However, using some GT.M capabilities activates APIs that require the user make some OSS software available:

while those are what FIS tests with, as long as the API is compatible, substitutions should work.

	Note
	Linux distributions include various OSS components some of which GT.M relies on.

If you plan to use the example / reference implementation plugin in support of database encryption, TLS replication, or TLS sockets, you must compile the reference plugin in order to match the shared library dependencies specific to your platform. The instructions for compiling the Reference Implementation plugin are as follows:

The GT.M TLS reference encryption plugin implements a subset of options as documented in the OpenSSL man page for SSL_set_options which modify the default behavior of OpenSSL. Future versions of the plugin will enable new options as and when the OpenSSL library adds them. To enable options not supported by the GT.M TLS reference plugin, it is possible to create an OpenSSL configuration for GT.M processes. See the OpenSSL man page for "config".

FIS strongly recommends you back up your Global Directory file before upgrading. There is no one-step method for downgrading a Global Directory file to an older format.

To upgrade from any previous version of GT.M:

If you inadvertently upgrade a global directory, perform the following steps to downgrade to an old GT.M release:

An analogous procedure applies in the reverse direction.

Before starting the database file upgrade, use the prior GT.M version to perform an appropriate MUPIP action (i.e. ROLLBACK, RECOVER, RUNDOWN) to remove abandoned GT.M database semaphores and release any IPC resources.

There are three upgrade paths available when you upgrade to V7.1-007.

V7 Upgrade Path 1: In-place Upgrade

To upgrade from GT.M V7*:

There is no explicit procedure to upgrade a V7 database file when upgrading to a newer V7 version. After upgrading the Global Directory, opening a V7 database with a newer V7 GT.M process automatically upgrades the fields in the database file header.

To upgrade from GT.M V6* (or V5*):

There are two phases to upgrade from V6 to V7:

Both phases operate once per region. Phase 1 is not restartable. Phase 2 is restartable.

While these are the basic steps, customers must integrate them with appropriate operational practice and risk mitigating procedures, such as comprehensive testing, backup, integrity checks, journal and replication management, and so on based on their environments and risk tolerance. FIS strongly recommends performing a MUPIP INTEG (-FAST), of the database and creating a backup prior to upgrade. Customers must test these utilities against copies of their own production files, using their planned procedures, before undertaking the conversion of current production files.

Using MUPIP UPGRADE and MUPIP REORG -UPGRADE should be a significantly faster alternative to using MUPIP EXTRACT and LOAD. FIS favors using a "rolling" upgrade using a replicated instance. Whatever the approach you choose, FIS requests capturing all logs in case there are issues or questions leading to support requests.

Phase 1: Standalone MUPIP UPGRADE

MUPIP UPGRADE performs Phase 1 actions of upgrading a database to V7. The format of the UPGRADE command is:

MUPIP UPGRADE {-FILE <file name>; | [-REGION] <region list>}

As the GT.M version upgrade changes the journal format to support 64-bit block pointers, MUPIP UPGRADE does not maintain journal files or replication; configured journaling and replication resumes for activity after MUPIP UPGRADE.

UPGRADE:

At this point, after a successful MUPIP UPGRADE:

These database changes are physical rather than logical, and thus do not require replication beyond noting the increase in transaction numbers.

Phase 2: MUPIP REORG -UPGRADE (GVT Index Block Upgrade)

MUPIP REORG -UPGRADE performs Phase 2 actions of upgrading a database to V7 format. The format of MUPIP REORG -UPGRADE is:

MUPIP REORG -UPGRADE {-FILE <file_name> | [-REGION] <region_list>}

Before image journaling with MUPIP REORG upgrade provides maximum resiliency. MUPIP REORG -UPGRADE reports it has completed its actions for a region with a MUPGRDSUCC message, at which point all index blocks have V7m format with 64-bit block pointers. You can resume and complete a MUPIP REORG -UPGRADE stopped with a MUPIP STOP (or <Ctrl-C>); avoid a kill -9, which carries a high risk of database damage.

MUPIP REORG -UPGRADE:

Phase 3: Optional GVT Data and Local Bit Map Block Upgrade

While it makes no operational or processing difference, GT.M does not consider the database "fully upgraded" until the block version format of all data blocks becomes V7m. Any of the following operations upgrade some or all of the remaining data blocks:

Failure to perform Phase 3 has NO implications for V7.1-007 but might be an issue for any as-yet unplanned further enhancement.

	Important
	Taking the steps in the following list that use MUPIP REORG -MIN_LEVEL=1 significantly reduce upgrade time.

The following lists the recommended ordered steps for the full upgrade process:

V7 Upgrade Path 2: EXTRACT and LOAD

Two commonly used mechanisms are as follows. We recommend you use replication to stage the conversion and minimize down time.

	If you are using triggers, extract the triggers from the V6 database and load them in the new V7 database.

V7 Upgrade Path 3: No change

Continue using your V6 databases with GT.M V7.1-007. In case you do not wish to operate with files of differing format, specify the -V6 qualifier when invoking MUPIP CREATE.

Choosing the right upgrade path

Choose V7 Upgrade Path 1 or 2 if you anticipate a database file to grow to over 994Mi blocks or require trees of over 7 levels as V7.1-007 supports 16Gi blocks and 11 levels. Note that the maximum size of a V7 database file having 8KiB block size is 114TiB (8KiB*16Gi).

Choose the V7 Upgrade Path 3 if you do not anticipate a database file to grow beyond the V6 database limit of 994Mi blocks or a tree depth limit of 7 levels. Note that the maximum size of a V6 database file having 8KiB block size is 7TiB (8KiB*992Mi).

Other than the new maximum database file size and greater tree depth that comes with V7 Upgrade Path 1 and 2, there is no difference between V7 Upgrade Path 1 and 2 and V7 Upgrade Path 3. You can choose V7 Upgrade Path 3 first and then later choose V7 Upgrade Path 1 or 2 if a need arises.

For additional details on differences in factors involved in the V6 to V7 upgrade refer to Appendix G in the GT.M Administration and Operations Guide.

GT.M V7.1-007 does not require new replication instance files when upgrading from any version after V6.0-000.

On every GT.M upgrade:

	Important
	This is necessary because MUPIP JOURNAL cannot use journal files from a release other than its own for e.g. RECOVER, ROLLBACK, or EXTRACT. MUPIP UPGRADE temporarily disables journaling and replication settings for the duration of its activity. Once complete, MUPIP UPGRADE restores prior settings.

GT.M V7.1-007 does not require trigger definition upgrade when upgrading GT.M from any version after V6.3-000. If upgrading from a prior GT.M release, please see the instructions in the release notes for V6.3-014.

The configuration file version does not need to be the first item in the entire configuration. However, placing it at the top of the file makes for simplicity and understanding. Prior to version 2, configuration files were not explicitly versioned. When no version is present, the plugin treats the file version as 1. Configuration files using the "Plugins" section must be version 2 or higher.

A version 2 configuration file is backwards compatible provided keys protected by GnuPG are configured and present on disk. If this section is missing, the plugin treats the configuration as version 1.

Version 2 of the reference plugin configuration supports the "openssl-pkcs8" plugin configuration using OpenSSL. This section, if enabled, defines an RSA private and public key/certificate that encrypt database encryption keys and file encryption keys. The format of these sections follows the format described for Database Encryption and File Encryption below. Those configurations are nested inside the plugins definition to signify those keys are encrypted with the RSA private key.

The plugin section uses "openssl" in the name because it uses functionality from OpenSSL for encryption.

FIS recommends following your corporate procedures for generating and/or acquiring the RSA key.

The files section defines keys that MUMPS applications use to perform file encryption. It can exist as a global configuration used by GnuPG or as a subsection of the "openssl-pkcs8" plugin configuration.

MUMPS applications reference these keys by their name. These names must be unique among encryption keys inside the configuration file. This section serves to define GnuPG operation in a way compatible with version 1.

The TLS section contains information such as the location of the root certificate authority, leaf-level certificates with the corresponding private key files, and other TLS configuration options. Under the TLS section, you can use the same tlsid or separate tlsids (with a different set of certificates and options) for TLS replication and TLS sockets depending on what establishes appropriate security for your application.

One can adapt an existing configuration that uses GnuPG protected database and/or file encryption keys to one that uses both an OpenSSL RSA key and GnuPG. This can be useful when sites use more than one version of GT.M. To do so, convert all GnuPG protected symmetric keys to OpenSSL RSA protected symmetric keys. Then add entries for each into the "openssl-pkcs8" section as needed.

Each GnuPG protected key can be decrypted and piped to OpenSSL to encrypt with the RSA public key. In the example below, one must input the password for the GnuPG key ring.

 gpg −−homedir=$GNUPGHOME −−pinentry-mode=ask −−decrypt /path/to/database/key/dbONE.key | \
 openssl pkeyutl -certin -inkey /path/to/key/one.crt -out \
 /path/to/database/key/pkcs8dbONE.key -pkeyopt rsa_padding_mode:pkcs1 -encrypt

Each RSA protected database key file generated like this will need an entry in the "database" subsection of the "openssl-pkcs8" plugin configuration.

	Note
	Each user or role will need a role specific configuration file and keys.

 /* Default is 1 which disables "plugins" section parsing */
version: 2;

 /* Database Encryption Section
  * GT.M processes lookup database symmetric key file paths using both database file paths
  * and the symmetric key hash value in the database file header.
  * To support re-keying, a database file may have multiple keys associated with it.
  * This top-level Database section implicitly provides the (default) GnuPG configuration.
  */
database: {
 keys: (
 { /* Database file ONE */
 dat: "/path/to/database/file/dbONE.dat"; /* Encrypted database file */
 key: "/path/to/database/key/dbONE.key"; /* Encrypted symmetric key */
 },
 { /* Database file TWO */
 dat: "/path/to/database/file/dbTWO.dat";
 key: "/path/to/database/key/dbTWO.key";
 },
 {
 /* Database file ONE using a new key. Note the DB name remains the same */
 dat: "/path/to/database/file/dbONE.dat";
 key: "/path/to/database/key/dbONEnew.key";
 }
 /* Append new database symmetric keys to the end of this list */
 ...
      );
}

 /* File Encryption Section
  * MUMPS applications reference file encryption keys by the name.
  * Each name is unique in the configuration. One name cannot refer to more than one key.
  * This top-level Files section implicitly belongs to the (default) GnuPG plugin configuration.
  */
 files: {
 name1: "/path/to/symmetric/key1";
 name2: "/path/to/symmetric/key2";
 };

 /* GT.M Encryption Reference Plugin support
  * To use RSA keys for database key encryption, set the configuration version to 2
  * and create a plugin entry that includes database keys and (if needed) GT.M file encryption keys.
  */
plugins: {
 /* When using "openssl-pkcs8", only one RSA key encrypts keys. 
  * This could be a corporate issued key+certificate that shares a common root CA.
  * With this setup, users can share database encryption keys.
  * Without the common CA, users fail to verify other users when attempting to share the encrypted database symmetric key.
  */
 openssl-pkcs8: {
 enabled: 1; /* Disabled by default */
 format: "PEM"; /* Currently only PEM format is supported */
 key: "/path/to/key/one.key";
 cert: "/path/to/key/one.crt";
 /* The following parameters may be used in a future release.
  * Please refer to the guidance in the TLS section
  */
 CAfile: "/path/to/tls/certs/CA/CA.crt";
 CApath: "/path/to/tls/certs/CA/";
 /* This section follows the guidelines of the top level "Files" section. 
  * This plugin specific Files section belongs to this configuration. 
  * These keys are encrypted using this plugin's key.
  * Key paths must be distinct from keys used by other plugins
  */
  files: {
  pkcs8name1: "/path/to/symmetric/pkcs8key1";
  pkcs8name2: "/path/to/symmetric/pkcs8key2";
  };
 /* This section follows the guidelines of the top level "Database" section. 
  * This plugin specific Database section belongs to this configuration.
  * These keys are encrypted using this plugin's key.
  * Key paths must be distinct from keys used by other plugins
  */
 database: {
 keys: (
 { /* Database file ONE */
  dat: "/path/to/database/file/dbONE.dat";
  key: "/path/to/database/key/pkcs8dbONE.key";
 },
 { /* Database file TWO */
  dat: "/path/to/database/file/dbTWO.dat";
  key: "/path/to/database/key/pkcs8dbTWO.key";
 },
  { /* Database file ONE using a new key. Note the DB name remains the same */
  dat: "/path/to/database/file/dbONE.dat";
  key: "/path/to/database/key/pkcs8dbONEnew.key";
 }
  /* Append new database symmetric keys to the end of this list */
  ...
  );
  };
 };
};

/* TLS section */
tls: {
 /* Certificate Authority (CA) verify depth provides an upper limit on the number of CAs to look up for verifying a given certificate. 
  * The depth count is described as ''level 0:peer certificate'', ''level 1: CA certificate'',
  * ''level 2: higher level CA certificate'', and so on.
  * The default verification depth is 9.
  */
 verify-depth: 7;
 
 /* CAfile: points to a file, in PEM format, describing the trusted CAs. The file can contain several CA certificates identified by:
  * −−−−-BEGIN CERTIFICATE−−−−-
  * ... (CA certificate in base64 encoding) ...
  * −−−−-END CERTIFICATE−−−−-
  * sequences.
  */
 CAfile: "/path/to/tls/certs/CA/CA.crt";
 
 /* CApath: points to a directory containing CA certificates in PEM format.
  * The files each contain one CA certificate.
  * The plugin looks up files, which must be available, by the CA subject name hash value.
  * If more than once certificate with the same name hash value exists, the extension must be different (e.g. 9d66eef0.0, 9d66eef0.1 etc). 
  * The directory is typically created by the OpenSSL tool 'c_rehash'.
  */
 CApath: "/path/to/tls/certs/CA/";
 /* crl: points to a file containing list of revoked certificates. Create this file with the openssl utility. */
 crl: "/path/to/tls/revocation.crl";
 
 /* Timeout (in seconds) for a given session.
  * If a connection disconnects and resumes within this time interval,
  * TLS reuses the session to speed up the TLS handshake. 
  * A value of 0 forces sessions to not be reused. 
  * The default value is 1 hour.
  */
 session-timeout: 600;

 /* ssl-options: specifies OpenSSL options to be set or cleared. By default the TLS plugin uses the following ssl-options,
  * which disables SSLv2, SSLv3, TLSv1 and TLSv1.1
  * ssl-options: "SSL_OP_NO_SSLv2:SSL_OP_NO_SSLv3:SSL_OP_NO_TLSv1:SSL_OP_NO_TLSv1_1";  // Default
  * Enable SSLv3/TLSv1 by doing the following.
  * Note the use of '!' preceding the options inverts their application
  * ssl-options: "SSL_OP_NO_SSLv2:!SSL_OP_NO_SSLv3:!SSL_OP_NO_TLSv1:SSL_OP_NO_TLSv1_1";
  * WARNING: Even if the configuration is changed to support SSLv3/TLSv1,
  * OpenSSL may have been compiled to not support SSLv3/TLSv1 
  * or additional changes are needed to OpenSSL's configuration to allow SSLv3/TLSv1
  */
 /* cipher-list: List of acceptable TLS ciphers
  * NOTE: The naming scheme changed as of TLSv1.3
  * pre-TLSv1.3 ciphers default if not specified for TLSv1.2 and before cipher-list: 
  * "ALL:!ADH:!LOW:!EXP:!MD5:!DH:@STRENGTH";
  * TLSv1.3 ciphers  cipher-list:
  * "TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_8_SHA256:TLS_AES_128_CCM_SHA256:TLS_AES_256_GCM_SHA384";
  */
 /* verify-mode: Verification mode
  *  - SSL_VERIFY_NONE does no verification of certificates
  *  - SSL_VERIFY_PEER (default) performs verification of all certificates
  *  - SSL_VERIFY_POST_HANDSHAKE TLSv1.3 specific verifies certificates after handshake
  * verify-mode: "SSL_VERIFY_PEER"
  */
 /* Enable post-handshake fallback for clients that do not support PHA when using TLSv1.3
  * post-handshake-fallback: 1;
  */
 /* List of alphanumeric TLS configuration identifiers (the "tlsid" used by GT.M processes) which must begin with a letter.
  * Each configuration consists of name/value pairs for specific options like certificate, key and format. 
  * "tlsid" specific configuration options override global "tls" scope options.
  * These tlsids can be used for GT.M Database Replication and for TLS SOCKET devices used by application logic.
  */
 PRODUCTION: { /* "PRODUCTION" is the "tlsid" name */
 /*  Format of the certificate and private key pair.
 /*  Currently, the GT.M TLS plug-in only supports PEM format. */
 format: "PEM";
 /*  Path to the certificate. */
 cert: "/path/to/tls/certs/Malvern.crt";
 /* Path to the private key. If the private key is protected by a passphrase, use an obfuscated version of the password
  * in the environment variable which takes the form gtmtls_passwd_<identifier>.
  * For instance, for the below key, the environment variable should be 'gtmtls_passwd_PRODUCTION'.
  * Currently, the GT.M TLS plug-in only supports RSA private keys.
  */
 key: "/path/to/tls/certs/Malvern.key";
 };
 DEVELOPMENT: { /* "DEVELOPMENT" is the "tlsid" name */
 format: "PEM";
 cert: "/path/to/tls/certs/BrynMawr.crt";
 key: "/path/to/tls/certs/BrynMawr.key";
 };
};

As this $gtmcrypt_config file contains database, file, plugin and tls sections, you need to set the gtm_passwd and gtmtls_passwd_&lt;tlsid&gt; environment variables conforming to the maskpass utility's output. For more information on these environment variables, refer to "Environment Variables".