GT.M properly manages concurrent process kills during an online rollback. Previously, a concurrent kill might have induced unwanted transaction restarts during the online rollback. This was only seen in development environments and was never reported by a customer. (GTM-9836)

GT.M avoids unnecessary delays when one process waits for another process to complete the read from secondary storage of a block in which it is interested. Previously, such cases could result in slowdowns in processing; for example, when the replication update process repeatedly waits for reads initiated by reader helpers. (GTM-10071)

For regions with BG access method, GT.M provides GVSTATS IDXH which gives the number of index block hits and IDXM which gives the number of index block misses. These statistics may help in determining appropriate sizing for a region's global buffers. The hit ratio may be determined as: IDXH/(IDXH+IDXM). Index blocks hold metadata GT.M uses to rapidly locate application data. They constitute a very small, but heavily used, portion of a database file. Finding them in the global buffers causes a higher positive impact on database performance than finding data blocks. While these statistics are useful in understanding the role of global buffers, because processes use their own caching of paths to recently referenced data, these statistics underrepresent actual index block usage. IDXM is a subset of DRD. The hit ratio for data blocks may be approximated by: (DTA+GET+KIL+ORD+QRY+SET+ZPR-DRD)/(DTA+GET+KIL+ORD+QRY+SET+ZPR). Previously, GT.M did not provide separate index block statistics. (GTM-10076)

By default, TPNOTACID retries for a transaction exceed 16, GT.M issues a trappable TPNOTACID error in order to limit livelock. The limit may be adjusted to between four (4) and 100, or set to zero (0) by appropriately defining the gtm_tpnotacidtries environment variable; specifying a value outside the supported values silently reverts to the default. The setting of zero (0) acts like an audit by reporting all encountered operations capable of causing TPNOTACID detection to the syslog but setting the actual error limit to the default. In addition, GT.M suppresses TPNOTACID syslog warning messages that originate from the same action as the last prior message from a given process. Previously, GT.M did not enforce any limit on TPNOTACID retries, had no "audit" capability and could be noisy with informational messages for TPNOTACID retries. (GTM-10098)

GT.M uses TPNOTACID behavior for all external calls and for ZEDIT; previously, external calls and the ZEDIT command were exempted from TPNOTACID handling. (GTM-10099)

$VIEW "GVSTAT", ZSHOW "G" and %YGBLSTAT report the count of $INCREMENT() operations labeled INC. $INCREMENT() operations are are still included in the SET count. Previously, these operations were only included in the SET count. (GTM-10123)

GT.M appropriately manages the journal pool resource control (ftok semaphore IPC) after tracked events lose accuracy for example after simultaneous access of a journal pool by more than more than 32Ki processes. Previously, such a situation could cause inappropriate EINVAL errors when subsequently accessing the journal pool. This was only seen in development environments and was never reported by a customer. (GTM-10541)

GT.M includes six additional counters tracking milliseconds of time slept while waiting on another process to finish a task. The counters are available as part of all forms of GVSTATs, and have the following mnemonics and descriptions:

These counters can help identify the cause of performance degradation. High values per second can indicate I/O throughput issues that are forcing GT.M to perform excessive coordination activity. (GTM-10554)

$ZMAXTPTIME and its initializing environment variable, $gtm_zmaxtptime, maintain precision to milliseconds (three digits after the decimal point). Also, both ignore values exceeding a maximum of 60 seconds. Previously $ZMAXTPTIME only provided whole seconds, and, while it limited the initial value to 60 seconds, it did not limit the SET value. (GTM-10603)

GT.M inhibits epoch tapering when epoch tapering is enabled and only one process actively does updates. Previously, in this situation, epoch tapering could reduce performance. (GTM-10623)

$STORAGE reports the correct value when there is a restriction on the data segment limit (RLIMIT_DATA) of a process. Previously, $STORAGE inappropriately returned 2GiB in such a case. (GTM-9833)

GT.M avoids processing certain unneeded compiler operations. The optimization originally appeared in V6.3-012, but was ineffective. (GTM-9841)

READ * from a socket returns minus one (-1) if the read fails; previously it returned a zero (0) in that case, which was inconsistent with other devices and with the standard. (GTM-9855)

$TEXT() recognizes and reports DBROLLEDABACK error. Previously $TEXT() ignored and did not report DBROLLEDBACK errors. This was only seen in development environments and was never reported by a customer. (GTM-10150)

ZWRITE of a gvn maintains $REFERENCE to the last node it successfully processed. If you use ZWRITE as a debugging tool, or unlikely, in application code, in a circumstance where preserving $REFERENCE has importance, note $REFERENCE and restore it, as you would for any other command or function that references a global. Previously, ZWRITE restored the $REFERENCE to the value it had prior to the ZWRITE. (GTM-10679)

SET $ZTRAP appropriately validates the code string provided as a new value. GTM-9480/GTM-DE304273 in V7.0-004, which addressed an issue with $ZTRAP maintenance, introduced a possibility that the compilation of a $ZTRAP during a "SET $ZTRAP=x" operation could result in assigning a garbage value to $ZTRAP. A similar issue, dating to V6.3-001A, also affects certain I/O exception handlers specified as exception device parameters. If your application always uses code vectors rather than labels, a workaround for both issues is to set the gtm_ztrap_form environment variable to "adaptive", which prevents the assignment operation from validating the code. (GTM-10688)

