Processes execute substantially less logic when exiting database files opened with the BG access method. Previously process exit involved more checking, which could significantly slow the exit and consume CPU resources potentially usable by other processes, behavior which was most visible when a large number of processes concurrently attempted to exit databases with large numbers of regions and large numbers of global buffers per region. (GTM-6301)

A process with read-only access run on an otherwise unaccessed database that was not shutdown in an orderly fashion, due to for example a kill -9, attached processes exceeding 32Ki, etc., leaves shared memory intact. Previously, such a process could cause the loss of the shared resource and, under some circumstances, updates it contained. (GTM-7608)

GT.M uses non-zero, context-sensitive, initialization vectors (IVs) when it encrypts or decrypts databases, journal files, binary extracts and bytestream backups; previously it used empty (all zeros or "NULL_IV") initialization vectors.

MUPIP EXTRACT -FORMAT=BIN accepts a -NULL_IV qualifier and generates extracts in the following formats:

MUPIP BACKUP -BYTESTREAM in V6.3-000 uses level format 8 for an encrypted region and level format 9 for an unencrypted one (i.e., the first 5 characters of the label are "GDSV8" or "GDSV9", respectively). Bytestream backups created from a database with a particular minor version can only be restored onto a database with the same minor version. In case of a minor version mismatch GT.M issues the MUPRESTERR error with a descriptive addendum.

Journal and database file header dumps, produced using MUPIP JOURNAL -SHOW=HEADER and DSE DUMP -FILE -ALL, respectively, report whether an all-zero IV (NULL_IV) is in use.

Additionally, ZSHOW "D" displays the name of the encryption key and IV type for each file device that has its input, output, or both streams using encryption.

Please note:

(GTM-8117)

Processes starting up with an Instance Freeze in place can proceed up to their first attempt to perform an update. Previously, if all processes accessing a database region which was a member of a frozen instance had been shut down with a SIGTERM, subsequent processes could hang attempting to connect to that database region, even if their actions did not involve updates. This issue was partially addressed in V6.3-000, but the Source Server could incorrectly rundown database regions on frozen instances, leading to the hang. (GTM-8177)

The gtm_nontprestart_log_delta and gtm_nontprestart_log_first environment variables control whether and how GT.M sends to the syslog NONTPRESTART messages that supply information on non-TP "mini transaction" restarts. If $gtm_nontprestart_log_delta is a non-zero integer, GT.M uses the value as a sampling interval for the messages, so a value of one (1) produces a report for every non-TP restart, a value of two (2) means a report for every other non-TP restart, etc. If $gtm_nontprestart_log_delta is defined as described and $gtm_nontprestart_log_first is also a non-zero integer, GT.M reports the first $gtm_nontprestart_log_first non-TP restarts before reporting samples as defined by $gtm_nontprestart_log_delta. Previously, GT.M did not provide detailed information for non-TP mini-transactions, but it did provide cumulative restart non-TP mini-transaction restarts using the NR0, NR1, NR2, NR3 fields in the ZSHOW "G" output. In addition, if the restart occurs due to a conflict in the global directory tree, the TPRESTART message reports "*DIR" for the glbl field. Previously, in that case, it displayed only "^" with no global variable name. TPRESTART messages include the subscript of the contested global. Previously, it reported global names without any subscript information. VIEW [NO]LOGN[ONTP][:intexpr] allows a process to dynamically change the logging to the syslog of NONTPRESTART messages established at process startup by the environment variables gtm_nontprestart_log_delta and gtm_nontprestart_log_first. VIEW "NOLOGNONTP" turns off the logging of NONTPRESTART messages to the syslog. VIEW "LOGNONTP"[:intexpr] turns on logging of NONTPRESTART messages to the syslog. If no intexpr is specified, GT.M uses the value of environment variable gtm_nontprestart_log_delta, if it is defined, and one (1) otherwise (that is, log every transaction restart). A negative value of intexpr turns off the logging of NONTPRESTART messages. Note that it is not possible to perform the operations of gtm_nontprestart_log_first with VIEW "LOGNONTP"[:intexpr]. (GTM-8190)

Encryption initialization is faster for databases with multiple encrypted regions, with the improvement more noticeable as the number of regions increases. To facilitate this performance improvement, GT.M requires the encryption configuration file (referred to by $gtmcrypt_config) to specifically associate the key used by each database file with that database file name, raising an error if an entry mapping the key to the file does not exist. Previously, GT.M accepted any key with a hash matching that in the database file header, even a key that was not specifically mapped to a database file name that used it. This enhancement benefits from changes to the API of the encryption plugin. (GTM-8336)

Update helper writer processes increase replication throughput, decrease backlog, and improve manageability:

(GTM-8340)

$ZTRIGGER() and MUPIP TRIGGER delete all, "-*", operations delete malformed trigger records, identifying such malformed trigger records with TRIGDEFBAD warnings. Previously trigger delete ignored some malformed triggers making them undeletable. In some cases, attempts to view (SELECT) these malformed triggers failed, making them invisible as well. The workaround was to extract all triggers to a file, add a trigger for each global variable with a trigger, followed by a delete all, "-*". This deleted all triggers and restored the desired triggers in one transaction. (GTM-8399)

$ZTRIGGER()and MUPIP TRIGGER appropriately delete triggers as specified; previously under rare circumstances, they silently failed to do so. This issue was only observed in the GT.M development environment, and was never reported by a user. (GTM-8457)

Processes that have read-write access to a journaled database file, but have not yet performed any updates to it (i.e., processes that have not yet opened the journal file for that database file), cooperate correctly with processes that have read-write access and have performed updates. Previously, it was possible for the former to pick up all available slots for flushing dirty buffers (the default being two slots), resulting in an out-of-design situation where dirty buffers did not get flushed in a timely manner, in turn resulting in the Source Server terminating with a SEQNUMSEARCHTIMEOUT error. Additionally, the Source Server issues an alert every 50 seconds (instead of 10 seconds previously). (GTM-8489)

KILL of a global outside of a TP transaction following a large TP transaction with certain characteristics by the same process works correctly; previously this unusual sequence could terminate a process with a segmentation violation (SIG-11). Database structural integrity was not at risk from this behavior. (GTM-8499)

GT.M does not internally deadlock in the presence of certain rare, asynchronous events, as it previously could in releases V6.0-003 through V6.2-002A. This issue was only observed in the GT.M development environment, and was never reported by a user. Note that the design of GT.M precludes deadlocks in normal usage. (GTM-8500)

MUPIP, LKE, and DSE no longer issue NOCHLEFT fatal errors while handling errors in database disconnect which occur during process shutdown. (GTM-8501)

GT.M processes no longer deadlock when a trigger causes a fatal error, under certain unusual conditions. This issue was only observed in the GT.M development environment, and was never reported by a user. (GTM-8506)

TP transactions work appropriately for MM access databases when there is a concurrent database file extension. Previously, in rare cases these circumstances caused GT.M to terminate 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-8523)

GT.M issues a JNLPOOLSETUP error if/when 32Ki processes open the journal pool and the corresponding replication instance file does not have -qdbrundown enabled. In GT.M V6.3-000, the GT.M process used to terminate abnormally with a SIG-11 while trying to issue the error. (GTM-8535)

