GT.M defers the hardening (fsync) of a journaled database file (a potentially time consuming operation) to occur as much as possible outside the database critical section, particularly when it is time to write an EPOCH record in the journal file. Previously, this was done while holding the critical section which could affect database transaction throughput. (GTM-5206)

MUPIP INTEG, DSE INTEG and in some instances VIEW "GDSCERT" produce a NONUMSUBS error if they encounter a numeric subscript in a global variable tree that has been defined to only use string subscripts; previously, they did not report this issue. (GTM-6037)

GT.M provides a fast and efficient mechanism for processes to share their database access statistics for other processes to monitor. In addition GT.M now supports implicit instantiation of a database file. Please refer to the Additional_Information section for the details and implications of this feature. (GTM-6699)

Released as field test grade functionality in a production release, asynchronous IO is an option for database segments using the BG access method; previously GT.M performed only synchronous I/O through the file system cache. Also, when invoked from the shell, GDE returns a non-zero status in case it terminates with errors; previously it always returned a zero status, even if it encountered errors. Note: when invoked from GT.M, GDE does not return a status. MUPIP RUNDOWN appropriately manages the FTOK semaphore associated with a database to which it has read-only access; previously it inappropriately removed that semaphore if the database was quiescent but its attachment counter had ever exceeded 32Ki simultaneous processes. Please refer to the Additional Information section for details. (GTM-6838)

When MUPIP INTEG, DSE INTEG -BLOCK, or VIEW "GDSCERT":1 processing encounter an empty-string ("null") subscript that does not match current file header settings for the null characteristic they issue a DBNULCOL or NULLSUBS error. If MUPIP LOAD-FORMAT=BINARY encounters empty-string subscripts in an extract it is loading on a database that does not permit such subscripts, it produces a NULLSUBS error. Previously, these functions did not report these errors (MUPIP LOAD did not load the offending data). Also, if MUPIP LOAD -FORMAT=BINARY encounters two keys that are the same except for their representations of empty string subscripts, it produces a warning message and discards the one whose representation does not match that of the database into which the data is being loaded. (GTM-7857)

Extended references work correctly when poollimit is enabled. Previously, such a combination could produce GTMASSERT failures. This issue was only observed in the GT.M development environment, and was never reported by a user. (GTM-8553)

GT.M protects itself against one type of random error in a control field used for buffer management. Previously, recovery required shutting the database down. The error observed most likely resulted from some sort of hardware malfunction. Note that FIS recommmends the use of ECC RAM in production systems. (GTM-8597)

GT.M issues a ACTCOLLMISMTCH error in case multiple processes concurrently attempt to create the first global node of a global variable using differing collation characteristics (defined through the -GBLNAME section of their respective global directories). Previously, it was possible for processes to proceed to update with conflicting views of the global's collation, resulting in global nodes with misaligned collation sequences in the same global, creating an application level data integrity error. This issue was only observed in the GT.M development environment, and was never reported by a user.(GTM-8613)

$ORDER(gvn,-1) and $ZPREVIOUS(gvn) work correctly in case of spanning nodes. Since GT.M V6.2-002, due to a regression introduced in GTM-7917, it could return the same value as the last subscript in the input key in case the global corresponding to gvn contained spanning nodes. For example if ^X(3) existed and was a spanning node, $ORDER(^X(4),-1) would return 4 instead of 3, potentially leading to infinite loops. If ^X(3) was not a spanning node, $ORDER() would return the correct value. The return value was unaffected by the existence or non-existence of a subtree of ^X(3). (GTM-8641)

GT.M does better in maintaining database integrity in the face of a kill -9 of a process in the middle of a database commit. Previously, if a process trying to update a particular GDS block was killed in the middle of a commit, it was possible to lose prior updates to just that block within the same epoch, resulting in a database file with structural damage. Note that FIS continues to strongly recommend against kill -9 of processes that have opened a database file. (GTM-8655)

GT.M defers performing an idle epoch if it concurrently holds the journal pool critical section lock. Previously, under rare conditions, performing the idle epoch in this situation could result in database deadlock. This issue was only observed in the GT.M development environment, and was never reported by a user. (GTM-8664)

GT.M marks journal files as current or not current, which allows it to deal more appropriately with an operational situation in which an operator renamed an older journal file as current. Previously, GT.M MUPIP ROLLBACK -FORWARD could not detect this operational issue and consequently failed to deliver a consistent state at completion. (GTM-8685)