A Source Server more reliably returns memory used to manage journal files to the operating system as it moves from older to newer journal files for a region. The Source Server uses the mmap() and munmap() services rather than malloc() and free(), which may affect the memory limits for the process or the system. Previously, the Source Server deallocated memory for older journal files, but malloc() and free() rely on a system heap implementation that can interfere with attempts to return memory from the process to the operating system. (GTM-9141)

MUPIP CREATE gives database files permissions based on the umask setting of the target directory. Previously new database files always took 0666 as their permission regardless umask setting. (GTM-9272)

GT.M processes started at the same time as a REORG ENCRYPT correctly load the new encryption key. Previously, processes started at the same time as REORG ENCRYPT could fail to acquire the new key and exit with a CRYPTOPFAILED error message. This issue was only seen in development and not reported by a customer. (GTM-9839)

Both the Source and Receiver Servers include a timestamp in any GETADDRINFO error messages and the Receiver Server follows that message with a REPLCOMM message. Previously, neither Server included a timestamp in the GETADDRINFO error message, and the Receiver Server omitted the REPLCOMM message. (GTM-10081)

On replication shutdown GT.M allows sufficient time for all processes to terminate before attempting to clean up shared IPC resources. Previously running peer processes could prevent the resources from being released. This was seen only in internal testing and was not reported in production. Also for replication retries GT.M takes care to check the retry interval. Previously, if an operating system sleep operation returned slightly before expected, GT.M might delay connection retries. This was only seen in internal testing and not reported by any customer. (GTM-10587)

MUPIP REORG correctly handles concurrent reduction in the depth of a global tree caused by concurrent REORGs or full-global kills. Previously, in rare cases where this situation occurred in a small window, REORG could terminate unexpectedly due to a GVFAIL error or segmentation violation (SIG-11) without any database damage. This issue was only discovered in testing and not reported by any customer. (GTM-10670)

MUPIP INTEG appropriately manages reporting details of an error in a database block. Previously, INTEG would overwrite between one (1) and four (4) bytes beyond the end of the message buffer when preparing such an error message. This issue was only discovered in testing and not reported by any customer; we not been unable to identify any user-visible symptoms or any security exploit associated with this issue. (GTM-10684)

GDE and MUPIP report a more appropriate maximum value for journal file extension. This does not change the way the extension logic works, only the value reported by the GDE VALTOOBIG or MUPIP JNLINVEXT messages. Previously the messages reported a maximum that had no relationship with the maximum size of a journal file. (GTM-10687)

MLKHASHRESIZE, MLKHASHRESIZEFAIL and MLKREHASH messages include region and database file names. Previously, these error messages did not provide the region and database file names. (GTM-9653)

GT.M appropriately handles a high rate of MUPIP interrupts. Previously, under rare circumstances where a process received many MUPIP INTRPTs in rapid succession, the process could fail with an GTMASSERT error. This issue was only seen in development and not reported by any customer. (GTM-9775)

Processes in Direct Mode handle local variables appropriately when interrupted by SIGINT or SIGUSR1 signals. Previously, processing such signals in Direct Mode leaked stack space, potentially causing STACKCRIT and/or STACKOFLOW errors. (GTM-9815)

GT.M properly handles the effects of advanced optimization under newer C compilers during asynchronous signal handling. This issue does not affect any known distributed binaries of GT.M, but can affect versions of GT.M compiled from source with compiler optimizations enabled. The issue can cause database corruption, application-level inconsistency in the form of partially-complete transactions, and hangs. Users of previous versions who compiled from source with compiler optimizations enabled can reduce the likelihood of encountering this issue by increasing the database flush timer. This issue was found in development and was never reported by any customer. (GTM-9831)

Eliminate a rare issue with asynchronous events; previously such an event at in a window that widened in V7.1-003, could cause a process termination with a SIG6. (GTM-10586)

GT.M more reliably returns physical and virtual memory used to manage its heap to the operating system, using the mmap() and munmap() services rather than malloc() and free(). The change may affect the memory limits for the system. Previously, GT.M deallocated memory when its heap needed to expand, but used malloc() and free() which rely on a system heap implementation that can interfere with attempts to return memory to the operating system. (GTM-10588)

GT.M protects itself against a case where a timer could expire in a vulnerable window of several instructions and cause a process performing a journal operation to loop indefinitely. This issue did not compromise database integrity. Recovery required shutting down processing and restarting journaling. (GTM-10591)

GT.M protects itself against a rare case where a MUPIP STOP or other process kills could occur in a vulnerable window of a handful of instructions and create an inconsistent state in the journal buffer which could cause GT.M processes to loop indefinitely while trying commit an update. This issue did not compromise database integrity. (GTM-10597)

GT.M provides protection from asynchronous events during small windows performing state changes to LOCK shared memory. Previously, asynchronous events like MUPIP STOP at inopportune times could leave LOCK shared memory in an out-if-design state, causeing subsequent attempts at using LOCKs to terminate with a GTMASSERT2. The workaround was to close and restart the instance. (GTM-10615)