GT.M allows updating globals belonging to a different source instance using extended global references or SET $ZGBLDIR. While the replication setup remains the same, these are the main considerations:

Notes

Like other mapping specified by a global directory, a process determines any instance mapping by a global directory at the time a process first uses uses the global directory. Processes other than MUPIP CREATE ignore other (non-mapping) global directory database characteristics, except for collation, which interacts with mapping. When Instance Freeze is enabled (gtm_custom_errors is appropriately defined), a process attaches a region to an instance at the first access to the region; the access may be a read or a VIEW/$VIEW(). Otherwise, the process attaches to a region at the first update to that region. When the mappings are correct, this difference does not matter. A process can always update globals that are not in a replicated region. Use $VIEW("JNLPOOL") to determine the state of the current Journal Pool. $VIEW("JNLPOOL") returns the replication instance file name for the current Journal Pool and an empty string when there is no Journal Pool. Note that the current Journal Pool may not be associated with the last global accessed by an extended reference.

Example:

An EHR application uses a BC replication configuration (A->B) to provide continuous availability. There are two data warehouses for billing information and medical history. For research purposes, the data in these medical history warehouses is cleansed of patient identifiers. Two SI replication instances (P->Q) are setup for the two data warehouses.

The primary global directory (specified via the environment variable gtmgbldir) includes the regions needed for the application proper. It may have the instance file as specified in the global directory or via the environment variable gtm_repl_instance. Each warehouse instance would have its own global directory (e.g. p.gld and q.gld). These global directories have an instance file specified with GDE CHANGE -INSTANCE -FILE_NAME=<replication_instance_file>.

Such a replication setup may benefit from this facility in the following ways:

Because this functionality has a wide variety of user stories (use cases) and has substantial complexity, although the code appears robust, we are not confident that we have exercised a sufficient breadth of use cases in our testing. Also, we may make changes in future releases that are not entirely backwards compatible. We encourage you to use this facility in development and testing, and to provide us with feedback. If you are an FIS customer and wish to use this in production, please contact us beforehand to discuss your use case(s). (GTM-8182)

GT.M LOCK commands perform better with large numbers of locks, and particularly with large numbers of processes acquiring the locks. Previously processes acquiring locks could encounter significant slowdown and lock timeouts as the number of locks and competing processes increased. This change requires additional memory per lock slot, so administrators should monitor lock slots (LKE SHOW) to determine if they need to increase lock space needs.

The GDE -LOCK_SPACE segment qualifier and MUPIP SET -LOCK_SPACE qualifier accept a maximum value of 262144 pages. Previously the maximum value was 65536 pages.

LKE SHOW includes a LOCKSPACEINFO message in its output for regions with a BG or MM access method. This message provides additional information on the use of LOCK space. Previously LKE only issued this message when the lock space was exhausted.

(GTM-8680)

When the first reference to a database for which a process has statistics sharing enabled is an extended reference, $REFERENCE maintains the extended reference. A regression associated with the implementation of statistics sharing in V6.3-001[A] caused this unusual case to lose that information. This was only ever observed in the GT.M development environment and has never been reported from a customer site. (GTM-8790)

GT.M keeps journal files up to date while a MUPIP FREEZE -ONLINE is in place. Previously the journal files would only be updated when there was a large amount of journal activity or the freeze was removed. (GTM-8795)

GT.M correctly handles any errors in the middle of a transaction commit. In GT.M V6.3-002, due to a regression introduced by GTM-8436, it was possible in very rare scenarios for a critical section deadlock. This issue was only observed in the GT.M development environment, and was never reported by a user. (GTM-8796)

GT.M manages LOCK concurrency correctly when checking for abandoned LOCKs. In V6.3-002 it could prematurely or belatedly determine that a LOCK was abandoned. (GTM-8805)

GT.M processes detach from database files correctly when a FREEZE -ONLINE is in place. Previously a process could hang waiting on a critical resource while trying to detach, which typically occurs when the process is trying to exit. (GTM-8850)

Improve available information in cases of apparent database integrity issues. (GTM-8858)

GT.M properly handles retries involving $ORDER(gvn,-1) or $ZPREVIOUS(gvn) functions. Previously, with certain key combinations, the retry processing could overflow a buffer, leading to memory corruption. The workaround was for any process using $$ORDER(,-1) in a region to previously have used a maximum length key for the region. (GTM-8873)

GT.M handles out-of-lock-space conditions more gracefully. Previously a full lock table could result in corruption of the lock structures, leading to segmentation violations (SIG-11). (GTM-9020)