Replication works correctly when the replication instance file has -qdbrundown enabled and some processes in the instance have read-only access to the replication instance file. In V6.3-000, if the 32,768th process accessing the instance had read-only access to the replication instance file, it would issue a REPLINSTOPEN error, and hold internal locks on the Journal Pool and instance file, resulting in hangs and MUTEXLCKALERT messages from other processes. A value of 1 returned by $$^%PEEKBYNAME("node_local.ftok_counter_halted",region) means that the number of processes accessing the region ever reached 32,768, resulting in the counter no longer being maintained. Similarly, a value of 1 returned by $$^%PEEKBYNAME("jnlpool_ctl_struct.ftok_counter_halted") means that the number of processes attaching to the Journal Pool reached 32.768, again resulting in the counter no longer being maintained. A value of TRUE in the "CTL FTOK Counter Halted" field of the output from MUPIP REPLIC -SOURCE -JNLPOOL -SHOW also shows the Journal Pool information. DSE and LKE now send any RESRCWAIT messages to the syslog. Previously, they used to display such messages in their output. (GTM-8538)

With epoch tapering enabled, GT.M issues a single fsync in preparation for an epoch; previously it could issue a number of fsyncs prior to the epoch. This issue was only observed in the GT.M development environment, and was never reported by a user. (GTM-8539)

LOCK (and ZALLOCATE) issue a LOCKTIMINGINTP warning message to the syslog when a process fails to acquire a LOCK within a critical resource holding retry of a TP transaction. Unlike TPNOTACID warnings, which signal the release of critical resource, LOCKTIMINGINTP does not indicate a release of resources. Such a LOCK must have a timeout less than gtm_tpnotacidtime, or, if undefined, its default of two (2) seconds, which should limit the duration of the resource blockage it causes; a timeout of 0 (zero) prevents this warning. Note that FIS recommends avoiding the use of LOCK commands within TP transactions. Previously, the described condition produced a TPNOTACID warning with its accompanying release of resources, which made the transaction more likely to make repeated restarts. (GTM-8546)

GT.M avoids holding a critical shared resource on database regions and the journal pool longer than necessary. Previously, a non-TP transaction on a replicated region which processed a timed epoch would hold the resource on the journal pool while processing the epoch, and a process in the final retry of a transaction could frequently sleep or yield the processor, potentially repeatedly, while holding the resource on the database region. (GTM-8554)

GT.M is silent about implicitly assigning the current global directory to a value that identifies an inaccessible file. Note that attempting to use such a value for a global directory continues to produce a ZGBLDIRACC error. Previously, with such a $ZGBLDIR value, a QUIT after a NEW $ZGBLDIR resulted in a STACKOFLOW error and a valid external reference produced an inappropriate ZGBLDIRACC error. (GTM-4759)

ZMESSAGE accepts an indirect argument. Previously this syntax produced a GTMASSERT. (GTM-6114)

In an M mode process, a WRITE to a sequential device after a SET $X to a value greater than the device WIDTH or a reduction in WIDTH to less than the current $X acts as if the first character caused $X to exceed the WIDTH inducing an immediate WRAP, if WRAP is enabled. Previously, $X exceeding WIDTH in an M mode process caused a SYSTEM-E-ENO14, Bad address error. (GTM-7060)

$ZWRITE() accepts a second intexpr which specifies the direction of the conversion. No value or a zero value converts the first argument to ZWRITE format and a non-zero value converts the first argument from ZWRITE format to a string with embedded non-graphic characters. In addition, $ZWRITE() now takes the cannonical or non-cannonical nature of its first argument into account; previously it attempted to treat non-canonical numeric values as numbers rather than strings, which caused errors and inappropriate results. Also if all its arguments are literals, $ZWRITE() evaluates to a literal constant at compile time. Previously $ZWRITE only accepted a single argument, converting only to ZWRITE format, and always evaluated at run time. (GTM-7604)

The GT.M compiler resolves some expressions involving string literals at compile time, reducing both code size and run time CPU requirements. Currently the compiler does this for concatenation operations, $[Z]ASCII(), $[Z]EXTRACT(), $[Z]PIECE(), and $ZSUBSTR(). For code compiled in UTF-8 mode, this means that the compiler can report BADCHAR warnings for strings that are not legal UTF-8 strings, where previously it did not. The compiler flags these as warnings, rather than as errors, since the possible difference between the compile time and run time setting of [NO]BADCHAR dictates that the compiler cannot with certainty determine whether strings containing illegal UTF-8 characters are actually errors (for example, they may contain binary data). When the compiler reports BADCHAR warnings, it defers the computation to run time, instead of attempting to precompute the result. Note that sometimes a single character with an invalid encoding can cause multiple warnings, for example, when a string that is not a valid UTF-8 string appears inside a function such as $PIECE(). Regardless of any compile time warnings, there is no change to run time functionality of any M application code as a result of this change. (GTM-7762)

Using VIEW "JOBPID":1 does not issue an error when the JOB command parameters ERROR and OUTPUT point to the same file; previously, while the effect of the VIEW command was not documented, using the same file name for ERROR and OUTPUT and VIEW "JOBPID":1 resulted in an error. (GTM-8034)

$ZCONVERT(...,"T") works in M mode; previously it only worked in UTF-8 mode. (GTM-8038)

Processes no longer terminate with a segmentation violation (SIG-11) when:

These issues were only observed in the GT.M development environment, and were never reported by a user. (GTM-8112)

$ZCONVERT() raises an ICUERROR if GT.M is unable to correctly access the ICU library; previously the process terminated with a GTMASSERT. It also runs faster than it did previously. (GTM-8215)

%PEEKBYNAME() provides a stable interface to $ZPEEK() that uses control structure field mnemonics. $ZPEEK() provides a read-only mechanism to access selected fields in selected control structures in the address space of a process, including process private memory, database shared memory segments and Journal Pools. Although application code can call $ZPEEK() directly, such direct access must use numeric arguments that can vary from release to release. Access using %PEEKBYNAME makes application code more stable across GT.M releases. For more information, refer to Additional Information forGTM-8296- %PEEKBYNAME(). (GTM-8296)

If the JOB command finds the ZWRITE representation of an lvn consisting of a its full name, its subscripts, corresponding value, quotes and the "=" sign, exceeding 1MiB, it produces a JOBLVN2LONG error in both JOB'ing and JOB'd process' error stream. This message includes the attempted length and maximum limit. Previously, the JOB'ing process would issue a JOBLVN2LONG error without the lvn length details, and JOB'd process would issue a JOBLVNDETAIL with the length information which the JOBLVN2LONG currently displays. (GTM-8297)

The WRITE /TLS("renegotiate"[,,[tlsid][,,options]]) command on a server socket allows applications to request a TLS renegotiation. In the command:

The WRITE /TLS("renegotiate",...) command ignores options other than those listed above. The options remain in effect for the socket after the renegotiation. Any virtual section remains available in the current process.

Renegotiation requires the suspension of application communication and the application must read all pending data before initiating a renegotiation. This means that in the communication protocol used, both parties must be at a known state when renegotiating keys. For example, in GT.M replication, one party sends a renegotiation request and waits for an acknowledgement before initiating the renegotiation.