GT.M now properly handles loading multiple global directories with increasing numbers of regions. Previously, this could have resulted in memory corruption if a process first opened the first global directory with fewer regions AND both global directories had at least one global variable name that spanned multiple regions. This issue was never reported by users and was only seen in the GT.M development environment. (GTM-8687)

Operations on statistics database files (e.g. VIEW "STATSHARE", VIEW "NOSTATSHARE", direct access to ^%YGS global nodes) work correctly even in the case a process accesses the same statistics database file through more than one global directory. In GT.M V6.3-001, this could cause the process to terminate abnormally with a segmentation violation (SIG-11). GT.M correctly creates statistics database files (which are always created dynamically) even in case of heavy database contention amongst processes. In GT.M V6.3-001, if a process in a TP transaction (TSTART/TCOMMIT fence) was in its final retry (due to restarts from other concurrently running processes), it was rare but possible to encounter a deadlock. $ZPEEK issues a BADZPEEKARG error when its argument specifies a non-existent lower-case region name. In GT.M V6.3-001, this terminated the process with a segmentation violation (SIG-11). MERGE, ZWRITE, $DATA(), $ORDER(), and $QUERY() involving ^%YGS open any implicitly associated statistics database files when run outside of a TP transaction. In GT.M V6.3-001, they could ignore ^%YGS nodes corresponding to regions previously unopened or untracked by the process. Note that these operations within an explicit TP transaction do not implicitly open any not-yet-open statistics database until after the transaction commits. GT.M correctly handles a MUPIP SET -REPLICATION=ON for a region which was still replicating after journaling turned off (in the "was_on" state). In GT.M V6.3-001, due to a regression introduced by GTM-7593, an exiting process executing in a small window of instructions in database rundown logic could, in rare, cases terminate with a segmentation violation (SIG-11). MUPIP SET JOURNAL and MUPIP REPLICATE -INSTANCE_CREATE issue appropriate errors when their input attempts to create journal and/or replication-instance file names whose absolute path is more than 255 bytes long. Previously, it was possible for these commands to abnormally terminate with a "stack smashing detected" error due to GT.M-internal buffer overflows. All these issues were only observed in the GT.M development environment, and were never reported by a user. (GTM-8700)

Updates within explicit (TSTART/TCOMMIT) or implicit (spanning nodes or regions, or triggers) transactions requiring one or more additional blocks reliably write before images (if configured) to the journal file or to a MUPIP BACKUP -ONLINE. Missing before images could cause incorrect or damaged databases after a MUPIP JOURNAL -RECOVER or -ROLLBACK, or in a backup. In GT.M V6.3-001, due to a flaw in GTM-8637, in rare cases when choosing a previously freed block, GT.M failed to appropriately write a before image. This issue were only observed in the GT.M development environment, and was never reported by a user.(GTM-8702)

MERGE into a local variable (lvn) target limits the number of target subscripts to the maximum number supported by GT.M (currently 31); previously, MERGE could produce variables with 32 subscripts which could cause subsequent problems. (GTM-6793)

The USE command accepts [I|O]CHSET as valid deviceparameters. It is possible to change the character set of an open device. In addition to USE, the OPEN command also changes the character set of an already opened device including Sequential Disk, SOCKET and terminal devices. It is useful to deal with binary data intermixed with character data. Previously, there was no documented way to change the character set of an open device. (GTM-8254)

GT.M takes the initial value of $ZSTEP from the environment variable gtm_zstep, with a default value of "B" (a BREAK command) if gtm_zstep is not defined; previously, changing the default value required a SET command. (GTM-8357)

TSTART commands with indirect arguments work correctly in GT.M. Previously, they allowed only specification of a single local variable with no parentheses, SERIAL flag or transaction id parameter. Also, use of TSTART in direct mode is prohibited and generates a NODMTSTART error. Previously, TSTART/TCOMMIT sometimes worked when on the same direct mode command line but more often got strange errors and caused memory leaks at best. (GTM-8359)

GT.M assigns an empty string to $REFERENCE when there is an error while constructing a subscripted global variable. Previously, GT.M assigned the last successful subscripted global variable to $REFERENCE. (GTM-8366)

