$ORDER(gvn,-1) and $ZPREVIOUS(gvn) appropriately handle the concurrent move of the global variable tree root block of the gvn by MUPIP REORG; previously, this concurrence could occasionally produce a GVORDERFAIL with a status code of tSSS. (GTM-8910)

GT.M avoids superfluous public (ftok) semaphore control operations on database startup or rundown. (GTM-8940)

TPRESTART messages correctly identify the global causing the conflict; previously they could report an incorrect global name. (GTM-8967)

GT.M processes work correctly when a concurrent MUPIP REORG -ENCRYPT encrypts a previously unencrypted database file. Previously GT.M processes could fail with CRYPTOPFAILED errors unaccompanied by other errors explaining the reason for the failure. This issue was only observed in the GT.M development environment, and was never reported by a user. (GTM-8969)

GT.M processes attempting to acquire a shared database resource and encountering long delays continue to wait if the process holding the resource is still active. Previously they intervened prematurely which could cause DBDANGER errors and accompanying database damage. GT.M processes attempting to acquire a shared resource required to perform journal writes and encountering an extended delay in acquiring the resource, issue JNLSENDOPER/JNLFLUSH/JNLPROCSTUCK messages to the system log, and, if so configured, freeze the instance as a result, sending REPLINSTFROZEN/REPLINSTFREEZECOMMENT messages to the system log. They continue to attempt the journal writes, removing the instance freeze if they eventually succeed. Previously, such processes received an error, and the instance required a operator action to release the freeze. (GTM-8974)

GT.M does not decrement database statistics for $DATA(), $GET(), $ORDER(), or $QUERY(). Note that, to minimize performance impact, GT.M updates most database statistics without concurrency controls, so the statistics are approximate and may have brief fluctuations. Previously GT.M made explicit adjustments which reporting was more likely to detect. MERGE operations increment DATA and GET database statistics to more accurately reflect database activity. Previously, Merge suppressed increments to those statistics under certain conditions.(GTM-8992)

If the process has access to an instance file designation, $VIEW("JNLPOOL") returns its name; if the process has not yet opened the pool, the return contains an asterisk after the name. If the process does not have sufficient information to determine a replication journal instance file, the function returns "No replication instance defined." Previously, the function with this argument returned an empty string if the process had not opened the journal pool. (GTM-8930)

A ZGOTO 0 in case of call-in, unwinds all the M stack frames and returns to the invoking C routine. In case of a non-CI invocation, this terminates the process. A gtm_ci invocation without calling gtm_init() first, proceeds with the CI invocation. Previously, this produced 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-8943)

With auto-relink enabled, $TEXT() and ZPRINT use auto-relink when their argument includes a routinename. Note that ZBREAK does not use auto-relink because its intended purpose is as a debugging facility and if the user intends the ZBREAK for a new version they can explicitly request it with a ZLINK. Previously, $TEXT() and ZPRINT used the version most recently linked by the process even if a new version had become available in an auto-relink enabled environment. (GTM-8951)

ZGOTO 0 in a call-in returns to the invoking program. Previously on x86-64 Linux systems with glibc 2.24 or later, this generated a segmentation violation (SIG-11). [x86-64 Linux](GTM-8959)

The path reported by ZSHOW "D", $KEY, and $ZSOCKET("","LOCALADDRESS",) for LOCAL sockets passed via JOB or WRITE /PASS is correct. Previously on AIX 7.2, there could have been extra bytes at the end. This issue was only observed in the GT.M development environment, and was never reported by a user.[AIX 7.2] (GTM-8961)

ZSHOW "I" outputs $ZPIN and $ZPOUT even if they are the same as $PRINCIPAL and no longer displays $ZPROCESS, as it was only meaningful on OpenVMS; also, $ZTNAME appears in proper alphabetic sequence. Previously if $ZPIN or $ZPOUT matched $PRINCIPAL, ZSHOW "I" omitted them, $ZPROCESS appeared as an empty string and $ZTNAME was not ordered appropriately. (GTM-8962)