The configuration file can specify options, although the WRITE /TLS("renegotiate",...) command can override them. Note that configuration file options may be useful even without the renegotiate command.

The default for the configuration file option verify-mode is SSL_VERIFY_PEER. Previously it was SSL_VERIFY_NONE for TLS enabled sockets.

Including "SESSION" in the fourth argument of $ZSOCKET "TLS" returns information related to SSL sessions including information about renegotiations. The following is an example of the information returned in addition to the information previously returned:

|S:RENSEC:1,RENTOT:1,SESSID:A9EB18B4731B2E4ABA572C8386213
4C67C9561597D5FAF47CDD5B866B77215FF,SESEXP:Thu Jun  4 21:07:11 2015

where "|S:" denotes this piece contains session information, "RENSEC:" indicates whether secure renegotiation is available (1) or not (0), "RENTOT:" gives the current total number of renegotiations done on this socket, "SESSID:" shows the session id in hexadecimal, and "SESEXP:" indicates when the session expires in the local timezone.

Including "OPTIONS" in the fourth argument of $ZSOCKET "TLS" now returns the verify mode after the TLS options (that is, "|O:hexdigits") as a comma and two hexadecimal digits. The verify mode values are defined in openssl/ssl.h.

Including "ALL" in the fourth argument of $ZSOCKET "TLS" returns all available information.

A successful WRITE for a TLS enabled socket with an argument larger than the ZBFSIZE for the socket is not considered an error. Previously, such a WRITE indicated an error with the following $DEVICE value: "1,Unknown error -1" or if IOERROR="TRAP", $ZSTATUS included:

%GTM-E-SOCKWRITE, Write to a socket failed,%GTM-I-TEXT, Unknown error -1

(GTM-8302)

To improve performance of certain UTF-8 string functions, when a string 32-bytes or longer is passed as the first parameter to $EXTRACT() and $FIND() calls that have three parameters, GT.M caches information regarding transitions between blocks of ASCII characters ($CHAR(0) through $CHAR(127)) and non-ASCII UTF-8 characters ($CHAR(128) & up). Actual improvement in application performance can range from unobservable to dramatic depending on the prevalence of this use case. As there are a couple of tuning parameters for this optimization (with defaults that are reasonable in our judgement), if you have code that benefits from this optimization, please contact your GT.M support channel for help in experimenting with the tuning the parameters. (GTM-8352)

When a process accesses a trigger definition with ZPRINT or $TEXT() outside of a TP transaction and it has previously fetched the definition with no intervening execution of a revised trigger definition, GT.M returns information cached by that prior access. Previously, if another process had deleted or modified the definition after its last source access and with no intervening execution, ZPRINT gave a TRIGNAMF error and $TEXT() returned an empty string. Note that accessing the source code within a TP transaction (either implicit or explicit) always uses the current definition. (GTM-8389)

When interrupted by a signal requesting termination, such as SIGTERM, while writing to the principal device, GT.M prints that all subsequent rundown messages correctly. Previously, there was a small window in writing to the principal device when an external signal could result in corrupt rundown messages. This issue was discovered in the GT.M development environment and was never reported by any user. (GTM-8397)

Calls to $TEXT() for which the compiler can determine the source code line at compile time it compiles as literal strings in the object code. Specifically, this optimization occurs when the entryref refers to a line in the current routine, and no component of the entryref uses indirection. (GTM-8404)

ZSHOW accepts atomic indirection in the second expression of its argument. Previously it incorrectly gave an error for such an attempt. (GTM-8407)

ZPRINT handles an unusual case when it appears within trigger code and also within an XECUTE or indirection and the target routine has become empty (has zero length). Previously, such circumstances intermittently produced a ZLINKFILE error. This issue was only observed in the GT.M development environment, and was never reported by a user. (GTM-8417)

$TEXT() returns the empty string for ^GTM$DMOD and ^GTM$CI; previously these $TEXT() arguments, which represent respectively the base frames for mumps -direct and a call-in and could be derived from $STACK(), $ZPOSITION or ZSHOW "S", produced an RPARENMISSING error. (GTM-8431)

ZSHOW expr:gvn stores continuations of information that do not fit in the maximum record size as immediate descendants, using ordinal subscripts starting at one (1), of the node holding the beginning of the information. This facilitates identifying when multiple nodes need to be reassembled to find the entire item. In addition, the ^%ZSHOWVTOLCL utility program restores ZSHOW "V":gvn data into its original local variables. The utility needs to be invoked with $ECODE set to the empty string ("") and cannot restore a local variable with the same name (%ZSHOWvbase) as the parameter in its formal list. Other ZSHOW information typically fits within common database record size limitations. Previously, ZSHOW expr:gvn stored continuation nodes at the same level as other nodes. Although this change is not backward compatible, it facilitates automated restoration even of nodes exceeding the maximum record size of the global, which was not the case previously (GTM-8433)

When a GT.M process receives a MUPIP STOP while doing a READ on a SEQUENTIAL, FIFO, or PIPE device in NOFIXED, M mode, the process terminates. Previously, this combination could cause the process to hang. (GTM-8435)

GT.M produces an appropriate error for an inappropriately long device name in the argument of OPEN, USE and CLOSE commands; previously such an argument could cause a segmentation violation (SIG-11). (GTM-8440)

When interrupted by a signal requesting termination, such as SIGTERM GT.M handles the termination appropriately. In GT.M V6.2-002 and V6.2-002A, if the interrupt happened during certain small windows of execution, it was possible for the process to terminate abnormally, hang, or exhibit other incorrect behavior under rare conditions. This issue was discovered in the GT.M development environment and was never reported by any user. (GTM-8448)

$ZGETJPI() reports large values appropriately; previously large times could wrap. (GTM-8450)

ZWRITE and ZSHOW "V" work appropriately after an interrupted MERGE command involving a local variable; previously this combination could cause a segmentation violation (SIG-11). (GTM-8454)

A JOB command with PASSCURLVN correctly passes alias containers that contain KILL'ed original aliases. Previously, JOB command with PASSCURLVN could fail with INDEXTRACHARS error in such a case. (GTM-8465)

$ZSEARCH() avoids a possible deadlock that could cause a process to hang indefinitely. This issue was only observed in the GT.M development environment, and was never reported by a user. (GTM-8475)

GT.M handles errors from triggers on globals that span nodes or regions when the error handler does not clear $ECODE. Previously, when a trigger's error handler did not clear $ECODE for an update to a global that spanned regions or nodes, GT.M issued a fatal GTMASSERT2 error. (GTM-8476)

GT.M no longer issues an inappropriate TLVLZERO error when executing a TCOMMIT command, as it previously did under certain very rare conditions. This issue was only observed in the GT.M development environment, and was never reported by a user. (GTM-8477)

MUPIP JOURNAL -EXTRACT leaves journal files in a wholesome state when run where a corresponding database was not shutdown in an orderly fashion, due to for example a kill -9, attached processes exceeding 32Ki, etc. Previously, under these somewhat unusual conditions MUPIP JOURNAL -EXTRACT left the journal files in a state where they could not be applied to recover the database. (GTM-8483)

M compilations, trigger compilations, and online integrity checks no longer result in segmentation faults (SIG-11) in rare cases. This issue was only observed in the GT.M development environment, and was never reported by a user. (GTM-8484)