GT.M performs arithmetic operations involving only literals at compile time, with the exception of divide and integer divide (/ and \) by zero (0), which because of their use to intentionally produce an error is left to run time. Note that modulo (#) produces a compile time error. Previously, GT.M did all such calculations at run-time. (GTM-8385)

$ZCOLLATE(glvn,intexpr[,{0|1}]) returns a transformed representation of a first argument glvn using the alternative transform specified by the second argument intexpr that, by default, or if the optional third argument is zero (0), represents a normalized form that can be used as an operand to the follows (]) or sorts-after operator ([[) such that, if both operands are in the normalized form, the result is independent of alternative collation. If the optional third argument is non-zero, $ZCOLLATE() returns a reverse transform of the first argument intended to restore the normalized form to the native M glvn representation. $ZCOLLATE() replaces the "YGVN2GDS" and "YGDS2GVN" arguments to $VIEW(), which are deprecated. $ZATRANSFORM(expr,intexpr[,{0|1}][,{0|1}]) returns a transformed representation of a first argument expr, treated as a subscripted or unsubscripted key, using the alternative transform specified by the second argument intexpr in a normalized form that can be used as an operand to the follows (]) or sorts-after (]]) operator such that, if both operands are in the normalized form, the result is independent of alternative collation. If the optional third argument is non-zero, $ZATRANSFORM() returns a reverse transform of the first argument intended to restore a normalized form to the native M expr representation. By default, or if the optional fourth argument is zero, $ZATRANSFORM()returns the transformation of expr using standard M collation of numbers before strings, causing numbers to sort like strings; if the optional third argument is non-zero, $ZATRANSFORM() treats all expressions as strings.(GTM-8427)

$gtm_etrap and $gtm_trigger_etrap accept up to 8192 bytes and produce a LOGTOOLONG message in the syslog when ignoring a value longer than 8192. Previously, process initialization limited both environment variables to 4096 bytes and did not log any message for an over-length $gtm_trigger_etrap. This issue was only observed in the GT.M development environment, and was never reported by a user. (GTM-8559)

$ZTRIGGER() operations that affect triggers executed in the same transaction work as documented. Previously, in rare situations, transactions that performed $ZTRIGGER() operations in some, but not all, retries and invoked a trigger affected by the $ZTRIGGER() operation in some, but not all, retries could result in a TRIGDEFBAD or SIG-11. Also, trigger load operations in which an error occurred only perform a validity check on trigger delete by name operations. Previously, if an error occurred during a trigger load, a subsequent trigger delete by name operation resulted in a TRIGDEFBAD if the name targeted a trigger installed as part of the current load operation. In addition, concurrent MUPIP REORG works appropriately with GT.M triggers. Previously, in rare situations, a concurrent MUPIP REORG could cause GT.M trigger operations to issue TRIGDEFBAD errors. These issues were only observed in the GT.M development environment, and were never reported by a user. (GTM-8568)

$SELECT() does not pre-evaluate any expressions. A regression introduced in V6.2-002A related to GTM-8376 resulted in inappropriate pre-evaluation of arguments in some cases, especially when both FULL_BOOLEAN and gtm_side_effects modes were off. This caused inappropriate behavior such as errors in $SELECT() formulations intended to prevent execution of inappropriate indirection or $INCREMENT() acting on a global variable. (GTM-8572)

When the argument of an IF command is a literal value or expression, the GT.M compiler generates code to set $TEST appropriately and ignores the rest of the line. When the argument of a command postconditional is a literal value or expression, the GT.M compiler evaluates the postconditional and either generates code for an unconditional command or omits generation for the command. Previously, the computation was performed at run time. Note that literal postconditionals evaluating to 0 result in smaller object modules than literal postconditionals evaluating to non-zero values. (GTM-8573)

As part of compilation, GT.M optimizes unary operations, and binary operations, where both operands are literals; cases where the first operand is an empty string, divide and integer divide (/ or \) by zero (0) are exceptions. In addition, it treats $ZCHSET and $ZVERSION as compile time constants. 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 use variable operands, indirection or XECUTE for operands used with pattern match (?) or sorts-after (]]) if the application changes the run time values controlled by those environment variables. Note that the compiler detects a few errors at slightly different points which may change some messages, hopefully for the better. In addition, this change prevents a possible segmentation violation (SIG-11) in V6.3-000[A] when attempting to MUMPS -RUN of a routine with no current object module when the routine uses ZWRITE. (GTM-8579)