Pattern match of a string with an alternation match exceeding what GT.M can handle produces a PATALTER2LARGE error; previously this condition produced a segmentation violation (SIG-11). (GTM-8965)

VIEW and $VIEW() with a empty string or inappropriate region-list works appropriately; in V6.3-004 these could cause inappropriate results, including a segmentation violation (SIG-11). $VIEW("statshare") returns a 0 when the process has sharing disabled, a 1 when it has sharing enabled and a 2 when sharing is selectively enabled. In V6.3-004, it did not differentiate between the all and selective cases and returned 1 when sharing was disabled and selective disabling was also specified. $VIEW("statshare","<region>") works appropriately even if the region had been selectively disabled when full sharing is disabled and the region had not been opened. In V6.3-004, this set of conditions produced a segmentation violation (SIG-11). The error messages when invalid parameters are passed to VIEW/$VIEW() print the name of the parameter; previously such error messages did not have the name of the parameter. (GTM-8980)

IF @<literal> works correctly when the literal evaluates to FALSE; in versions V6.3-001 to V6.3-004, it tended to fail with an inappropriate INDEXTRACHARS error or a segmentation violation (SIG-11). (GTM-8981)

The GT.M compiler appropriately handles possible string returns into Boolean expressions from functions with all literal arguments; in V6.3-000 to V6.3-004 it could produce an incorrect result. The workaround was to avoid all literal arguments for $CHAR(), $EXTRACT(), $PIECE(), their $Z*() variants and $SELECT() when they appeared in Boolean expressions. (GTM-8985)

When ZRUPDATE encounters a cycle of symbolic links without finding a specified routine, it treats the same as a simple routine not found and ignores the missing routine. Previously, the command issued an error with text about "too many levels of symbolic links". This issue was observed in the GT.M development environment after upgrading to newer Linux distributions. (GTM-8990)

MUPIP LOAD reports ranges of records not loaded due to missing database files; previously it reported an error for every such record. (GTM-3659)

GT.M supports specifying the M stack size in KiB with the gtm_mstack_size environment variable. No setting or a setting of 0 uses the default (272KiB). The minimum supported size is 25 KiB; GT.M reverts values smaller than this to 25 KiB. The maximum supported size is 10000 KiB; GT.M reverts values larger than this to 10000 KiB. (GTM-4647)

GT.M recognizes setting the environment variable gtm_mstack_crit_threshold to specify an integer between 15 and 95 defining the percentage of the stack which should be used before GT.M emits a STACKCRIT warning. If the value is below the minimum or above the maximum GT.M uses the minimum or maximum respectively. The default is 90. (GTM-5059)

An automatic database file extension, MUPIP EXTEND, INTEG and SIZE all put a message in the system logs when the database reaches 88% of its maximum size. Beyond this 88% threshold, manual and automatic extends only report at 1% intervals, but INTEG and SIZE report at every subsequent invocation while the condition persists. All but the automatic extension also produce the message for the operator. Previously GT.M gave no such warnings, which made it necessary to proactively check on database size. (GTM-7960)

When a multi-thread instance of MUPIP journal -rollback runs out of memory during a rehashing operation, child threads transfer error-handling to the parent thread and terminate themselves. Previously, child threads occasionally failed to report the error, causing MUPIP to halt without a descriptive error message. This issue was only observed in the GT.M development environment, and was never reported by a user. (GTM-8836)

The GT.M restriction mechanism recognizes the following lines:

ZSYSTEM_FILTER[:M labelref]
PIPE_FILTER[:M labelref]