GT.M correctly issues a ZROSYNTAX error when transitioning from a $ZROutines with auto-relink enabled to a $ZROutines that has non-existent directory paths. Previously, GT.M terminated with a segmentation violation (SIG-11). (GTM-8486)

GT.M treats VIEW 1 and VIEW 0 as errors. Previously, it treated these constructs as VIEW "GDSCERT":1 and VIEW "GDSCERT":0 commands respectively. (GTM-8490)

On AIX, for non-wildcard searches, $ZSEARCH() exhibits performance similar to that of other platforms. The correction made with GTM-8237 in V6.2-002 exposed decreased and erratic performance on AIX of the POSIX service used to perform such searches. [AIX] (GTM-8491)

Unless overridden with a GBLDIR jobparameter, processes started with the JOB command use the global directory specified by the $ZGBLDIR of the process executing the JOB command (as documented). Previously, these processes incorrectly used the value of the environment variable gtmgbldir in the environment of the parent executing the JOB command. As a side effect, since the process executing the JOB command would have previously validated the path to the global directory, a JOB'd processes does not terminate with a segmentation violation (SIG-11), as it previously did, if $gtmgbldir is longer than GT.M's limit of 255 bytes for the path to the global directory. You should check all occurrences in your application where it executes JOB commands without GBLDIR jobparameters when its values of $ZGBLDIR and $gtmgbldir differ. In addition, processes no longer terminate with a segmentation violation (SIG-11) when: executing the ZSYSTEM command with an overly long value of the environment variable SHELL; and initializing the reference implementation of the encryption plugin with an overly long value of the environment variable GNUPGHOME. These issues were only observed in the GT.M development environment, and were never reported by a user. (GTM-8512)

GT.M correctly handles pattern specifications where the pattern contains a finite pattern atom (for example 1A) followed by an infinite pattern atom with a pattern code that is a superset of the first pattern (for example .AN) and followed by an alternation (for example .(1".")). Previously it used to treat the finite pattern atom in the above specification as infinite and incorrectly merge the two treating a 1A.AN.(1".") as .AN.(1".") resulting in incorrect results. In addition, the pattern match operator run- time performance has been improved for various types of pattern expressions. (GTM-8522)

If the SHELL environment variable is undefined at GT.M process start-up or if an external call unsets the SHELL enviroment variable, the ZSYSTEM command uses /bin/sh to execute the shell command. Previously, if the SHELL environment variable was undefined at GT.M process start-up, the ZSYSTEM command would fail to work, issuing a "not found" error. In GT.M V6.3-000, if an external call unset the SHELL environment variable, only the first ZSYSTEM call worked as intended. This issue was only observed in the GT.M development environment, and was never reported by a user. (GTM-8530)

Intrinsic functions that use integer or numeric arguments actually constructed using compile-time optimizations to resolve expressions consisting entirely of literals for concatenation and some string functions in source code work as documented. For example $ORDER(xxx,"-"_"1"), where xxx is any legal first argument produced a GTM-E-ORDER2 error. Not invoking the optimization by avoiding the concatenation worked correctly - e.g., $ORDER(xxx,"-1") - as did any operation that coerced the result to numeric - e.g., $ORDER(xxx,"-"_"1"+0). Owing to a problem with string optimizations (GTM-7762 and GTM-8404) in V6.3-000 this described combination of factors generated inappropriate errors. (GTM-8540)

$TEXT(x) where x is a label works correctly when there is a label xyz in the current routine (a) preceding label x and (b) where x is a leading substring of xyz. Note that $TEXT(x^routine) was not affected. Note also that "local labels," those terminated with a colon (:), are accessible at compile time, but not at run time. Owing to a bug with optimization GTM-8404 in V6.3-000, $TEXT(x) would, under these circumstances, incorrectly provide the source code $TEXT(xyz). If there were multiple labels xyz1, xyz2, etc., $TEXT(x) would provide the source code for the first, i.e., $TEXT(xyz1). (GTM-8549)

When assigned to a local variable node, the result of $FNUMBER() where the second argument is the empty string and the third argument specifies potential rounding retains the value assigned. Previously in such circumstances, GT.M could subsequently alter the value in such a node to an incorrect value. The workaround was to use $JUSTIFY(x,0,n) rather than $FNUMBER(x,"",n)(GTM-8558)

MUPIP JOURNAL commands (e.g. ROLLBACK, RECOVER, VERIFY, SHOW etc.) accept the -PARA[LLEL][=n] qualifier to specify the number of parallel threads (for backward processing) and parallel processes (for forward processing). Omitting the qualifier or specifying a value of one (1) defaults to a single process with no threads. Omitting the value or specifying a value of zero (0) specifies one thread or process per region. A value greater than one (1) specifies the maximum number of concurrent threads or processes MUPIP should use, although it never uses more than one per region. If the number of regions exceeds the specified value, MUPIP allocates threads or processes in an order determined by timestamps in the journal records. The environment variable gtm_mupjnl_parallel provides a value when the command has no explicit -PARALLEL qualifier; when defined with no value gtm_mupjnl_parallel acts like -PARALLEL with no value. When the -PARALLEL qualifier (or the gtm_mupjnl_parallel environment variable) specifies the use of parallel processes in the forward phase of a MUPIP JOURNAL command, MUPIP may create temporary shared memory segments and/or extract files (corresponding to -extract or -losttrans or -brokentrans qualifiers) and clean these up at the end of the command; however an abnormal termination such as a kill -9 might cause these to be orphaned.

Journal extract files (created by specifying one of -extract or -brokentrans or -losttrans to a MUPIP JOURNAL command) contain journal records sorted by sequence number (token_seq/jsnum) then by update order (updnum) for all regions which were replicated/journaled - in other words: in the exact order their corresponding updates happened in time. In prior versions of GT.M, these files were not sorted which meant applying lost transaction files (for example) required first sorting the file to correspond to the update-order before applying them.

In addition, a MUPIP JOURNAL -SHOW=HEADER has default of -NOVERIFY if no other action qualifiers (-EXTRACT, -RECOVER, -ROLLBACK, -SHOW) are specified. This speeds up the command in the default case (no verification of the entire journal file occurs). Note that specifying -VERIFY explicitly still does the verification as requested. (GTM-5007)

See GTM-7768. (GTM-5726)

With the -ENCRYPT flag, MUPIP REORG changes the encryption key of a database, or encrypts an unencrypted database, while the database continues to be used by applications. Whether or not the prior encryption uses non-zero initialization vectors (IVs), database blocks encrypted with the new key use non-zero IVs (see GTM-8117). The syntax is:

    MUPIP REORG -ENCR[YPT]=<key> -REGION <region-list>

where <key> is a key provided by MUPIP to the encryption plugin. The reference implementation of the plugin expects a key with the specified name in the encryption configuration file identified by $gtmcrypt_config. The configuration file must contain an entry in the database section for each database file mapping to a region specified in <region-list> that names the specified key as its key. The -ENCRYPT flag is incompatible with all other command line flags of MUPIP REORG, and performs no operation other than changing the encryption key. If the specified key is already the encryption key of a database region, MUPIP REORG -ENCRYPT moves on the next region after displaying a message (on stderr, where MUPIP operations send their output).