MERGE permits its target to hold the maximum number of subscripts supported by GT.M (currently 31). Beginning with V6.1-000 the change associated with GTM-7867 could cause inappropriate MAXNRSUBSCRIPTS errors when the source and the target were both global variables, most likely when the source had many subscripts. The workaround was to MERGE the source into a local variable and then MERGE from there to the actual target. (GTM-8583)

$QLENGTH(), $QSUBSCRIPT() and $ZCOLLATE() use ZWRITE format to report the namevalue in any NOCANONICNAME error. Previously, a <NUL> byte in the input resulted in a GTMASSERT. (GTM-8584)

GT.M defers certain timed operations while performing a $ZCONVERT(); previously, the function could hang if interrupted by an timed operation that invoked non-reentrantsystem memory management services. This issue was only observed in the GT.M development environment, and was never reported by a user.(GTM-8590)

Deviceparameters on the OPEN command for SOCKET device containing open sockets can modify the ZFF and delimiters of the current socket; previously, these could only be changed with a USE command. In addition, $KEY and $ZB for SOCKET devices appropriately return UTF-8 representations of the characters; previously, if the device character set was UTF-16[BE|LE], the terminator representations were inappropriately also encoded in UTF-16[BE|LE]. (GTM-8593)

In M mode, $ASCII() of literal characters returns the correct value. In V6.3-000/-000A, this returned an incorrect value, typically -1 (it worked correctly for ASCII literal characters, for variable arguments, and in UTF-8 mode). Note that this is an edge case: instead of coding $ASCII() of a literal, one would normally just use the value, e.g., 65 instead of $ASCII("A"), and furthermore, the supported character set for literals in M programs is a subset of ASCII, whereas the issue affected literals corresponding to the non-ASCII characters $CHAR(128) through $CHAR(255). (GTM-8595)

ZSHOW "G" and $VIEW("GVSTAT") report a count BTD, which for database regions that use the BG access method is the number of times a global buffer has transitioned from an clean (unmodified) state to a dirty (modified) state. For database regions that use the MM access method, BTD is zero. (GTM-8639)

GT.M accepts NUL characters ($CHAR(0)) within literals used in indirection and XECUTE; previously, it generated errors for that character. (GTM-8640)

GT.M now reduces the active memory usage when a process uses a large amount of memory then subsequently uses a significantly reduced amount. Previously, active memory usage was distributed across the whole memory segment. In addition, $VIEW("SPSIZE") now returns three sizes (as comma separated values): the total amount of space allocated to the heap, amount of heap space in use, and amount of heap space reserved. The reserved space is used to reduce the active memory usage as mentioned above. GT.M now extends memory used for local variables more frequently when garbage collection does not reclaim a significant amount of space.(GTM-8672)

Name-level $ORDER() on globals maintains $REFERENCE analogously to other $ORDER() invocations, that is: by reflecting the first argument unless a subsequent global reference in the second argument takes precedence; previously, it left $REFERENCE empty except when the second argument was a variable. This also applies to $ZPREVIOUS(), which is a deprecated way to do a $ORDER(,-1). (GTM-8679)

GT.M protects OPEN commands against the possibility they don't complete due to an interrupt or device failure; previously, there was a very small window where external actions such as <CTRL-C>, MUPIP INTRPT, or a device disconnect could leave a device partially set up, which could cause a subsequent segmentation violation (SIG-11). This was only encountered in the GT.M development environment and was never reported by a user. (GTM-8689)

ZSHOW/ZWRITE work correctly even if they encounter a relatively rare heap management action. Previously, these commands could terminate with a segmentation violation (SIG-11) in these rare cases. This issue was only observed in the GT.M development environment, and was never reported by a user. (GTM-8705)

MUPIP BACKUP and INTEG wait approximately one minute for any kill-in-progress to clear. Previously, the times exceeded the documented one minute time by three times for INTEG and an amount for BACKUP that was a function of the number of regions with kill-in-progress indicators; abandoned indicators showed this issue most strongly. These problems were never reported by users and were only seen in the GT.M development environment. (GTM-6598)

GT.M flushes dirty journal and database buffers to disk in a timely manner in a replicated environment. Additionally, the Source Server recovers from an unflushed journal buffer situation by taking on the task of flushing, if needed, every eight (8) seconds while waiting for a journal record in the journal file. It logs a "REPL_INFO : Source server did flush of journal file" message to record such an event. Previously, it was possible in a rare case, involving journal file switches and process exits, for the buffers to stay unflushed causing the Source Server to issue a "REPL_WARN: Check for problems with journaling" alert every 50 seconds. The workaround for this situation was to start a new process that did an update or shut the source server down. (GTM-7593)