This basically reverts GTM-8680 as the performance improvements were unreliable in circumstances reported by a customer, resulting in multiple processes occasionally holding the same LOCK. The GDE -LOCK_SPACE segment qualifier and MUPIP SET -LOCK_SPACE qualifier accept a maximum value of 65536 pages. In V6.3-003[A] the maximum value was 262144 pages. LKE SHOW does not include a LOCKSPACEINFO message in its output for regions with a BG or MM access method as it did in V6.3-003[A]; GT.M only issues this when the application exhausts the LOCK space. (GTM-9023)

Addressed by GTM-8694 (GTM-6115)

When GT.M encounters a line with a length greater than 8192 bytes in a source file, it emits a %GTM-W-LSINSERTED warning. This warning identifies cases where a line greater than 8192 bytes is split into multiple lines, which causes statements beyond the character prior to the limit to execute irrespective of any starting IF, ELSE or FOR commands. Previously, GT.M split the lines with no warning. (GTM-7986)

GT.M accepts an offset without a label for an entryref argument to DO, GOTO and ZGOTO. FIS recommends restricting the use of offsets in entryrefs to debugging, error handling and testing. Previously GT.M required a label before any offset. (GTM-8186)

GT.M sets $KEY to the characters terminating a READ, and NULL if terminated otherwise (e.g. FIX format, end of file, or timeout). When it encounters an error during an I/O, GT.M sets $DEVICE to "1," followed by an error description. Previously, GT.M did not maintain $KEY for sequential devices and only maintained $DEVICE for certain I/O errors. (GTM-8587)

GT.M checks the syntax of code assigned to $ETRAP, $ZSTEP, $ZTRAP, and EXCEPTION at the time they are specified. Note that $ZTRAP and EXCEPTION are subject to gtm_ztrap_form, and, if that specifies entryref or adaptive, GT.M does not check the syntax. Also, the environment variables $gtm_etrap, $gtm_trigger_etrap, and $gtm_zstep provide ways of setting some of the ISVs, so their values are verified at process initiation. Further, a SET $ETRAP uses a temporary default value of "IF $ZJOBEXAM" when shifting from $ZTRAP to $ETRAP in case the specified value has compilation errors. Previously GT.M detected errors in such code only for SET $ZSTEP and when attempting to use the vector. (GTM-8769)

$SELECT() compilation properly handles special cases where an omitted colon after a literal true select argument produces a syntax error; a regression introduced in V6.3-001[A], caused it to produce a GTMASSERT2 after reporting the issue. (GTM-8780)

$NAME() of a naked reference returns any extended reference associated with the current $REFERENCE; previously it did not. (GTM-8786)

The compiler excludes BLKTODEEP lines from the object files; due to a regression introduced by GTM-5178 in V6.3-002 they were not excluded (GTM-8788)

The Update Process operates correctly when a trigger issues a NEW $ZGBLDIR while performing updates on other unreplicated instances. A regression introduced with GTM-4759 in V63000[A] caused such operations in the Update Process to terminate unexpectedly with a segmentation fault (SIG-11). (GTM-8789)

$QUERY() of a local variable produces a MAXSTRLEN error when its result exceeds the supported string length. While GT.M supports very long key lengths for local variables, features that need to work with the entire key, such as $NAME() and $QUERY(), may not be able to handle keys with a length that exceeds the maximum supported string length (currently 1MiB). Rather than prohibit longer keys entirely, GT.M just restricts such features, so, if you need the features, avoid keys that exceed the limit. Previously $QUERY() could give a segmentation violation (SIG-11) if it encountered an over-length key. (GTM-6115)(GTM-8792)

The ZSHOW "T" (where "T" can be case-insensitive) produces only the summary lines for "G" and "L" output; previously ZSHOW always showed the detail with the summary. (GTM-8804)

GT.M reports a NUMOFLOW error for a string literal used as a number and evaluating to a number that exceeds the supported range, as of this writing: 1E47. A compiler optimization in V6.3-001[A] caused such an evaluation to produce a very very small negative value. (GTM-8832)

$DEVICE returns the complete error message. Previously, $DEVICE truncated messages which were over 80 characters. (GTM-8839)

The read/write (non-NEWable) $ZSTRPLLIM ISV provides a way for a process to limit its process private memory used for local variable and scratch storage. When the value is zero (0), the default, or negative, there is no limit. A positive value specifies a byte limit. When a request for additional memory exceeds the limit, GT.M does the expansion, and then produces an STPCRIT error. By default, a later request for memory produces an STPOFLOW, unless, subsequent to STPCRIT, $ZSTRPLLIM has been set to the same or higher limit. Note that GT.M allocates memory in large blocks so the interaction of $ZSTRPLLIM with memory growth is not exact. When the gtm_string_pool_limit environment variable specifies a positive value, GT.M uses it for the initial value of $ZSTRPLLIM. Previously, process memory was only limited by operating system configuration. (GTM-8847)