As MUPIP REORG -ENCRYPT must read, re-encrypt, and write every encrypted block in each database file, its operation will take a material amount of time on the databases of typical applications, and furthermore will add an additional IO load to the system on which it runs. You can use the environment variable gtm_poollimit to ameliorate, but not eliminate, the impact, at the cost of extending execution times. To minimize impact on production instances, FIS recommends running this operation on replicating secondary instances, rather than on originating primary instances.

MUPIP REORG -ENCRYPT switches the journal file for each database region when it begins operating on it, and again when it completes, and also records messages in the syslog for both events. Note that the detailed journal extract format is now level 8.

As is the case under normal operation when MUPIP REORG -ENCRYPT is not active, journaled databases are protected against system crashes when MUPIP REORG -ENCRYPT is in operation: MUPIP JOURNAL ROLLBACK / RECOVER recovers journaled database regions (databases that use NOBEFORE journaling continue to require FORWARD RECOVER / ROLLBACK).

Since a database file utilizes two keys while MUPIP REORG -ENCRYPT is underway, the database section of the configuration file provides for a single database file entry to specify multiple keys. For example, if the keys of database regions CUST and HIST, mapping to database files cust.dat and hist.dat in directory /var/myApp/prod, are to be changed from key1 to key2 using the command:

    MUPIP REORG -ENCRYPT=key2 -REGION CUST,HIST

then the database section of the configuration file must at least have the following entries:

 database: {
     keys: ({
         dat: "/var/myApp/cust.dat";
         key: "key1";
     },{
         dat: "/var/myApp/cust.dat";
         key: "key2";
     },{
         dat: "/var/myApp/hist.dat";
         key: "key1";
     },{
         dat: "/var/myApp/hist.dat";
         key: "key2";
     })
 };

In other words, each database file entry can have multiple keys, and a key can be associated with multiple database files. With a configuration file that has multiple keys associated with the same database file, MUPIP CREATE uses the last entry. Other database operations use whichever key has a hash matching one in the database file header, reporting an error if no key matches. To improve efficiency when opening databases, you can delete entries for keys that are no longer used from the configuration file.

MUPIP REORG -ENCR[YPT] can encrypt an unencrypted database only if the following command:

    MUPIP SET -ENCRYPTABLE -REGION <region-list>

has previously marked the database "encryptable".

The command requires standalone access to the database. Just as encrypted databases use global buffers in pairs (for encrypted and unencrypted versions of blocks), a database marked as encryptable has global buffers allocated in pairs (i.e., the actual number of global buffers is twice the number reported by DSE DUMP -FILEHEADER) and requires correspondingly larger shared memory segments. To revert unencrypted but encryptable databases back to "unencryptable" state, use the command:

    MUPIP SET -NOENCRYPTABLE -REGION <region-list>

The above command also requires standalone access, and the result depends on the state of the database. It:

Under normal operation, a database file has only one key. Upon starting a MUPIP REORG -ENCRYPT to change the key, there are two keys, both of whose hashes GT.M stores in the database file header. With a MUPIP REORG -ENCRYPT operation underway to change the key, normal database operation can continue, except for another MUPIP REORG -ENCRYPT or MUPIP EXTRACT in binary format. Other MUPIP operations, such as MUPIP BACKUP and MUPIP EXTRACT in ZWR format can occur. A MUPIP REORG -ENCRYPT operation can resume after an interruption, either unintentional, such as after a system crash and recovery, or intentional, after an explicit MUPIP STOP of the MUPIP REORG -ENCRYPT process. To resume the REORG operation, reissue the original command, including the key parameter. (Note that supplying a key other than the one used in the original command results in an error.)

After the MUPIP REORG -ENCRYPT process completes, subsequent MUPIP REORG -ENCRYPT operations on the same region(s) are disallowed until the following command is run:

    MUPIP SET -ENCRYPTIONCOMPLETE -REGION <region-list>

The reason to block subsequent MUPIP REORG -ENCRYPT operations upon completion of one is to provide time for a backup of the entire database before enabling further key changes. MUPIP SET -ENCRYPTIONCOMPLETE reports an error for any database region for which MUPIP REORG -ENCRYPT has not completed.

The above changes necessitated certain alterations of the encryption plugin API (for other API changes, see GTM-8336).

(GTM-6310)

See GTM-8137. (GTM-6317)

MUPIP EXTRACT and MUPIP JOURNAL -EXTRACT are faster. While improvements you see will depend on the circumstances of your configuration and environment, in testing in the GT.M development environment, GO and ZWR formatted extracts completed in as much as three to four times faster than before. (GTM-6388)

On AIX, GT.M uses the AIX provided ICU libraries when gtm_icu_version is not defined. Previously GT.M required users to build the ICU libraries. [AIX] (GTM-6858)

With the -ZEROBACKLOG qualifier, a MUPIP REPLICATE -SOURCE -SHUTDOWN command shuts down the Source Server either when the backlog goes to zero, or the timeout expires, whichever occurs first. (GTM-6928)

MUPIP JOURNAL -ROLLBACK recognizes the -FORWARD qualifier to specify it apply update records in journal files to backed up copies of database files in order to bring them to the same state that MUPIP JOURNAL -ROLLBACK -BACKWARD "*" would bring crashed database files. Unlike MUPIP JOURNAL -ROLLBACK -BACKWARD, MUPIP JOURNAL -ROLLBACK -FORWARD accepts either a comma-delimited list of region names or "*", indicating the journal files associated with all regions in the current Global Directory. A MUPIP JOURNAL -ROLLBACK -FORWARD "*" command does what a MUPIP JOURNAL -RECOVER -FORWARD "*" would do except that the -ROLLBACK also updates sequence number related fields in the database file header, and ensures update serialization across regions - MUPIP JOURNAL -RECOVER can leave one database region ahead of another region and cannot ensure database Consistency across regions, whereas MUPIP JOURNAL -ROLLBACK can ensure Consistency. Databases recovered with MUPIP JOURNAL -ROLLBACK can therefore be used in replicated instances. Note that, in the context of -RECOVER and -ROLLBACK, the "*" indicates the use of all the appropriate journal files in all the replicated regions and the quotes prevent inappropriate expansion by the OS shell. MUPIP JOURNAL -ROLLBACK -FORWARD leaves the journaling state turned off in database files (as does MUPIP JOURNAL -RECOVER -FORWARD), which in turn means that replication is also turned off; journaling should be re-enabled, and replication turned on, before database files are used in environments where they can be updated, but can be left off if subsequent access is read-only. After a MUPIP JOURNAL -ROLLBACK -FORWARD, the replication instance file needs to be recreated as part of turning replication on in the recovered database. MUPIP JOURNAL -ROLLBACK -FORWARD can use both before-image and nobefore-image journal files. See the More Information section for details on qualifier use. In addition, MUPIP JOURNAL -ROLLBACK -BACKWARD output always includes the RLBKJNSEQ message; previously the output only included this if the rollback changed the database (i.e., the operation was not a no-op). Also, MUPIP JOURNAL -RECOVER -BACKWARD -BEFORE works even when -SINCE is not specified; previously such a command terminated with a JNLTMQUAL1 error. For more information, refer to Additional Information for GTM-7291 - MUPIP JOURNAL -ROLLBACK qualifiers. (GTM-7291)