GDE ADD, CHANGE and TEMPLATE for REGION objects recognize the -[NO]LOCK_CRIT qualifier; MUPIP SET recognizes a -[NO]LCK_SHARES_DB_CRIT qualifier. Both control whether LOCK actions share the same resource and management as the database or use a separate resource and management. The GDE choice only affects database file creation with MUPIP CREATE. GDE SHOW -ALL and -REGION, and DSE DUMP -FILEHEADER each display the choice, which defaults to Sep(arate)/FALSE. Previously LOCK actions used the same resource and manager. While we expect this to have either no effect or a positive effect on performance depending on the application use patterns, it is different by default, so you should be aware of this change. (GTM-7729)

MUPIP REPLICATE -CHANGELOG waits for up to twenty-five seconds for confirmation from Source and Receiver Server processes that the change succeeded (it may not for a variety of reasons). Previously, only MUPIP REPLICATE -RECEIVER -CHANGELOG waited; MUPIP REPLICATE -SOURCE -CHANGELOG did not. (GTM-7837)

MUPIP EXTRACT appropriately handles the case where a concurrent process updates a spanning node that MUPIP EXTRACT is processing; previously, this situation could cause a segmentation violation (SIG-11). Note that running an EXTRACT without -FREEZE and with concurrent activity produces an inconsistent output (GTM-7922)

MUPIP FREEZE -ON -ONLINE freezes updates to the database file, but allows updates to memory and journal files to continue. As for normal freezes, the Online Freeze is removed by a MUPIP FREEZE -OFF. Online Freeze may only be used on regions with the BG access method.

In the Online Freeze state, GT.M prevents casual database updates from occurring, including background flushing and timed epochs. However, certain conditions require updates to the database file, including full database buffers, journal file switches, and database file extensions. The -[NO]AUTORELEASE option may be used with the -ON option to select the behavior in these conditions, with -AUTORELEASE being the default. If a GT.M process autoreleases an Online Freeze, it sends an OFRZAUTOREL message to the operator log, all processes will be allowed to write to the database file, and a subsequent MUPIP FREEZE -OFF will warn that an Online Freeze had been removed. In this case any database copy or snapshot should be considered suspect and retried. If -NOAUTORELEASE is specified, memory updates will be suspended rather than release the freeze. If a process encounters this situation while holding a critical resource, it will send an OFRZCRITSTUCK message to the operator log and wait, which will prevent other operations on the region. When the Online Freeze is removed by a MUPIP FREEZE -OFF, the waiting process will send a OFRZCRITREL message to the operator log.

Some commands which cannot run with an Online Freeze, e.g., MUPIP BACKUP and MUPIP SET -JOURNAL, will either autorelease or issue an OFRZACTIVE error, depending on the -[NO]AUTORELEASE option used to set the freeze. Other commands, e.g., MUPIP EXTEND, MUPIP REORG -TRUNCATE, and MUPIP INTEG -ONLINE, will either autorelease or hang until the Online Freeze is released.

A MUPIP FREEZE -OFF must always follow a MUPIP FREEZE -ON -ONLINE, even in the case of an autorelease, to ensure that normal operations are resumed. In the case of an autorelease, the MUPIP FREEZE -OFF command will report a OFRZNOTHELD warning.

To maximize the time that updates to memory may continue, MUPIP FREEZE -ON -ONLINE flushes all dirty buffers to disk and performs a journal file switch, but it does not perform a database extension. If a database file is nearly full, the user should consider doing a database file extension before the Online Freeze. When the previous FREEZE operation was -ONLINE, a MUPIP FREEZE -OFF flushes any dirty buffers to disk and performs a journal file switch. These operations are performed in such a way as to minimize impact to processes doing memory updates, but they do involve performing epochs, so there may be some delay to other processes.(GTM-8362)

MUPIP replication servers accept changes to their log file destinations immediately after the last change; previously, they occasionally required a wait between changes. (GTM-8373)

