GT.M does comprehensive deadlock detection for both TP transactions and non-TP mini-transactions. Previously, GT.M's deadlock checking was less complete and might rarely and erroneously issue an inappropriate GTMASSERT; FIS encountered this issue in testing and has not received a customer report of such a GTMASSERT. (GTM-7614)

GT.M issues a DBFILERR error upon encountering file system problems which prevent normal reading from the database file. Previously, due to changes made with the introduction of MUPIP REORG -TRUNCATE in V5.5-000, GT.M issued a misleading TPFAIL or non-TP failure error with code 'qqqq' in response to such problems. (GTM-7623)

For a database region for which Instance Freeze is enabled, GT.M and MUPIP processes correctly freeze the instance in the unusual case a file system write to the database fails. Previously, this resulted in a segmentation violation (SIG-11) for the process. [UNIX] (GTM-7647)

GT.M manages aspects of TP transactions and non-TP mini-transactions in a more efficient way on AIX and Solaris. In database intensive activity, the improvement on AIX could approach 30% and on Solaris, 10%. As database updates are just one part of a typical application, typical improvements in application throughput are likely to be less than these numbers (i.e., your mileage may vary). [UNIX] (GTM-7664)

An Instance Freeze during database initialization works correctly. Previously, such an event could produce an EN022 error. [UNIX] (GTM-7716)

GT.M more smoothly handles high contention for a database's principal critical section. Previously, limited benchmarking revealed erratic database access latencies in scenarios involving on the order of one thousand concurrent processes. [x86_64 Linux, Solaris] (GTM-7738)

SET operations work correctly on global nodes with defined triggers. Previously, if any trigger node had the same unsubscripted ancestor as the destination node, SET sometimes placed a garbled value in the destination. [UNIX] (GTM-7760)

VIEW accepts DBFLUSH, DBSYNC, and EPOCH. VIEW "DBFLUSH"[:REGION[:N]] writes modified cache blocks to the database file. By default, these command options operate on all regions under the current global directory. N specifies the number of blocks to write; by default, DBFLUSH writes all modified blocks. On UNIX, VIEW "DBSYNC"[:REGION] performs an fsync() system call on the database file. VIEW "EPOCH"[:REGION] flushes the database buffers and, if journaling is enabled, writes an EPOCH record. (GTM-7777)

GT.M appropriately handles a MUPIP STOP received by a process within a small window while processing a TRESTART while an performing an update involving a trigger. Previously, such an unlikely circumstance could cause the process to terminate with a segmentation fault (SIG-11). FIS encountered this issue in testing and has not received a customer report of such an event.[UNIX] (GTM-7811)

GT.M avoids certain unusual hangs during process rundown triggered by the delivery of an external signal. Previously, under very rare circumstances a GT.M process could fall into an indefinite sleep while handling a process-terminating signal, such as SIGTERM. [UNIX] (GTM-4828)

The GT.M terminal device driver sets $KEY to the character or escape sequence terminating a READ, which is the same as the contents of $ZB. Previously, GT.M did not maintain $KEY for terminals. [UNIX](GTM-5708)

GT.M ignores repetitive call-in invocations of gtm_init(). Note that gtm_init() call is done implicitly, not required, and best avoided. Previously, repeted call-in invocations of gtm_init() could cause M stack overflow[UNIX] (GTM-5710)

GT.M supports both IPV4 and IPV6 communication for SOCKET devices, replication, backup, and GT.CM. FIS considers IPv6 support in V6.0-003 to be field test grade functionality, and intends to designate IPv6 support as production grade in a future release. Except for IPv6 support, FIS considers V6.0-003 to be a production grade GT.M release.

The addition of IPv6 support can result in a Source Server of a GT.M V6.0-003 instance attempting to make an IPv6 connection to a Receiver Server from an instance running an older version of GT.M, if the same server name is used with both IPv4 and IPv6 instances. For environments where such circumstances arise, and where different server names are not used for IPv4 and IPv6 addresses, the environment variable gtm_ipv4_only can be set to"TRUE", "YES", or a non-zero integer to instruct GT.M that it should only use IPv4. Also, MUPIP REPLICATE -SOURCE -JNLPOOL -SHOW now displays the "Secondary INET Address" field in a human-readable format. Previously MUPIP displayed the address as a number in decimal and hexadecimal. [UNIX] (GTM-7500) (GTM-6707)

Please refer to GTM-6707. (GTM-7500)

The OPEN and USE commands support the [NO]EMPT[ERM] deviceparameter for terminal devices. When EMPTERM is specified, and a process executing a READ or READ # command receives an "Erase" character or character sequence with an empty input line, the command terminates and $KEY (and $ZB) hold the terminating character sequence. The default is NOEMPTERM. The gtm_principal_editing environment variable can specify an initial setting of [NO]EMPTERM. The TERMINFO specified by the current value of the TERM environment variable defines capnames values "kbs" and/or "kdch1" with character sequences for "Erase." If "kbs" or "kdch1" are multi-character values, you must also specify the ESCAPE or EDIT deviceparameters for EMPTERM recognition. The ERASE - a special terminal input character - also terminates a READ command with an empty input line and $KEY (and $ZB) hold the ERASE character. You can set the ERASE character to various values using the stty shell command. Typical values of the ERASE character are <CTRL-H> and <CTRL-?> .[UNIX](GTM-7675)