GT.M accepts all ICU versions reported by "icu-config -version" for gtm_icu_version. Previously GT.M required the format of gtm_icu_version to be <ICU Major Version> "." <ICU Minor Version> with no trailing digits, and required ICU versions 49 & higher (i.e., with the new ICU numbering scheme) to be specified as 4.9, 5.0, etc. (GTM-7375)

An improvement in database replication communication between Source and Receiver Servers reduces delays. Previously, a busy Source Server, for example, one searching through journal files to find the transaction at which to resume communication with a replicating secondary instance with a large backlog, could ignore communications long enough for the Receiver Server to close the connection and begin a reconnection cycle, adding to the persistence of the backlog. Note that a Source Server started with -JNLFILEONLY always reads from the journal files. (GTM-5726) (GTM-7768)

MUPIP SET recognizes the -SPIN_SLEEP_LIMIT=n where n is decimal maximum number rounded up to the nearest power of two and turned into a hexadecimal mask that determines the maximum number of nanoseconds for processes to sleep while waiting to obtain critical sections for shared resources, principally those involving databases. The default is zero (0) which causes the process to return control to the UNIX kernel to be rescheduled with no explicit delay. When the value is non-zero, the process waits for a random value between zero (0) and the maximum value permitted by the mask. DSE CHANGE -FILEHEADER -SPIN_SLEEP_MASK provides a means to directly set the hexadecimal value of the mask, which appears in DSE DUMP -FILEHEADER output with the label "Spin sleep time mask." Previously, processes always rescheduled themselves with no delay. In addition, MUPIP SET (and DSE) accept a 0 value for -SLEEP_SPIN_COUNT, which eliminates the sleep loop in the mutual exclusion (mutex) facility so processes go straight from a hard spin to a queued wait. Previously, the -SLEEP_SPIN_COUNT qualifier was not recognized by MUPIP SET and processes that exhausted the hard spin count always did at least one (1) rescheduling operation. Except on the advice of your GT.M support channel, FIS recommends leaving the default values unchanged in production environments, until you have data from testing and benchmarking that demonstrates a benefit from a change. If none of its qualifiers are out of the range from minimum to maximum, MUPIP SET processes all qualifiers for each region applying them only if all are appropriate for the region and otherwise warning of any issues. Previously, MUPIP SET stopped at the first error and if some qualifiers required standalone access and others did not, applied only those requiring standalone access and silently ignored those that did not. If you have scripting that checks for correct completion of a MUPIP SET command, no changes are required to accommodate this change. However, if your scripting checks for and takes actions based on errors reported by MUPIP SET, you should test your script and revise it as needed. (GTM-7809)

MUPIP JOURNAL ROLLBACK fixes DBDANGER situations and therefore neither issues DBDANGER messages to syslog nor freezes an instance. Previously, MUPIP JOURNAL ROLLBACK could send DBDANGER messages to syslog even though it would fix the problem, and, when using the Instance Freeze facility with a DBDANGER in the custom errors file, a ROLLBACK issuing a DBDANGER message would freeze until manually unfrozen. (GTM-7831)

GT.M replication uses the operating system and network to perform flow control. Previously, the Source and Receiver Servers performed flow control, as a consequence of which the Receiver Server could flood the socket connection with flow control messages, leading to a large number of log messages and an occasional hang in replication processing. (GTM-7838)

MUPIP LOAD accepts negative values in ZWR format input such as that produced by %GO. Previously, such a value caused a LOADFILERR. The workaround was to use GO format or edit the file to add a pair of double-quotes around the negative value. (GTM-8020)

GT.M can be configured to permit more than 32,767 processes to concurrently access a database file. In a replicated environment, to permit one or more database files to be concurrently accessed by more than 32,767 updating processes also requires the replication instance file to be configured to permit concurrent access by more than 32,767 processes. The default behavior is to limit the number of processes accessing a database file or instance file to 32,767. This permission is effected by the QDBRUNDOWN flags in database file headers and in replication instance files. When an open database file or replication instance file with QDBRUNDOWN set is first concurrently accessed by more than 32,767 processes, GT.M (a) logs a NOMORESEMCNT message in the system log, and (b) stops counting the number of attached processes. This means that GT.M cannot recognize when the number of attached processes reaches zero (0) in order to release the corresponding shared resources, and therefore requires explicit manual clean up of resources for an orderly shutdown. Previously, exceeding 32Ki attachments to shared resources caused a DBFILERR, CRITSEMFAIL error with an ERANGE status for database and replication instance files, as it still does when QDBRUNDOWN is not set.

Except in application configurations that require it, FIS recommends not setting QDBRUNDOWN. Not setting QDBRUNDOWN allows GT.M to clean up resources, instead of putting the burden on the operational procedures. Where GT.M cannot perform an orderly shutdown, an explicit, clean shutdown must be performed as follows:

MUPIP REPLICATE -INSTANCE_CREATE -[NO]QDBRUNDOWN controls the QDBRUNDOWN setting of a replication instance file when it is created. For an existing replication instance file, requiring stand-alone access (i.e., the instance must not have an existing Journal Pool), MUPIP REPLICATE -EDITINSTANCE -[NO]QDBRUNDOWN controls the QDBRUNDOWN setting. Specifying -QDBRUNDOWN turns it ON, and -NOQDBRUNDOWN turns it OFF. MUPIP REPLICATE -EDITINSTANCE -SHOW displays the current QDBRUNDOWN setting of an instance file as "HDR Quick database rundown is active", reported as TRUE or FALSE. Note that QDBRUNDOWN is an existing setting in database files. See the release note for GTM-8296 on accessing the QDBRUNDOWN setting using %PEEKBYNAME().

In support of this enhancement:

The work to develop this enhancement also addressed several issues. These issues were only observed in the GT.M development environment, and were never reported by a user.

(GTM-8137)

MUPIP LOAD accepts a broader range of labels; label second lines containing "ZWR", "GLO", or the pattern produced by MUPIP EXTRACT and %GO automatically determine a format. Starting with V6.2-001, LOAD required the second line be either the exact format produced by MUPIP EXTRACT and ^%GO or under some conditions have a second line ending in "; ZWR" or "; GLO". In addition, MUPIP LOAD accepts files with DOS style termination. For -FORMAT={ZWR|GO} files not produced by MUPIP EXTRACT or %GO, the first line of the label must contain the case insensitive text "UTF-8" for UTF-8 mode files and the second line should contain the case insensitive test "ZWR" for zwr format or "GLO" for GO format and the two label lines must contain a total of more than 10 characters. (GTM-8223)

MUPIP replication compression supports the use of the IBM provided zlib library for AIX. Previously MUPIP replication compression required a custom compiled library. [AIX] (GTM-8225)

MUPIP REPLIC -BUFFSIZE=<bytes> has a maximum of 4294967288 (4GiB-8) for both -SOURCE and -RECEIVER; previously it had a maximum of 2147483647 (2GiB-1). (GTM-8326)

MUPIP TRIGGER -TRIGGERFILE presents a delete all confirmation prompt once, "Please enter Y or N:" (case insensitive). For any other response, MUPIP prompts again. Previously, every time MUPIP TRIGGER -TRIGGERFILE had to restart its transaction, it would repeat the prompt. Also, previously MUPIP TRIGGER -TRIGGERFILE would treat any response other than Y (case insensitive) as NO. (GTM-8342)