MUPIP DUMPFHEAD [-FILE <file-name>][-REGION <region-list>] provides a way to get substantially the same information as DSE DUMP -FILEHEADER, but in the same format as provided by %PEEKBYNAME, and without connecting to database files. It is both lighter weight than DSE and avoids the need to use DSE, for which operator error can have serious consequences. The formatting is more regular than that of DSE. As MUPIP DUMPFHEAD does not open shared memory, values reported for dynamic fields that are in shared memory may be stale. Because MUPIP DUMPFHEAD is implemented in MUMPS, application code can call getfields^%DUMPFHEAD(varname,dbfilename), where varname is a local variable name passed by reference, and dbfilename is the name of a database file, to generate the records dumped by MUPIP. Note that this facility supersedes ^%DSEWRAP, which is deprecated, is not updated or tested, and eventually will be withdrawn. (GTM-8447)

MUPIP LOAD -FORMAT=BINARY validates the keys in the extract records and reports any errors it detects before skipping the bad record and any following records in the block. Previously, LOAD of a binary extract did not validate incoming keys. (GTM-8542)

The Source Server handles reconnects after errors gracefully. Previously the Source Server could exit with a REPLBRKNTRANs error after an error like REPLNOTLS that causes the Source and Receiver Servers to disconnect in middle of renegotiating the replication starting point. This issue was identified in FIS testing and has not been reported by any customers. (GTM-8547)

MUPIP REORG -ENCRYPT works correctly when reissued after a prior invocation of the same command was interrupted. Previously, if a MUPIP REORG -TRUNCATE was run in between and did truncate the database, it was possible for the reissued MUPIP REORG -ENCRYPT to incorrectly succeed even though it did not finish the (re)encryption. This was particularly evident if one ran a MUPIP SET -ENCRYPTIONCOMPLETE command on the same database which correctly indicated the encryption as incomplete. This issue was only observed in the GT.M development environment, and was never reported by a user. A workaround for this was to run a MUPIP EXTEND on the database and reissue the MUPIP REORG -ENCRYPT. (GTM-8564)

Enabling sync_io for journaling works correctly on XFS filesystems configured with 4KiB sector sizes. Previously, the Source Server could experience a REPLFILIOERR error with the message "Error in reading jfh in update_eof_addr" when reading from journal files. (GTM-8582)

MUPIP JOURNAL -ROLLBACK -FORWARD correctly rolls the database forward in the case one region has a journal file with very limited update activity (less duration than the epoch interval of that region). Previously, it was possible, in the unlikely case of a crash (where the journal files were not cleanly shutdown) where a region had only a single epoch matching the safe restore time determined across all regions, for ROLLBACK to inappropriately set the database file header as if it had restored updates beyond those it actually restored, which could cause a subsequent replication restart to miss updates. This issue was only observed in the GT.M development environment, and was never reported by a user. (GTM-8599)

The error messages for JNLTRANSLSS and JNLTRANSGTR now include the transaction numbers in the database file header and journal file header. The accompanying JNLOPNERR prints the name of the database and journal files. Previously, when issued alongside a JNLSENDOPER message, JNLOPNERR missed information about the database file, and there were no transaction numbers for JNLTRANSLSS or JNLTRANSGTR. The error JNLREADEOF omits the journal file name as the accompanying JNLEXTEND message prints this information.[/p][p]The error messages JNLBADRECFMT, JNLVSIZE, and CRYPTJNLMISMATCH include context information when a process fails to open a journal file for thefirst time. Previously, these error messages did not include some or all of the context information. (GTM-8609)

The Receiver Server handles unusual protocol messages appropriately. Previously, in extremely rare circumstance, the Receiver Server could mishandle such a message and terminate with a segmentation violation or REPLTRANS2BIG error preceded by numerous "Received UNKNOWN message" messages. This issue was only observed in the GT.M development environment, and was never reported by a user. (GTM-8610)

MUPIP LOAD does not terminate abnormally with a segmentation fault (SIG-11) when delivering the MAXSTRLEN error nor does MUPIP LOAD treat a 12 byte header as a MAXSTRLEN error. Previously, a 12 byte header line in a GO or ZWRITE extract could cause GT.M to terminate abnormally with a segmentation fault (SIG-11). The workaround for the short header was to edit it in order to pad the length. (GTM-8612)

The REQROLLBACK message indicates that required -ROLLBACK also requires the -NOONLINE qualifier.(GTM-8614)

