As a potential performance enhancement for applications that are limited by journal writes, with the BG access method, GT.M writes journal and replication information while holding a more granular resource, that is: after releasing control of the region, but while it still has control of the block associated with the update. This change does not apply to MM access method processing . Previously GT.M updated the journal and replication streams while holding the resource associated with the region. (GTM-8436)

When it can, GT.M takes a lightweight approach to initializing encryption resources. Previously many processes concurrently attaching to an encrypted database could cause some of them to exit with a SEMWT2LONG error. (GTM-8690)

When GT.M encounters an error creating an autoDB database (including those used to store statistics), it issues a MUCREFILERR which identifies the application code entryref where it encountered the issue followed by the underlying error. Previously the it only supplied the underlying error with no context as to where it occurred. In addition, if GT.M encounters an error running down a statistics database, it reports the error to the syslog; previously reported to the user's device. (GTM-8698)

GT.M avoids premature epochs after a period of no updates. In particular, the update process writer helper avoids retrying the epoch repeatedly. (GTM-8708)

A DBIOERR error message displays additional diagnostic information when it is available. Previously, it did not display some available error context. (GTM-8755)

MUPIP BACKUP -ONLINE produces an integrity error free backup even after inappropriate killing of MUMPS processes. Previously under rare circumstances, killing MUMPS processes while an online backup was in progress could produce a database file with DBTNTOOLONG integrity errors. This issue was only observed in the GT.M development environment, and was never reported by a user. (GTM-8759)

GT.M source lines, XECUTE strings and Direct Mode input all accept up to 8192 byte values. In the case of source, the length includes the terminator(s). In the case of Direct Mode, the WIDTH and/or WRAP deviceparameter characteristics may cause a lower limit. Previously the limit for source lines was 8191, and 1024 or less for the other two. (GTM-8281)(GTM-4851)

GT.M reports BLKTOODEEP errors as warnings, including FOR lines with multiple leading dots (levels) underneath an undotted line (current level of zero). These new reports may identify latent issues in existing code. Previously GT.M reported some BLKTOODEEP cases as errors but did not report lines with multiple dots when the current level was zero, but rather silently ignored such lines. (GTM-5178)

For JOB, LOCK, OPEN and READ commands, and $gtm_tpnotacidtime, GT.M supports fractional timeout values to millisecond precision with timeout values capped at 999,999.999 seconds (about 11.5 days); higher timeout values execute with the capped value. Previously GT.M supported timeouts as integers (GTM-5250)

GT.M compiles XECUTE <literal> at compile time when the literal is valid GT.M code that has minimal impact on the M virtual machine. An XECUTE literal containing GOTO, NEW, QUIT, (nested) XECUTE and indirection cannot be precompiled because of the interaction of those features with the stack architecture of the M virtual machine. Precompiled XECUTE literals do not show up in $STACK() as having a separate stack level, but rather "disappear" into the stack level of the original XECUTE. Please observe the following cautions: ensure you compile with the same GT.M version, $gtm_chset, $gtm_local_collate, $gtm_patnumeric, $gtm_pattern_file and $gtm_pattern_table values (or lack thereof) as those used to run your application, and, if the application changes the run time values controlled by those environment variables, use variable operands or indirection, rather than literals for operands with pattern match (?) or sorts-after (]]). While we do not expect much impact on existing code, it is possible that an application that makes unusual use of XECUTE might require some rework. Note that indirection almost always performs better than an XECUTE that cannot be precompiled. Note also that adding a QUIT at the end of an XECUTE that does not contain a FOR will leave it for run time compilation. Previously an XECUTE that had not recently been used was always compiled at run-time. (GTM-5754)