The compiler appropriately handles a syntax error in the argument of a postconditional command when the postconditional is a literal that evaluates to FALSE. Due to a regression associated with GTM-8573 in V6.3-001[A], this combination caused an abnormal termination with a segmentation violation (SIG-11). (GTM-8854)

GT.M defers literal optimizations involving patterns within an XECUTE as well as evaluations that encounter issues with the pattern table. Due to a regression associated with GTM-8573 in V6.3-001[A], these combinations caused an abnormal termination with a segmentation violation (SIG-11). (GTM-8856)

Pattern code processing appropriately produces a PATMAXLEN error for certain patterns that exceed the size GT.M supports. Previously, some patterns produced a segmentation violation (SIG-11). This issue was only observed in the GT.M development environment, and was never reported by a user. (GTM-8857)

GT.M appropriately handles timeout values which have more than three decimal digits; in V6.3-002 and V6.3-003, such values inappropriately had a very long timeout. The workaround was to avoid such values because GT.M only recognizes three digits after the decimal point for timeouts. (GTM-8866)

When using standard Boolean evaluation (no short-circuiting enabled by $gtm_boolean or gtm_side_effects) GT.M deals appropriately with cases where the there is a side effect and an right-hand operand interior to the expression happens to evaluate to a value that causes an incorrect result. This issue appeared with the introduction of standard Boolean evaluation in V5.5-000, and has not previously shown up in testing or been reported until a customer encountered a case. (GTM-8880)

MUPIP BACKUP for directory and file name lengths equal and greater than 255, issues FILENAMETOOLONG error; previously, this produced a core. Also, backing up an Instance File to a path longer than 255 succeeds with the correct journal sequence number; previously, this issued an incorrect journal sequence number. In addition, MUPIP JOURNAL -RECOVER -REDIRECT issues more information for the INVREDIRQUAL error; previously, it provided less context for the INVREDIRQUAL error. (GTM-4212)

The MUPIP SET command supports the following qualifiers: -N[ULL_SUBSCRIPTS]={never, always, existing}, which controls whether GT.M accepts null subscripts for database keys. -[NO]STD[NULLCOLL], which determines whether GT.M will use standard MUMPS collation or GT.M collation for null-subscripted keys. Previously, this functionality was only available through GDE for database file creation, and DSE for existing database files. FIS strongly recommends avoiding the use of DSE when there is an alternative. (GTM-8617)

MUPIP REPLICATE -RECEIVER -LOG_INTERVAL= and MUPIP SET -DEFER_TIME= accept values ranging from 0 to 2**31-1, -DEFER_TIME= accepts one special value -1; otherwise they produce an error message. MUPIP REPLICATE -RECEIVER -HELPER accepts values ranging from 1 to 128 and otherwise produces an error message. Previously, all these operations accepted inappropriate values. (GTM-8732)

MUPIP SET -{FILE|REGION} recognizes the -[NO]READ_ONLY qualifier to indicate whether GT.M should treat an MM access method segment as read only for all users, including root. This designation augments UNIX authorizations and prevents any state updates that normally might require an operational action for a database with no current accessing (attached) processes. The GT.M help databases have -READ_ONLY set by default. Previously, a database such as the gtmhelp database in the GT.M distribution typically never received a data update but nevertheless could require a ROLLBACK, RECOVER or RUNDOWN to ensure a proper at-rest state. MUPIP emits an error on attempts to set -READ_ONLY on databases with the BG access method, or to set the access method to BG on databases with -READ_ONLY set. (GTM-8735)

MUPIP SET for file or region accepts -H[ARD_SPIN_COUNT]=<integer count> and -SPIN[_SLEEP_MASK]=<hexadecimal mask>; previously it did not support changes to the hard spin count and required -SPIN_SLEEP_LIMIT to change the spin sleep mask. MUPIP SET no longer supports the -SPIN_SLEEP_LIMIT qualifier.(GTM-8767)

MUPIP FREEZE sends a DBFREEZEON/DBFREEZEOFF message to the system log for each region whose freeze state is changed. (GTM-8779)

MUPIP JOURNAL -EXTRACT='-stdout' appropriately handles its termination; previously, if stdout was already closed this specification produced a segmentation violation (SIG-11). (GTM-8787)

Copies of a database file made while a MUPIP FREEZE -ONLINE -ON is in effect can be used on the same system by performing a MUPIP RUNDOWN -OVERRIDE and a MUPIP FREEZE -OFF on the copy. Previously, an attempt to remove the freeze on the copy would attempt to modify the journal files of the original database and fail. Note that this change moved the ^%PEEKBYNAME item "sgmnt_data.freeze_online" to "node_local.freeze_online"; for this release (V6.3-003) only, ^%PEEKBYNAME recognizes either designation, but going forward, it will not. If you have code referencing this item, please revise it. (GTM-8794)