MUPIP RESTORE issues an IOEOF error and exits with a non-zero status when supplied with a truncated backup file. Previously, it used to prompt for the next volume to be mounted and later issue a SYSTEM-E-UNKNOWN error and incorrectly exit with a zero status indicating normal exit. Additionally, it cleans up database semaphore ipcs in case of errors; previously left two semaphores per database in case of errors.(GTM-8629)

GT.M considers available process groups when determining permissions based on group membership for IPCs and files, like journals and snapshot files. Previously, when GT.M failed to determine group membership, GT.M inappropriately removed owner access to the IPCs that it created resulting either a PERMGENFAIL error or DBFILERR error followed by the supplemental text "Error with database control semctl SETVAL". (GTM-8654)

The GT.M reference encryption plugin is compatible with OpenSSL 1.1.0. Previously, the plugin would not compile with OpenSSL 1.1.0. (GTM-8656)

GT.M replication appropriately handles the case where a receiving Supplementary Instance (P) connects to a non-supplementary Originating Instance (A) for the first time and then reconnects with no intervening updates. Previously, if the A->P connection occurred twice with no intervening update, replication from P to another receiving Supplementary Instance (Q) failed with a STRMSEQMISMTCH error. (GTM-8657)

GT.M makes more information available to system profiling tools such as perf. [x86_64 Linux] (GTM-8660)

The GT.M reference encryption plugin Makefile copies the pinentry.m routine into $gtm_dist/plugin/gtmcrypt and the GT.M reference encryption plugin pinentry program includes $gtm_dist/plugin/r in the gtmroutines search path. Previously, if the encryption plug-in source archive was not extracted in $gtm_dist/plugin/gtmcrypt, the custom pinentry program failed to load the pinentry routine and the user would be prompted via the system default pinentry program.The GT.M Encryption plugin properly compiles when GT.M is installed without Unicode support. Previously, this would result in the Makefile exiting with an error. The GT.M encryption plugin includes support for loopback pinentry mode (available starting with GnuPG 2.1.12) which simplifies unattended passphrase handling.(GTM-8668)

The GT.M compiler accepts input with <CR><LF> line termination (common on some non-POSIX Operating Systems); previously, it did not. Our thanks to the membership of the May 2016 "Hacking GT.M" workshop for this change. (GTM-4283)

Update Process Reader Helpers operate correctly. Previously, under rare conditions the Reader Helper would encounter a segmentation violation (SIG-11). This was only encountered in the GT.M development environment, and was never reported by a user. (GTM-6085)

Code using literals on Linux on x86_64 is faster, and the generated object file is smaller than previously. Compilation is also faster, which should, in turn, speed up operations using indirection and XECUTE. As with any performance enhancement, actual benefit will vary, depending on the extent to which application code uses constructs that benefit from this change. [x86_64 Linux] (GTM-6332)

The gtmsecshr wrapper on AIX uses the standard system timezone taken from /etc/environment for the timestamps of any syslog entries it generates. It also passes this timezone on to gtmsecshr to use for its entries as well. Previously, syslog timestamps from the AIX gtmsecshr wrapper could be either in the timezone of the process that started gtmsecshr or UTC, depending on whether environment variables had been cleared at the time of the error or not. [AIX] (GTM-7778)

Critical section acquitions are slightly more efficient. [x86_64 Linux] (GTM-8430)

GT.M manages time-related tasks in a more lightweight fashion. On heavily loaded systems with large numbers of processes, this should reduce the number of interrupts and context switches that the operating system needs to process. In addition, GT.M processes time-related tasks in a timely fashion. Previously, in rare conditions, timed operations (e.g., HANG) could be delayed up to eight seconds. This issue was only observed in the GT.M development environment, and was never reported by a user. (GTM-8544)

A GT.M process functions correctly when its M data heap exceeds 2GiB. Previously, such a process could experience damage to internal data structures, leading to incorrect process behavior including process termination with segmentation violations (SIG-11). This issue was only observed in the GT.M development environment, and was never reported by a user. (GTM-8561)

The GT.M configure installation script always creates the plug-in routine source and object file directories. Previously, when installing over an existing directory the installation script did not create the plug-in routine source and object file directories. (GTM-8562)

When directed to install GT.M with UTF-8 support, the configure script defaults to the C.UTF-8 locale when systems have none defined. Previously, the configure script terminated prematurely on such a condition. This was only seen by users building GT.M from source in a restricted build environment. (GTM-8567)