GT.M protects process creation from potential deadlocks caused by asynchronous signals. GT.M process creation includes: JOB'd processes, PIPE device processes, gtmsecshr processes, and replication server, update and helper processes. Previously, there were very small windows where an asynchronous signal could cause a process creating a new process to hang indefinitely. [UNIX](GTM-7680)

The GT.M tracing facility more accurately records the system and user CPU time for every profiled M line. Previously, GT.M tracing did not account for an undocumented anomaly in the system service that provides the times, resulting in occasional erroneous values. [Tru64 UNIX] (GTM-7733)

While retrieving information about a file, GT.M defers the handling of signals (such as SIGTERM) that could lead to a process hang. This closes a small window of time within which an interrupt to a GT.M process retrieving file meta-data from the operating system could cause it to hang. FIS encountered this issue in testing and has not received a customer report of such a error. [UNIX] (GTM-7747)

When using GTMJI call-in interface, if an M label declared to have a non-void return type (as defined in the call-in table) does not specify a return value, the invoking Java routine receives a default (false for Boolean, 0 for primitive numeric, and null for non-primitive types) return value. Previously, a missing return value in the M label could potentially result in a segmentation fault or arbitrary value returned to Java. [IBM System p AIX, Sun SPARC Solaris, x86_64 GNU/Linux, x86 GNU/Linux] (GTM-7749)

Long concatenations compile successfully with -DYNAMIC_LITERALS enabled. Previously, such compilations of concatenations involving 128 or more operands produced TMPSTOREMAX errors. [UNIX] (GTM-7761)

The JOB command produces a JOBPARTOOLONG error if a jobparameter exceeds 255 characters. Previously, on UNIX jobparameters longer than 127 characters and on OpenVMS parameters longer than 255, except for DEFAULT which failed when longer than 197, caused either an access violation or a GTMASSERT (GTM-7770)

The maximum number of arguments for functions and concatenate expressions is 253 on all platforms except for Solaris, where it is 239. Previously the documentation incorrectly stated that the limit was 256 for all platforms, and exceeding 239 arguments on Solaris for these operations produced an access violation (SIG-11) or an inappropriate UNDEF error. (GTM-7774)

GT.M safely executes extrinsic functions in an edge case where a routine loaded in memory that includes an address that is a multiple of 0x100000000, makes a call to a label within the routine but across that address. Previously, this could result in an access violation (SIG-11). [x86_64 Linux] (GTM-7817)

GT.M core dumps now include the memory segments needed for prompt problem analysis. Previously core dumps could be missing required memory associated with huge pages, or due to inappropriate user configuration. [Linux] (GTM-7823)

MUPIP SET -JOURNAL adjusts journal alignsize or allocation only when the operation can complete without any error. Previously, MUPIP changed these values before completing its error checking, which could cause subsequent problems for journal operation. (GTM-7370)

MUPIP issues a JNLORDBFLU error on failure to synchronize a journal file or database to disk. However, MUPIP RUNDOWN -OVERRIDE removes IPC resources, but leaves the database header fields intact for use by a subsequent MUPIP JOURNAL -ROLLBACK, MUPIP JOURNAL -RECOVER, or MUPIP RUNDOWN, depending on journal and/or replication status. Additionally, MUPIP RUNDOWN sends a MURNDWNOVRD informational message to the operator log on every use of the -OVERRIDE qualifier, which ignores potentially hazardous conditions that would otherwise result in guidance to use a MUUSERLBK, MUUSERECOV, or JNLORDBSYNC error; a brief description of the bypassed condition follows the MURNDWNOVRD message. [UNIX](GTM-7423)

MUPIP REORG safely trims long global names specified with the -SELECT and -EXCLUDE qualifiers to a maximum of 31 characters. Previously, MUPIP REORG produced a fatal GTMASSERT error if given a name longer than the maximum key size in the database file header, and if the name, when trimmed, matched an existing global. Also, MUPIP REORG -RESUME works appropriately after an administrator reduces the maximum key size, where previously it produced an access violation (UNIX SIG-11 or OpenVMS ACCVIO). Additionally, MUPIP EXTRACT prints trimmed global names in RECORDSTAT messages. (GTM-7430)

GT.M handles a database file extension after a MUPIP REORG -TRUNCATE correctly. Previously, when performing a file extension approximately concurrent with a TRUNCATE, a process might have encountered inappropriate TPFAIL or GVXXXXFAIL errors. FIS encountered this issue in testing and has not received a customer report of such an error. In addition, TRUNCATE no longer prints inappropriate GBLNOEXIST messages for "Global #t" and generally moves fewer root blocks. [UNIX] (GTM-7519)

To simplify journal file maintenance for system administration, when renaming the current journal file as part of a journal file switch, GT.M uses the current date and time. Previously, GT.M used the date and time of the last update within the journal file. (GTM-7627)