The gtminstall script has a new command line option to skip disablingRemoveIPC=Yes in systemd configuration files. This option was added to facilitate unattended installs and automated builds. Previously, if noresponse was provided, the script would terminate with an error in the script. This issue was only observed in the GT.M development environment, and was never reported by a user.

The configure script better handles the detection of 64 bit software. Previously, the script could mistakenly identify 32bit software as 64bit software if the output of the file command contained "64" in the sha1 binary hash. This issue was only observed in the GT.M development environment, and was never reported by a user.

Additionally the gtminstall script defaults to i586 kit for i686 platforms. Since GT.M V6.2-001, the GT.M release distribution kit has i586 in the name. Attempting to use gtminstall on an i686 platform resulted in a failure to download and install the distribution kit due to this change in name. This issue was only observed in the GT.M development environment, and was never reported by a user. (GTM-8797)

MUPIP ENDIANCVT converts all numeric file header fields to the opposite endian. Previously, it did not convert the Mutex Queue Slots field. (GTM-8798)

gtmsecshr, and facilities that interact with it use message severities that seem appropriate to the issue. Previously, we received customer concerns that the severities were arbitrary, which complicated understanding them. Note that, should you use message parsing that depends on severity, you should review it for possible impact. (GTM-8840)

When TRIGGER_MOD is restricted, attempting to ZBREAK a trigger results in a RESTRICTEDOP error, and both ZBREAK and ZSTEP actions are ignored while executing code within a trigger. Previously a TRIGGER_MOD restriction did not imply these other restrictions. (GTM-8842)

The GT.M restrictions facility recognizes HALT[:<group-name>] and ZHALT[:<group-name>]. When either is present and restriction conditions are met, the restricted command produces a RESTRICTEDOP error. In order to limit pathological looping, if A GT.M process issues a second occurrence of the restricted command within half a second, it terminates after sending a fatal error to both the principal device and the syslog, and also producing a GTM_FATAL* context file, but no core file. Note that, With these restrictions in place, a process should terminate with, for example: ZGOTO 0. with or without a restriction, executing these commands as part triggered logic on a replicating instance may cause the Update Server to terminate and thereby stop replication. As part of this change when ""=$ZTRAP and ""!=$ECODE, ZGOTO 0 returns a non-zero status, derived from the error code in $ZSTATUS, to the shell. If you have an application that uses ZHALT, ZGOTO 0 and shell scripts that check returned status, you should review things in light of this change. Note: with appropriate error handling, an application can use one or both of these restrictions to perform clean up after any explicit HALT or ZHALT. Previously, the restrictions facility did not support these two restrictions, and $ZGOTO 0 always returned a success status to the shell. (GTM-8844)

GT.M appropriately uses file paths with multiple adjacent forward slashes (/) when turning journaling on. Previously, when turning journaling on, GT.M appended inappropriate characters to the end of intended journal file names whose path contained adjacent forward slashes. The workaround was to avoid specifying file paths with any adjacent forward slashes. (GTM-8846)

GT.M defers interrupts during asynchronous database writes. Previously, such interrupts could very occasionally cause a deadlock. This issue was only observed in the GT.M development environment, and was never reported by a user. (GTM-8754)

ZSYSTEM manages memory appropriately; a regression in V6.3-002 caused it to leak small amounts of memory. This issue was only observed in the GT.M development environment, and was not reported by a user. (GTM-8781)

GT.M handles certain unusual cases of local storage (heap) utilization more efficiently. Previously, these cases would cause poor performance as local when adding variables with such patterns. (GTM-8799)

The cmake build produces appropriate support for the ^%YGBLSTATS utility; in the original V6.3-001, V6.3-001A and V6.3-002 releases, an attempt to use ^%YGBLSTATS with a cmake build produced DLLNORTN and ZCRTENOTF errors.(GTM-8801)

Help databases built with make files have QDBRUNDOWN and NOGVSTATS characteristics, which match the properties of help databases of the release builds. Previously, these characteristics differed depending on the build. (GTM-8849)

GT.M correctly cleans up buffers which were allocated prior to a runtime error due to a missing global directory. Previously, these buffers would accumulate if an error handler prevented GT.M from terminating. The workaround for this was to avoid repeated attempts to use a global directory that does not exist or to which the process does not have an authorized path. (GTM-8855)

GT.M handles rare cases in timer handling correctly. Previously these cases could result in SETITIMERFAILED errors and messages in the system log. This was only ever observed in the GT.M development environment and has never been reported from a customer site. (GTM-8887)

The ZHELP command does not report errors after the user presses a <CTRL-C>. Previously, when exiting after a <CTRLC>, the utility reported an UNDEF error and left a GT.M help dump file for analysis. (GTM-8889)