When starting up, the replication Receiver Server only issues a NOMORESEMCNT message to the syslog if it is the first process to determine that more than 32Ki GT.M processes have run in that instance. Previously, in very rare cases, it could inappropriately log a duplicate message. This issue was only observed in the GT.M development environment, and was never reported by a user. (GTM-8569)

The GT.M compiler reduces the size of object modules by not placing literals in an object module once the compilation eliminates a need for them. Previously, it sometimes left obsolete literals in the object files; in V6.3-000[A], GTM-7762 made this a more significant issue. (GTM-8570)

^%GI appropriately handles empty string data values in GO format input. In V6.3-000 and V6.3-000A, ^%GI ignored such input, leading to incorrect loads. The workaround was to use ZWR format or MUPIP LOAD. (GTM-8571)

^%PEEKBYNAME() handles cases where the type of data it is to access is an array of known types by returning a comma delimited list of the array elements; for example, $$^%PEEKBYNAME("sgmnt_data.tp_cdb_sc_blkmod",base) returns a string in the form "0,0,0,0,0,0,0,0" because the arguments identify an array of 8 integers (type int). Previously, this kind of invocation produced a BADZPEEKFMT error. (GTM-8578)

GT.M briefly defers certain operations while processing character input; previously, the non-reentrant system memory management services used in character-based input could hang a process if their timed operations also invoked memory management services. (GTM-8598)

MUPIP JOURNAL accepts multiple EOF records in the same journal file. Multiple EOF records only occur when the last process to halt out of a journaled database terminates abnormally just before cleanly shutting down the journal file. Note that FIS strongly recommends against using kill -9 on any GT.M process performing database updates. Previously, MUPIP JOURNAL produced a GTM-E-JNLUNXPCTERR error when it encountered multiple EOF records in a journal file. (GTM-8602)

GT.M prevents certain timed operations during external calls. Previously, in an environment using encrypted databases,an external call could cause the process to hang due to an invocation of non-reentrant memory management system services also invoked by the encryption plug-in. (GTM-8615)

The gtm_coredump_filter environment variable specifies the mappings of the process address space for a GT.M process, with the bits having the same meaning as those specified for /proc/<pid>/coredump_filter in "man 5 core". If unspecified, GT.M uses a value of 0x73; a value of -1 prevents GT.M from modifying the coredump_filter value. A running process can change its coredump_filter by writing to the file /proc/<pid /coredump_filter, and can query the current value by reading that file. [Linux x86_64] (GTM-8632)

Processes handle a large volume of TP updates appropriately; previously, a long-running process, such as an Update Process, adding new global nodes could eventually inappropriately terminate with a GTMASSERT2. (GTM-8637)

GT.M appropriately handles the case of a process receiving a MUPIP STOP while another process has recently been performing a MUPIP REORG -ENCRYPT to change the encryption keys. In V6.3-000[A] this combination could rarely cause the stopped process to terminate with a GTMASSERT2 error. This caused no problems for the database. This issue was only observed in the GT.M development environment, and was never reported by a user. (GTM-8642)

GT.M more accurately maintains the count of the number of processes attached to a database file $$^%PEEKBYNAME("node_local.ref_cnt",<region>) or "Reference count" in DSE DUMP -FILE output. Note that GT.M does not rely on this field, which exists to supply operational information to the user, but which may be inaccurate if processes are subject to kill - 9 - something that FIS recommends against and that GT.M does not guard against. Previously, in case the database has the quick-rundown mode enabled (MUPIP SET -QDBRUNDOWN), this counter could become inaccurate even without interference from kill -9. (GTM-8645)

When GT.M exits with a fatal error, such as GTM-F-MEMORY, it cleans up any empty file it was in the process of creating at the time of the failure. This applies to GT.M OPEN, DSE OPEN and a number of MUPIP functions which create files. Previously, this unusual situation left an empty file and in some cases the process terminated with a segmentation fault (SIG-11). (GTM-8659)

GT.M correctly marshals parameters when calling out to external Java libraries and programs. Previously GT.M over allocated the parameter space and in rare situations an overrun could occur. This problem was never reported by a customer and was only seen in development. (GTM-8669)

DSE FIND -KEY reports the correct path leading to the input key. For versions V6.0-000 to V6.3-000A, due to a regression introduced by GTM-6341, it sometimes reported an incorrect Global tree path if the input key is not found in the database file. (GTM-8676)

^%TI works as documented; previously, it rejected some documented forms. (GTM-8686)