GT.M releases the database critical section and reports TPNOTACID for timed WRITE /* operations subject to timeouts that exceed gtm_tpnotacidtime when $TRESTART>2. Also, gtm_tpnotacidtime recognizes millisecond fractions of seconds; previously the value was truncated to whole seconds. FIS strongly recommends avoiding coding that violates the ACID transaction properties, particularly Isolation. Previously non-Isolated WRITE /* operations could allow a process to hold the database critical section for an indefinite period. In addition, TPNOTACID errors report the timeout; previously they did not. (GTM-8165)

Addressed by GTM-4851 (GTM-8281)

The ZSYSTEM command always invokes shell specified by the SHELL environment variable; previously it was possible to construct arguments that did not. In addition, ZSYSTEM arguments handle quoting (both single and double) in a more straightforward way. This may require changes to existing code to simplify quoting. An example where a change may be needed:

GTM> zsystem "echo '""hello world""'"
hello world

will now produce:

GTM> zsystem "echo '""hello world""'"
"hello world"

and should be changed to:

GTM> zsystem "echo 'hello world'"
hello world

to get the same output. (GTM-8644)

$SELECT() appropriately handles an argument where a truthvalue made up of literals precedes a syntax error, as well as arguments where a literal FALSE truthvalue conditionalizes a global reference which a later argument also references. Due to a compiler optimization in V6.3-001[A], such an error produced a segmentation violation (SIG-11), and the other case produced a GTMASSERT2. (GTM-8717)

Attempting to set an invalid string into $ZROUTINES leaves the previous value of $ZROUTINES as it was. Previously, this could cause issues if auto-relink was in use, resulting in a segmentation violation (SIG-11). This issue was only observed in the GT.M development environment, and was never reported by a user. (GTM-8718)

Using indirection in a setleft which uses $INCREMENT() to create an indirect source value on the right works appropriately. While this worked as expected with gtm_side_effects defined to a non-zero value, with a default or zero (0) setting of that compiler characteristic, due to a regression introduced in V6.0-001, an right hand expression with a side effect could cause an inappropriate order of evaluation, which typically manifested as misbehavior around undefined variables, either reporting UNDEF when it should not or not reporting UNDEF when it should. (GTM-8720)

In NOUNDEF mode a naked reference using an undefined value as a subscript behaves appropriately; previously it could cause a GTMASSERT2 fatal error, or, in case of a name-level $ORDER(), return the first global name in the global directory. Note that, at least, syntax errors or UNDEF errors leave the naked reference at the point of the last valid subscript. While this is non-standard, it can be useful for debugging, would introduce inefficiencies to change, and has not, to date, generated any concerns from users. (GTM-8727)

$ZCONVERT() operates appropriately in UTF-8 NOBADCHAR mode; previously it issued an error. As a consequence the pinentry script operates correctly. The pinentry issue was only observed in the GT.M development environment, and was never reported by a user. Note that defining the gtm_ztrap_form environment variable to the empty (null) string sets ZTRAP handling to adaptive, while leaving it undefined sets the handling to "code" which can cause entryref device exception or ZTRAP handlers to fail with the error INDEXTRACHARs. (GTM-8733)

If the $gtmroutines environment variable is not defined, GT.M defaults $ZROUTINES to "." - meaning the current working directory; previously in this case, GT.M defaulted $ZROUTINES to "" which had the same effect, but was not as clear. (GTM-8736)

LOCK of an argument within a parenthetical list where the argument includes an extrinsic function that performs LOCK actions produces a BADLOCKNEST error except where there is only one such argument, it is the first argument in the list and the LOCK'ng as a consequence of the extrinsic function(s) is simple. Previously this construct could produce an unintended LOCK state or a segmentation violation (SIG-11). Note that this pattern may still produce some unintended outcomes, so FIS recommends against its use. This change also slightly modified a handful of LOCK-related error messages with the intention of improving their clarity. (GTM-8738)

The GT.M compiler handles nested Boolean operations that include literal operands appropriately; this corrects a flaw in the Boolean optimizations introduced in V6.3-001[A] that, given certain patterns of multi-level nesting could produce an inappropriate UNIMPLOP error, and, in some cases, incorrect results. (GTM-8743)

GT.M now properly handles environment variables whose contents is over 32K in size. GT.M reports an error if the content is larger than can fit in a local or global. Previously, environment variables whose contents was over 32K in size resulted in a SIG-11. This issue was only observed in the GT.M development environment,and was never reported by a user. (GTM-8760)

MUPIP BACKUP -BKUPDBJNL=OFF does not adjust the journaling state for a database with journaling disabled. Previously, -BKUPDBJNL=OFF turned off journaling in the backup database even when journaling was disabled, which required an extra step to explicitly reestablish the disabled journaling state characteristic for regions in the restored database that originally had journaling disabled. (GTM-6657)

Addressed by GTM-8694 (GTM-7638)

When creating, renaming and deleting journal files, GT.M processes send all status results to syslog correctly naming the files involved. Previously, only MUMPS processes sent this status information to syslog while MUPIP processes wrote the information to STDOUT. Additionally during a rename, GT.M creates an intermediate temporary file; previously, some messages did not include the intermediate file name. (GTM-8543)

MUPIP RUNDOWN with no arguments logs a message in the syslog facility with information about its actions including the process ID, user ID, and its current working directory. This may be useful for investigating any case where RUNDOWN inappropriately removes a GT.M shared memory segment or semaphore (IPC). Previously RUNDOWN did not provide such information. (GTM-8616)

Post installation, a system administrator can optionally add a restrict.txt file in $gtm_dist to restrict the use of certain GT.M facilities to a group-name. The owner and group for $gtm_dist/restrict.txt can be different from those used to install GT.M. The file may contain zero or more of the following case-insensitive lines in any order:

BREAK[:<group-name>]
ZBREAK[:<group-name>]
ZCMDLINE[:<group-name>]
ZEDIT[:<group-name>]
ZSYSTEM[:<group-name>]
CENABLE[:<group-name>]
PIPE_OPEN[:<group-name>]
DIRECT_MODE[:<group-name>]
DSE[:<group-name>]
TRIGGER_MOD[:<group-name>]

If the file $gtm_dist/restrict.txt does not exist, GT.M does not restrict any facilities.

Any non-empty lines that do not match the above format cause processes with read-only permission to behave as if they could not read the file, and GT.M enforces all restrictions.

Restrictions apply as follows:

If the file exists, a process:

Note that restricting $ZCMDLINE prevents things like: mumps -run %XCMD 'for read x xecute x' which can act as substitutes for Direct Mode. (GTM-7638),(GTM-8694)

GT.M installation script, gtminstall, accepts icu version input in the form of <major><minor>.<milli>.<micro>, which matches the convention and output of icu-config −−version, for ICU versions 49(4.9) and later. Previously gtminstall only accepted <major>.<minor>.(GTM-8704)

When invoked from the shell, GDE appropriately maintains the return status; previously it did not. Also, the GT.M help facility handles an EOF on $PRINCIPAL; previously an EOF produced an internal error and generated an associated context dump file. (GTM-8711)

If gtminstall finds the environment is a Linux installation using systemd, it prompts the user for permission to insert addRemoveIPC=no into /etc/systemd/logind.conf and restart logind; if the user refuses, gtminstall stops the installation after issuing instructions on how to perform the task independently, and information on why it is necessary. (GTM-8714)

GT.M releases include a gtmpcat_for_{release} kit which contains the files required to run gtmpcat against the released GT.M version. The install_gtmpcat.sh script included in the kit may be used to install the files in $gtm_dist/tools/gtmpcat. After installation, $gtm_dist/gtmpcat may be used to run gtmpcat. Note that the gtmpcat_for_{release} kit does not contain files necessary for analyzing other GT.M releases. Full gtmpcat releases contain these files for all supported production GT.M releases as of the gtmpcat release date. (GTM-8726)

MUPIP JOURNAL -SHOW displays the characters representing the first 12 bytes of the userid and the first 16 bytes of the node name. Also, it does not print trailing spaces after the time-stamp. Previously it truncated userid to eight bytes, the node name to 12 bytes, and put 19 trailing spaces after the time-stamp. (GTM-8737)

The command MUPIP REPLIC -SOURCE -JNLPOOL -SHOW displays whether the custom errors file is loaded. Previously the only mechanism to check this was via ^%PEEKBYNAME (available since V6.3-000) or $ZPEEK(). The following returns 0 when Instance Freeze is not enabled and 1 when it is:

    
$$^%PEEKBYNAME("jnlpool_ctl_struct.instfreeze_environ_inited")

When no prior custom errors file has been previously loaded, a Source Server starting with the gtm_custom_errors environment variable pointing to a file loads the contents of the file and thus enables Instance Freeze without performing a complete shutdown. Changing a previously loaded set of custom errors requires starting from a complete shutdown state. Previously if the Source Server initializing the replication journal pool was started without the gtm_custom_errors environment variable defined, enabling Instance Freeze by loading custom errors required a restart from a complete shutdown state. (GTM-8740)

GT.M does not update journals associated with an original database when working with a backup copy on the same system. V6.3-001A introduced an unintended change such that a MUPIP JOURNAL -{RECOVER|ROLLBACK} -FORWARD of the backup database marked the current journal of the original database as not current. This issue was only observed in the GT.M development environment, and was never reported by a user. (GTM-8742)

When the environment variable gtm_fullblockwrites is set to two (2), a process writes all newly allocated database blocks in their entirety regardless of their actual valid contents. This relieves some file systems from tracking potentially significant fragments of unallocated space, and thus reduces file system metadata maintenance. When this value is set to one (1) a process writes entire file system blocks in their entirety regardless of their actual valid contents, on some file systems, this avoids reading in advance of most writes and thus reduces file system load and increases response time. Note that when the file system block size and the database block size are the same there is no difference between the settings of 1 and 2. If the environment variable is undefined or zero (0), a process writes only valid data. FIS advises using the same value for all processes. Previously GT.M only recognized values of FALSE (0) or TRUE (non-zero) and equivalent to 1. (GTM-8753)

The GT.M installation script, configure, works appropriately on AIX configured to rely solely on the default ICU libraries. Previously, attempting to install GT.M with ICU support on AIX failed when it had only the default ICU libraries. (GTM-8756)

MUPIP JOURNAL -{ROLLBACK|RECOVER} -FORWARD handles interrupts to worker processes correctly. Previously, a worker process which was interrupted immediately after being started attempted to perform cleanup operations on the database which should only be performed by the main process, which could lead to undefined behavior. This issue was only observed in the GT.M development environment, and was never reported by a user. (GTM-8763)

GDE and MUPIP produce errors in response to an attempt to set global buffers higher than the maximum supported. Previously GDE accepted unsupported specifications and MUPIP could give a segmentation violation (SIG-11) error. This issue was only observed in the GT.M development environment, and was never reported by a user. (GTM-8766)

GT.M deals with an apparent deviation from documented POSIX behavior when using xfs with -NODEFER_ALLOCATE. Doing a -NODEFER_ALLOCATE extension, GT.M requests only new space. The exception is that an explicit MUPIP EXTEND -BLOCK=0 extension does request full allocation of existing space, which might be of interest when first selecting -NODEFER_ALLOCATE on an existing file. It's not clear whether the choice of file system or its tuning affect the response to this request. Previously in -NODEFER_ALLOCATE mode, xfs could fail to extend database files with a GBLOFLOW error even though there was sufficient space available. (GTM-8771)

GT.M protects the UNIX user information it maintains; previously, external calls could damage the information by using the getpwuid() service, which could result in unintended behavior. (GTM-8415)

MUPIP JOURNAL -PARALLEL correctly handles a MUPIP STOP when using multiple process to work in parallel. Previously, in the rare case the stop arrived while MUPIP was creating such processes, the processes could write their FORCEDHALT messages concurrently, resulting in garbled and/or lost output. This was a cosmetic issue that did not affect the correctness of the MUPIP JOURNAL command , was only observed in the GT.M development environment, and was never reported by a user. (GTM-8663)

DSE CACHE -VERIFY avoids certain spurious DBBSIZMN errors; previously, under rare circumstances, it produced such an inappropriate error. This issue was only observed in the GT.M development environment, and was never reported by a user. (GTM-8713)

GT.M correctly handles multiple processes opening and closing a relinkctl file (the file name indicated by ZSHOW "A") as part of process startup and shutdown respectively. Previously, it was possible in rare cases for a process to terminate with a SIGBUS error (kill -7) while trying to open an relinkctl file. This issue was only observed in the GT.M development environment, and was never reported by a user. (GTM-8724)

Starting replication on a supplementary instance works appropriately after a prior fetchresync rollback removed all updates from the non-supplementary originating instance. Previously, a receiver startup in this case incorrectly resulted in a REPLINSTNOHIST error. This issue was only observed in the GT.M development environment, and was never reported by a user. (GTM-8730)

GT.M distributions are built on RedHat Enterprise Linux 7 x86_64, Debian Linux 9 x86_32, and AIX 7/POWER 7. Previously, GT.M was built on RedHat Enterprise Linux 6 x86_64/x86_32 and AIX 6/POWER 5. (GTM-8745)