The distribution contains a source tarball for the reference encryption plugin, but no binaries. If you wish to use the reference encryption plugin, you must follow the instructions to compile it from the source in the tarball. Previously the distribution included binaries. Although not backwards compatible, we took this step because variations in encryption libraries meant that we could not provide a single binary that was guaranteed to run across Supported platforms with the robustness we require of GT.M. Note that when compiling the encryption plug-in, you should always review the makefile to ensure that all required dependencies in the makefile are installed on your system, and edit as needed to ensure that the locations of the header and library paths are correct for your system. (GTM-8361)

Repeated invocations of MUPIP JOURNAL ROLLBACK/RECOVER work correctly in case prior invocations terminated with certain errors. Previously, if at least two ROLLBACK or RECOVER commands terminated incompletely (say due to a GTM-E-MEMORY error) AND a MUPIP SET JOURNAL occurred between the interrupted commands, a subsequent ROLLBACK or RECOVER command could terminate abnormally with a GTMASSERT error even after correcting the cause of the original errors (say by raising the ulimit memory setting to avoid GTM-E-MEMORY errors). FIS recommends against unnecessarily changing journal files in the middle of operational processes such as ROLLBACK or RECOVER. (GTM-8394)

The Source Server correctly identifies the current journal file in the presence of a concurrent journal file switch. Previously, on rare occasion (made somewhat less rare by specifying the -JNLFILEONLY option to the Source Server) the Source Server would fail to identify the current journal file, issue a NOPREVLINK error, and exit. This issue was only observed in the GT.M development environment, and was never reported by a user. (GTM-8410)

See GTM-7658. (GTM-8420)

A Receiver Server started with -autorollback remains active even if an online rollback does not change the state of the database. Previously a Receiver Server started with -autorollback would shutdown if an automatic online rollback did not change the state of the database. (GTM-8421)

See GTM-6388. (GTM-8422)

The Receiver Server (MUPIP) correctly handles replication record conversion for large transactions from prior GT.M releases. A regression in GT.M V6.2-000 caused the Receiver Server to hang when the conversion size of records from a single transaction replicated from V5.4-002B or earlier exceeded 2MiB. (GTM-8423)

The Update Process receiving a replication stream works correctly in certain edge cases when a concurrent online rollback runs on the instance. Previously, the Update Process could terminate with a GTMASSERT error or hang and block further updates for potentially arbitrary periods of time. This was only encountered in the GT.M development environment, and was never reported by a user. (GTM-8425)

MUPIP INTEG appropriately reports large values; previously large amounts could overflow and cause erroneous reports. (GTM-8428)

Epoch tapering performs properly for a rare edge case. Previously, on very rare occasions, epoch tapering could encounter a divide-by-zero error. This issue was only observed in the GT.M development environment, and was never reported by a user. (GTM-8443)

The Source Server updates the resync sequence number in the replication instance file every 60 seconds. Internal testing pointed to a few timing windows where the resync sequence number was not updated for over 90 seconds. (GTM-8461)

MUPIP EXTRACT on an encrypted database instance creates valid binary extract files regardless of the region mapping. Previously, MUPIP EXTRACTs on instances with multiple regions pointing to the same database file could result in invalid extract files, that MUPIP LOAD could not process. The workaround was to use a global directory with regions merged so that each database file was referenced in just one segment. (GTM-8464)

When a Source Server starts replicating updates from a newer generation journal file, it closes any prior generation of that journal file that it has open. Previously, it closed open journal files only when switching to the Journal Pool, which was problematic for a Source Server started with the -jnlfileonly option. The workaround was to shut down and restart the Source Server. Additionally, the Source Server more efficiently handles the case where it has a large number of journal files open - a common situation when its receiving secondary instance starts with a significant backlog, forcing the Source Server to chain through large numbers of prior generation journal files. (GTM-8468)

See GTM-7831. (GTM-8470)

When completing a TLS renegotiation, the source server places a "Sending REPL_RENEG_COMPLETE" in its log file after a "REPL_RENEG_ACK received" message and before a "Sent REPL_RENEG_COMPLETE" message; previously it did not record this event. (GTM-8478)

MUPIP REORG limits its global buffer usage to the value specified by the gtm_poollimit environment variable, or, by default, if gtm_poollimit is not defined, to 64 buffers. Previously MUPIP REORG did not restrict its use of global buffers although the documentation stated that it did. We are aware of some issues with gtm_poollimit and recommend the following until the next release: avoid using it for processes that make extended global references or run MUPIP TRIGGER. (GTM-8479)

MUPIP BACKUP -DATABASE now attempts to preserve, and potentially restore, sparseness in database files. Previously, MUPIP BACKUP -DATABASE resulted in backup database files that were fully allocated. In the case of large but sparse database files, this could produce backup database files that used substantially more storage than the original database files. To remove sparseness from backup database files, use the fallocate command on Linux, or copy them to another location using the cp command on AIX. (GTM-8480)

MUPIP INTEG -FAST handles certain obscure integrity conditions correctly. Previously, these conditions could result in a REGSSFAIL error (AIX) or KILLBYSIGSINFO1 (signal 11) fatal error and core dump (Linux). MUPIP INTEG without the -FAST qualifier was not affected. (GTM-8481)

MUPIP JOURNAL correctly issues FILEPARSE errors for invalid paths; previously FILEPARSE errors would result in a SIG-11. (GTM-8485)

Shutting down all Source Server processes when GT.M processes are still accessing a database file does not generate inappropriate REPLINSTMATCH errors. (GTM-8487)

MUPIP BACKUP -ONLINE creates a usable backup of the replication instance file on a secondary instance. Previously, in rare cases, it could create a backup instance file that would cause the secondary to be out of sync with the currently replicating primary. Also, the replication instance file header on disk stores the current journal sequence number whenever a new history record gets added to the instance file. Previously this was not maintained which meant a MUPIP REPLIC -EDIT -SHOW command on the instance file potentially returned stale information on a live replicated environment. These issues were only observed in the GT.M development environment, and never reported by a user. (GTM-8494)

MUPIP commands that need standalone access, for example, MUPIP SET -REPLICATION=ON, issue a MUUSERLBK error on a crashed replication-enabled database, and MUUSERECOV error in case of a non-replicated-but-journaled database. Previously, the MUPIP commands would attempt a rundown regardless of the replication and journaling state of the database, potentially resulting in an unrecoverable database. Also MUPIP JOURNAL -RECOVER -FORWARD and MUPIP JOURNAL -ROLLBACK -FORWARD now issue a MUUSERECOV or MUUSERLBK error in case the database shared memory segment exists. In this case, only a MUPIP JOURNAL -RECOVER -BACKWARD or MUPIP JOURNAL -ROLLBACK -BACKWARD can correctly flush the updates from shared memory to the database file on disk. Previously MUPIP JOURNAL -RECOVER -FORWARD used to proceed with the recovery potentially creating a corrupt database file. Also, MUPIP RUNDOWN issues a MUUSERLBK error on a crashed replication-enabled database even if the database has NOBEFORE_IMAGE journaling. Previously, it used to issue a MUUSERECOV error in this case. This issue was only observed in the GT.M development environment, and was never reported by a user. (GTM-8502)