The labelref must include a routine name. If a process is restricted by a ZSYSTEM or PIPE_OPEN line in the restrictions file that restriction takes precedence over the corresponding filter restriction. Otherwise when a process is subject to these restrictions, GT.M inserts an invocation of the labelref prior to the restricted command, passing a string containing the argument to the ZSYSTEM command or the command deviceparameter of the PIPE OPEN. The path to the filter routine must be included in $zroutines. FIS recommends that the filter routine is placed in a location with restricted access such as $gtm_dist. If the filter invocation return is -1,GT.M produces a RESTRICTEDOP error, otherwise it executes the command using the returned string via output parameters as a, possibly identical, replacement for the original string. Since GT.M uses the call-ins mechanism to execute the filters, a filter invocation inside a TP transaction in call-ins produces a CITPNESTED error. Note that because ZSYSTEM and OPEN are not Isolated actions FIS recommends against their use within a TP transaction. Filters also increment the nested level of call-ins. A recursive filter invocation produces a NOFILTERNEST error. GT.M reports all filter errors to the operator log accompanied by a COMMFILTERERR.

An example restrict file for this:

cat $gtm_dist/restrict.txt

ZSYSTEM_FILTER:^filterzsy
PIPE_FILTER:^filterzsy

The actual filter routine:

filterzsy(inarg,outarg);
 if ""=inarg set outarg="-1;must provide a command" quit
 for i=1:1 set arg=$piece(inarg,";",i) quit:""=arg  do  quit:$data(outarg)
 . for  quit:$zchar(9,32)'[$extract(arg)  set arg=$extract(arg,2,9999)
 . set cmd=$piece(arg," ")
 . for restrict="sudo","cd" if cmd=restrict set outarg="-1;command "_restrict_" not permitted" quit
 . quit:$data(outarg)
 . if "echo"=cmd set $piece(arg," ")="echo #",$piece(inarg,";",i)=arg    ;example of modification
 set:'$data(outarg) outarg=inarg
 quit +outarg

Filter execution starts with $STACK=1 ($ZLEVEL=2).

Following are the GT.M commands, Intrinsic Special Variables, and functions whose behavior changes in the context of a filter invocation.

ZGOTO 0 (zero) returns to the processing of the restricted command as does ZGOTO 1 (one) with no entryref, while ZGOTO 1:entryref replaces the originally invoked filter and continues filter execution.

$ZTRAP/$ETRAP NEW'd at level 1.

$ZLEVEL initializes to one (1) in GTM$CI, and increments for every new stack level.

$STACK initializes to zero (0) in GTM$CI frame, and increments for every new stack level.

$ESTACK NEW'd at level one (1) in GTM$CI frame.

$ECODE/$STACK() initialized to the empty string at level one (1) in GTM$CI frame.

After the filter completes, GT.M restores the above to their values at the invocation of the filter. (GTM-8877)

LKE recognizes the full keyword for the -CRITICAL qualifier; previously it only accepted -CRIT. (GTM-8941)

The receiver process recovers after its update process was terminated with a signal while idle. Previously, on Linux systems with glibc 2.25 or newer, the receiver process could hang indefinitely, requiring manual cleanup of the process and shared memory. This issue was only observed in the GT.M development environment, and was never reported by a user. (GTM-8945)

MUPIP JOURNAL -ROLLBACK -FORWARD when executed with -VERIFY properly applies all updates. Previously updates that should have been applied to the database were instead sent to the lost transaction file. The workaround was to execute MUPIP JOURNAL -VERIFY independent of the FOWARD ROLLBACK. (GTM-8953)

The Source Server directs errors to the Source Server log file. A previous fix with GTM-8576 was incomplete and could result in TLS initialization error messages not logged to the server log file. (GTM-8954)

Executing MUPIP SET -NOREAD_ONLY -ACC=BG on a read-only database sets the access mode to BG and turns off read-only. Previously, this action would result in a READONLYNOBG error message and no changes to the file. (GTM-8957)

The TLS reference implementation plug-in disables SSLv3 by default. Previously, customers wishing to disable SSLv3 needed to add the configuration option 'ssl-options: "SSL_OP_NO_SSLv3";' to the "tls" namespace in the $gtmcrypt_config configuration file. (GTM-8958)