The Source Server and Receiver Server exchange and record information about their log files and process IDs. In addition, a FETCHRESYNC ROLLBACK, which does not have a separate log file, sends its current working directory to the Source Server log. Previously, the replication protocol did not exchange this state information. [UNIX] (GTM-7631)

REORG safely handles a rare concurrency issue associated with BG databases configured to have a small number of global buffers and MM databases of any size. Previously, REORG would produce an access violation (UNIX SIG-11 or OpenVMS ACCVIO) occasionally, while working on blocks within approximately 64KiB of the end of an MM database. The same could happen for BG databases with fewer than 384 global buffers (on 64-bit platforms) or with fewer than 512 (32-bit). (GTM-7688)

The replication Source Server always operates in the catch-up mode and reacts more quickly to flow control messages from the Receiver Server and to shut down commands. Previously, it could have been slow to recognize Receiver Server requests to suspend sending information in order for the Replicating Instance to have a chance to catch up, and, under some circumstances, it could have been unresponsive to shut down requests. The Source Server also maintains a more even stream by checking the replication journal pool more frequently. In addition, on HP-UX, a Receiver Server reacts more quickly to shut down commands. Previously, under some circumstances, it could have been unresponsive to shut down requests. (GTM-7754)

The Receiver Server manages incoming messages from the Source Server appropriately during shutdown and flow control events. Previously, in some rare cases, the Receiver Server could terminate with a segmentation violation (SIG-11) or hang indefinitely during these events. [UNIX] (GTM-7767)

The replication Update Process does not issue false STRMSEQMISMTCH errors. Previously, in the event of an concurrent ONLINE ROLLBACK, Update Process issued false STRMSEQMISMTCH errors. [UNIX] (GTM-7785)

The "MUPIP REPLICATE -SOURCE -ACTIVATE" command sets the source server to ACTIVE_REQUESTED mode, and the source server subsequently sets the mode to ACTIVE once it completes the transition. Similarly, the "MUPIP REPLICATE -SOURCE -DEACTIVATE" command sets the source server to PASSIVE_REQUESTED mode, and the source server subsequently sets the mode to PASSIVE once it completes the transition. The -ACTIVATE and -DEACTIVATE qualifiers produce an error message if they are specified while the source server is in ACTIVE_REQUESTED or PASSIVE_REQUESTED mode. The *_REQUESTED modes may be reported by the -CHECKHEALTH or -JNLPOOL -SHOW qualifiers. Previously, use of the -ACTIVATE and -DEACTIVATE qualifiers in rapid succession could lead to an inconsistent state in the source server. FIS encountered this issue in testing and has not received a customer report of such an event. (GTM-7786)

LKE and DSE automatically retry database initialization if some other process removes the shared memory associated with the database while they are bypassing the normal interlocking of the initialization. If initialization does not succeed due to repeated shared memory removals, DSE/LKE moves on to the next regions' initialization. Previously, these operator utilities terminated with an error (REQROLLBACK/REQRECOV/REQRUNDOWN) when another process removed shared memory while they were trying a non-interlocked database initialization. [UNIX] (GTM-7528)

While printing to the syslog, GTMSECSHR defers the handling of signals (such as SIGTERM) that could lead to a process hang. Previously, there was a very small chance that a signal could interrupt a GTMSECSHR process in the middle of writing to the syslog, thus causing the process to hang indefinitely. [UNIX] (GTM-7731)

GDE now correctly stores and displays the namespaces specified as part of the -NAME qualifier. Previously in edge cases where * was specified in global ranges, it was possible for GDE to store the global mapping incorrectly. This meant GDE SHOW -MAPS as well as GDE SHOW -NAME produced incorrect results. An example that did not work before was if the name AG* mapped to region STAR1, the name AGZ* to region STAR2 and the name AGZ to region STAR1 (that is, there was an exception in the AGZ* name specification), GDE incorrectly mapped the name AGZ* to region STAR1. (GTM-7732)

The gtmposix plug-in stat() function works with releases after V6.0-002. Previous versions of gtmposix contained an incorrect stat() function definition in the external call table, which, if used with current releases, produce an error return even for correct external routine invocations. [UNIX] (GTM-7788)

A GTMSECSHR process does not block any interrupt signals (such as SIGTERM) regardless of the signal mask of the invoking process, though it ignores signals that are not material to gtmsecshr operation. Previously, a gtmsecshr process inherited the signal mask of the invoking GT.M process and could inappropriately become unresponsive to particular signals. The workaround was to let gtmsecshr timeout. [UNIX] (GTM-7794)

TThe GT.M installation script "configure", which is in turn invoked by the "gtminstall" script, sets up the gtmsecshr-related files properly for both M and UTF-8 modes of operation. In the first packaging of V6.0-002, the gtminstall script configured gtmsecshr in a way that caused UTF-8 mode processes to attempt to start gtmsecshr in a way that violated the gtmsecshr security checks. A later repackaging of V6.0-002 corrected the issue.[UNIX] (GTM-7815)