Replication from an originating primary instance A to business continuity instance B and a supplementary instance P to an instance downstream Q (i.e., B<-A->P->Q) is more robust. Previously, if there was at least one switchover between A and B while the P->Q link was operating (i.e., from B<-A->P->Q to A<-B->P->Q) followed by a disruption in the P->Q replication connection, the automatic reconnect incorrectly concluded that P and Q were out of sync and the receiver server on Q incorrectly terminated. This issue was only observed in the GT.M development environment, and was never reported by a user. (GTM-8507)

The DSE ALL -CLEARCORRUPT qualifier sets the CORRUPT_FILE file header to FALSE for all GDS regions. Use the ALL -CLEARCORRUPT qualifier only after receiving instructions from your GT.M support channel. Previously, there was no single command to clear the CORRUPT_FILE to FALSE for all regions. (GTM-7199)

^%RI correctly responds to a yes answer to the "Formfeed delimited <No>? " question, correctly places its output even if the output is sent to a directory without specifying a trailing slash (/), appropriately restores the characteristics of $PRINCIPAL that it adjusts, and accepts "DOS" line terminations (<CR><LF> instead of <LF>) at the end of input file lines. Previously it ignored a "YES" form-feed answer, prepended the directory name to the routines, changed the characteristics of the principal device and retained <CR>s at the end of input file lines, which resulted in compilation errors.(GTM-7658)

Created processes inherit only those open files that they should inherit. Previously unintended file sharing with non-GT.M executables could cause rare file handling errors. Non-GT.M executables can be run via ZSYSTEM, PIPE, MUPIP replication filters, and the gtm_procstuck_exec environment variable. (GTM-8009)

^%GI accepts records up to the maximum string length (currently 1MiB). Previously it was limited to 8KiB for ZWR format and 2044 bytes for GO format. (GTM-8022)

The GT.M encryption plugin works correctly when $gtm_dist points to the utf8 subdirectory of the GT.M installation, as it should for UTF-8 mode processes. Previously, pointing $gtm_dist to the utf8 subdirectory resulted in the encryption plugin failing to load with a CRYPTDLNOOPEN2 error. The workaround was to replace the symbolic link plugin in the utf8 directory with a copy of the plugin directory from the main GT.M installation directory. This was originally fixed in V6.2-000, but was inadvertently omitted from the release notes. (GTM-8028)

In the event that a process detects a certain class of inconsistencies in the Journal Pool, it generates a core file (but does not terminate), and forces replication to continue from the journal files. This causes replication to reset to a known state. Replication resumes from the Journal Pool once a Source Server process determines that the updates it needs to replicate are in the Journal Pool. (GTM-8076)

Peer replication is a type of bi-directional replication that uses GT.M triggers. Subsets of application logic which do not need update / transaction serialization, but which can benefit by aggregating updates from separate instances, can be deployed using peer replication. For example, financial transactions on a bank account must be serialized because each transaction depends on the result of the previous transaction on that account; balance inquiries need not be serialized because, while an inquiry to an account depends on the last financial transaction on that account, it does not depend on the last inquiry to that account. A reference implementation of GT.M peer replication is available as a plugin that you can add to your application (the reference implementation of a plugin is code that you can use as-is if it meets your needs, or adapt to your needs as appropriate; an existing example is the POSIX plugin). Plugins are not part of the GT.M core release but are separately released packages. The plugin includes a detailed readme file on implementing peer replication using the plugin. (GTM-8325)

A GT.M process waits for 500 ms before re-attempting to start gtmsecshr. As a consequence of a regression introduced in a previous version, while processing a timed event, GT.M waited only 3 milliseconds between attempts which could generate unnecessary syslog messages. (GTM-8395)

The %MPIECE utility NEWs all local variables except its arguments. Previously it could disrupt the state of a caller's local variables. (GTM-8403)

Journal record time stamps are more closely aligned with $HOROLOG and the timekeeping used for the HANG function. Previously there was some evidence that a global SET, HANG 1, global SET might occasionally yield two journal records in with the same time stamp. (GTM-8416)

The build dependencies in the source code for GT.M released under a free / open source software license support a greater variety of environments. GT.M V6.2-002/-002A builds failed in some build environments with the error: "fatal error: xfer_desc.i: No such file or directory". (GTM-8429)

The gtminstall script now honors the −−copyenv, −−copyexec and −−group-restriction options; previously these options caused the script to fail. (GTM-8441)

Enhance infohub_profile.sh to allow for one sitewide configuration file named custom_infohub_site.sh located in the installation directory. Previously, each user would need to configure infohub_site.sh in their $HOME directory. The InfoHub database instance gleaners operated through a PipeLine service now include information about each of the 16 Source Server slots. Previously this information was not available. (GTM-8449)

DSE manages output so it appears in the intended order. In versions, from GT.M V6.2-000 to GT.M V6.2-002A inclusive, when stdout and stderr for DSE invocation were assigned to the same file or terminal, DSE sometimes presented output in an incorrect order. There was no issue if stderr and stdout were directed to different destinations - output always went to stderr. This issue was only observed in the GT.M development environment, and was never reported by a user. (GTM-8458)

When starting gtmsecshr, GT.M clears environment variables that gtmsecshr does not need. Previously, it set them to the empty string (""), which could result in benign ARCTLMAXLOW warnings in the syslog. (GTM-8471)

DSE interprets the keys on damaged blocks appropriately; previously moving between a good block and a damaged block could cause DSE to report the wrong key interpretation. This issue was discovered in the GT.M development environment and was never reported by any user. (GTM-8495)

DSE uses the original values used to create shared memory in case other values have been written to the file header. Previously mismatched values between shared memory and the file header prevented DSE from attaching to an active database. Note that such a scenario would require explicit abuse or misuse of DSE, and could not happen accidentally. Please remember that:

This issue was only observed in the GT.M development environment, and was never reported by a user. (GTM-8511)

The −−xec command line option of the %XCMD utility program is optional. Previously, it was required. (GTM-8514)

At the direct mode prompt, GT.M ignores escape sequences longer than 16 bytes, however generated. Previously an escape sequence longer than 16 bytes could cause abnormal process termination. Note that such long escape sequences are not meaningful to GT.M, which ignores all escape sequences except those mapping to the limited set of terminfo capabilities documented in the "Using Terminals" section of Chapter 9 (Input/Output Processing) of the GT.M Programmers Guide. (GTM-8521)

libgtmutil.so no longer includes extraneous MUMPS routines. Previously the GT.M distribution included MUMPS routines that are used in building GT.M and were not intended for distribution. (GTM-8524)

M-Profiling treats negative change in cumulative user/system/elapsed time, incorrectly returned by the operating system, as zero time change. Previously, in such cases the trace could include extremely large time values. (GTM-8541)

GT.M issues a KILLBYSIGUINFO message (to syslog as well as stderr) with valid process-id and userid information when a process that is hung on an instance freeze is killed using a process-terminating signal (e.g. kill -QUIT). Previously, in this scenario, it used to issue a KILLBYSIGUINFO message with a value of 0 for the process-id (of killing and killer process) and userid (of killing process). (GTM-8552)