MUPIP does not modify -READONLY (MM) database files; previously various MUPIP commands could inappropriately update state information in such database files, causing errors when subsequently using the database. (GTM-8964)

MUPIP RESTORE exits with an error when it encounters an out-of-space condition. Previously, if MUPIP RESTORE encountered an out-of-space condition, if crashed with a segmentation violation (SIG-11). This issue was only observed in the GT.M development environment, and was never reported by a user. (GTM-8988)

MUPIP RUNDOWN works as expected. In rare situations, processes killed during transaction commits could leave the transaction information in an inconsistent state that caused MUPIP RUNDOWN to hang. Note FIS strongly recommends against kill -9 of a process accessing the database as it can induce database damage. This issue was only observed in the GT.M development environment, and was never reported by a user. (GTM-8989)

GT.M issues an fsync on the database file after a region freeze goes into effect, which forces the underlying file system to harden changes to secondary storage. (GTM-8996)

The %DH,%HD,%OH,%HO,%OD, and %DO routines now handle conversions with numbers up to GT.M's maximum string length in size. Additionally, %DH and %DO routines now handle the conversion of negative decimal numbers properly, even when the specified length is not long enough to represent that fully converted number. Previously, the %DH,%HD,%OH,%HO,%OD, and %DO routines could only deal with numbers up to the equivalent of the maximum 18-digit decimal number. Attempting to convert a number larger than this would cause roundoff in the final result, which still occurs if they are used for arithmetic. Moreover, specifying a length for the %DH and %DO routines that was not long enough to hold the fully converted result would cause the routines to produce incorrect values. The workaround for both these issues was to avoid using these percent routines with numbers greater than the maximum 18-digit decimal number and to always specify an appropriate length for the %DH and %DO routines. (GTM-5574)

When a stack frame exceeds the M virtual machine stack pointer, GT.M issues a STACKOFLOW error and produces a GTM_FATAL_* context dump, but no core file, as this an application issue, rather than a GT.M problem. A module with a very large number of variables and/or dynamic literals can cause this problem. Note that the $gtm_mstack environment variable can, within limits, set the size of the M virtual machine stack size. Previously if the overflow was sufficient to make the stack pointer negative, the process exited with a segmentation violation (SIG-11). (GTM-8875)

GT.M avoids superfluous signal management operations. Previously system traces showed more sigprocmask system calls than desirable, particularly on Linux systems with Meltdown/Spectre mitigation in place. (GTM-8942)

GT.M prevents recursive calls to the system memory allocator. Previously, the system memory allocator could be called recursively which resulted in a process hanging. This issue was only observed in the GT.M development environment, and was never reported by a user. (GTM-8949)

GT.M appropriately compiles programs with large numbers of local variable names on 32-bit Linux; previously, compiling a routine with enough local variable names produced an ASSERTPRO and no object file. This issue was only observed in the GT.M development environment, and was never reported by a user. [x86 Linux](GTM-8952)

GT.M uses a lighter weight locking mechanism to protect the relink control file. Previously, a large number of concurrent relink control operations such as those done on process shutdown could cause the system to use an excessive amount of CPU. (GTM-8955)

The GT.M compiler -NOWARNING qualifier for the MUMPS command and $ZCOMPILE suppresses warning messages for BADCHAR, BLKTOODEEP, and LITNONGRAPH; previously it did not. (GTM-8956)

GT.M external call loading is more discriminating about M labelrefs; previously it did not detect all invalid labelrefs, which deferred error detection and made diagnosis more challenging. (GTM-8973)

GT.M appropriately bounds checks variable length input parameters to MUPIP and DSE. Previously it did not detect an off-by-one buffer overrun. Also, MUPIP EXTRACT issues the ICUNOTENABLED warning message when used with the -OCHSET qualifier while in M mode. Previously, attempting to use -OCHSET while in M mode resulted in a SIG-11. These issues were only observed in the GT.M development environment, and was never reported by a user. (GTM-9001)